I agree that the LSB shouldn't be a collection of required software as much as a group to help form and extend standardized APIs. It should be the glue that holds Linux together, not necessarily something that requires packages A, B, and C. I just think that if you deal with package dependencies intelligently, there's no reason to have the LSB tell you you need to have certain libraries. If a program needs certain other dependencies, it should just be able to quickly and easily find, download, and install them, in an intelligent way. So yeah, I hope the LSB evolves into the solidification and reporting of APIs for Linux's "glue" to help with modularity and to keep Linux powerful, but not necessarily a rule book. It should change with the times, not force the past on the future necessarily. I think there are certain programs that should be included on any distro though, like cp, or ls, but chances are pretty good those will always be there of course. If software installation is easy and intelligent, if you wanted a program that you were used to using it should be very very simple for you to get it. I like Ubuntu for notifying me of what package contains the program I am wanting to use.
I think it would be cool to click on a web link, and have the package manager pop up and ask if you want to install the package. You could then click OK, and it would check to see what software is required, and if you already have that software installed, and then only download the software you don't have.
The LSB Packaging API is just an API to allow the installation of any kind of software package. So, it's a very welcome part of any distro. The rest of the LSB? Maybe not as much. All I want is for Linux to be modular so that any software can be easily installed and will integrate well. For all the software that gets used, I think that popular demand should be the deciding factor, so the "distros" who want to be "popular" are going to include those popular packages. It's sort of the software version of natural selection. ^^
I'll chime in too and say also that I don't think that's correct. Now to demonstrate my possibly flawed understanding of economics (but I thiiiiiiink I'm right).
When they converted it to U.S. dollars, it was converted to U.S. dollars. That means that the value of the U.S. dollar vs. the U.K. pound should have been taken into account, via the conversion process. So, when comparing two items of the same price units, a higher price on an item is supposed to mean that a higher percentage of one's paycheck should be going into paying for that item, meaning that the item is more expensive for them. One problem I see is what is the conversion ratio based on, and is it a good number. If you're basing it off an average of several different kinds of items, that may be the best way to figure out how much two currencies are worth verses each other. But, this could be skewed for lots of reasons, like what if it doesn't take into account certain items which are heavily influenced by gross national production (GNP), and what about politics? For instance, now I don't know exactly how much they produce, but lets say China produced amazingly high amounts of rice. Because of this, rice in China was very cheap. When calculating how much a yuan was worth vs. other currency, if you did not take rice into account, the yuan would not be worth as much as if you did take it into account. It would be worth more because rice would be one thing you could buy cheaply in that country, and that means higher value.
So, back to the original topic, what if electronics weren't taken into account when factoring the value of the Pound? If electronics were much more costly for whatever stupid reasons there (which they are), that would mean that the value of the pound should be decreased further, so when viewing the price of the U.K. electronics, the price would be wrongly inflated when it should be lower. Suddenly, this could make the $600 British item be actually worth $500 in reality.
Now, you can do this experiment in your very own home across the internet!:P Ask your friend in another country to compare prices of items, and also compare what percentage those items cost roughly equivalent job positions. By doing this, you should be able to find out how much harder it is to survive doing roughly the equivalent work in two different countries. Add in research for the cost of electronics, and you'll have some idea of how much more or less electronics cost in comparison to food and other "basics". Then, last but not least, it should give you some idea of whether or not the conversion ratio between the currencies of each country is a good number or not.
Giving a binary base for privative software vendors throwing their software wherever they like to, with half-assed start/stop scripts and without integration with the native package management tools of my distribution of choice?
Uh that's exactly what the LSB is trying to put a stop to. Currently, software installation sucks because it doesn't have integration with the native package manager. One of the reasons for forming a cohesive, extensible packaging API is so that any package can communicate with the package manager about it's existence. Normally, this isn't done unless you use packages for your specific version of your specific distro. This is beyond retarded, and will keep Linux fragmented and away from ordinary users who don't know what the fuck configure make make install means, not to mention have no clue how to solve problems in doing that when they arise.
Currently the Burgdorf API is the incarnation of the LSB Packaging API and it would be nice to receive more help on such a critical issue. The article was spot on in saying that this will also lead to increased stability in other APIs as it's silly to install ten different versions of one library just because it's API isn't stable. Updating the library, that's mostly OK, but the rigidity of library APIs will become more apparent/annoying once Linux programs are actually portable (yes, I know binaries exist, I'm talking about packages for automatic updates, package manager awareness, etc).
Everyone should support good standardized APIs for Linux to help make this happen. While some users will be OK with never installing any software outside their own little world except for what their distro maintainers bundle up for them, many users are interested in having direct access to so-called "third-party" programs, not only for their binaries but for automatic updates among other things. Who's not satisfied with being stuck with version X just because they're using distro X of a program they love? I don't think most users are, and they shouldn't have to wait for the distro gift if they don't know how to compile, or the annoyances of running a "disconnected" binary in which they have to create manual menu items for and manually update.
If Linux is to ever be actually available to the masses, for it to gain momentum through the easy sharing of software outside the box which is the immediate software repository, and make it actually easy for Linux software developers to write software for any and all Linux distros without their blessed consent, this project is critical. Any user that wants free, unfettered, easy access to software has every interest in installing the LSB packaging API or using a distro with it already installed.
P.S. Yeah, there are other answers like Klik, Autopackage, Zero Install, and others, but an API to allow any package to be installed so that it will provide immediate integration with the package manager is much more helpful. Until the packaging API is finished though these solutions will help.
Some hardware, like ATI, has it's own BIOS on-board so that communication with the device is easier. I believe that an API is possible even for things which change quickly as long as there's enough planning to cope with such extreme changes, but to simplify the API, things like these on-board BIOSes certainly do help.
You shouldn't have to develop programs that are DE-centric. If Cocoa is so much better than GTK and QT, Freedesktop.org needs to help push some new APIs that GUI front-ends can use to create programs more rapidly that are not specific to one DE. wxWidgets seems to be really far behind and it's an API to allow modularity that's needed, not a specific library. Linux should push hard to get some professional, clean, and polished APIs together to make programming for Linux a snap, so it doesn't matter what DE the user prefers using.
If QT has a feature GTK doesn't, and you write your program to use that feature, make QT be a required dependency or whatnot until GTK can fill in that hole with something. The future of Linux is modular programming, so the sooner it's embraced the better off everyone will be and the easier access to software and less duplication of work will exist, among other benefits. Don't let Linux fragment, it needs all the help it can get. Open APIs that are well planned out and built will save everyone, users and developers alike, from being locked into massive software stacks. Modularity = win win for everyone.
Linux has several systems which are very unmodular and need to be scrapped and replaced with much more modular, flexible, and extensible systems. Use and help improve the existing APIs that are great out there, or come up with your own, but planning and planning for new plans to come about later (extensibility) is certainly one of the more important steps of a project. Of course it requires good coders and artists, too, and general community interest and support.
Don't forget good tools, libraries, and APIs. If you have a massive software stack that's completely unmodular because it uses no APIs or plugins or anything, making it incredibly difficult to add or remove features and actually work on the damn thing, that will help kill the project. You won't have such horrible problems with feature bloat if you make the system modular so that modules can compete.
This would be good for both open and closed software. Modular programming is intelligent and should be done where ever possible. Giving users more choice isn't a bad thing. The need for open source software will never go away. More freedom in every way for the Linux desktop will be good and will only spur adoption and growth, and that increase of both closed and open source software will help everyone, including users who only use open source software. Adoption helps everyone.
That's really great that some developers take the modular and API structural systems to heart. The divisioning of work is a great feature that allows for much easier development among other things. I hope the Linux kernel also becomes more modular and flexible in the future, and all software really. I think due to competition you'll see this kind of thing more and more, because the huge unmodular software stacks will become more ignored because they are more difficult and less usable, while the ones that are more modular and thus powerful will see more adoption.
I'd really like to see some standardization APIs created for more devices so that you only need one driver per hardware class. Imagine if you could just remove the whole proprietary problem with devices so that drivers were simple and new hardware was much easier to support. Perhaps some completely new interface standards could really help, just like how firewire made media drivers obsolete. Any new features can simply be extended to the firewire driver and that one driver updated to take advantage of newer hardware. Perhaps it could even be like OpenGL where devices could actually implement their own newer functions without *having* to have an update to OpenGL. Wouldn't it be nice to see the same thing for graphics cards? ^^
Well mobile and affordable/portable chips is a really big thing right now. Sure, users wanting powerful systems may not choose VIA but the market for small and portable computers is quite large. ^^
Lucky, that's cool. I don't know which I'd blame more for it not being sold much here, a general fear of change and stupidity with electronics, or MS business strongholds.
Even in their stores though? Best Buy of course sells it online, as well as the EEE PC, but that's what I was told when asking for the EEE in-store, and it was a manager even who said it. Not that managers are always right, and Best Buy *is* mostly a MS shop at least.
Sure, because MS would prefer to get as much money from you as possible, but if not they'll give you their OS for free just to have you using it at the very least as doing so helps them. Piracy helped make MS what they are today. It's really too bad schools don't band together and support the Linux OS instead, they could even each pay some money toward Linux software development, though I'm sure most of the crappy Windows educational software (and it IS crappy) will run through Wine any way.
Installing certain programs by default? That's what a distro is. As long as I can so-called "customize" my system by installing any of these programs that Dell is installing, I'll be fine. You don't need to buy a Dell computer to get certain programs though, unless they're the only provider and they aren't open sourced and you can't buy just the program from them, or unless you simply want those programs to be default. I'll take anything over Windows when I buy a complete computer, since I don't use it, and certainly having a good default program selection is a perk if that's the software you want.
Hmm, that's interesting and seems to be pretty good, but of course in a way I guess it's a little more "top level" sorta than the LSB Packaging solution. Or, well, maybe it would achieve the same thing but since the LSB is, well, the LSB, it will probably have good adoption and it seems that quite a few things may get addressed with it. The OpenSuse Build Service still needs to take specific distros into consideration, but after the LSB Packaging standard is finalized, it should level the playing field completely so that no annoying distro-specific crap has to be taken into account while packaging, since those things make packaging difficult. The LSB API should have enough information to easily allow any package manager to be able to deal with packages correctly on any system, provided that the solution is robust/extensible, etc, which is of course what everyone wants to make it be.
Don't get me wrong, I'm rooting for any and all solutions, but while not knowing too much in detail about what's out there, I would guess the LSB solution will probably be what will eventually be the solution, I just hope it won't take too long to do so. Until then, when and if that happens, these other projects can try to fill that spot but I just don't know if I'll be able to shake off the feeling that it's duct tape until the LSB solution arrives to wield it all together. ^^
Intel, how about supporting the LSB Package project so that once solidified will allow systems to install both RPM and DEB packages, as well as any others. Once software is easily installable cross-distro, distros will be reduced to mere collections of specific software, and you won't need to make silly decisions like that based on formats because any format will be possible.
Take a look at, and help with, the Burgdorf Packaging API, the current proposed solution in the making.
That's easy to solve. The whole point of an API is to allow a compatibility layer so that B can always communicate with A. If done right, this layer can be easily extensible to allow the adoption of new ideas and better ways of doing things. If there are certain things that the kernel absolutely must need to have in order for this compatibility layer to function, this minimal set of kernel requirements can be deemed LSB minimal. That way, driver developers can have a nice API to develop for and they don't have to worry about incompatibilities. It's the same way with anything else, like OpenGL for instance, or HTML, or any other standard. There's so many ways of helping to implement this, it's completely possible to do.
Yes, the NDA way is another solution as well, but the above API would allow an NDA to not be needed. These companies wouldn't have to trust any third-party developers with an NDA, it would allow them to do it themselves easily. Like I said, the more solutions that Linux can bring to the table, the better. The more it will help with Linux adoption. Anything that helps a small part of Linux will also help everyone else using and developing for Linux, that's the beautiful way Linux works. If you make it easier to install drivers or software or anything, it will help everyone, it's great. ^^ So, it's just a way in which Linux could improve itself, and that's good for all. I prefer open drivers just as much as anyone else as it helps with many things in many ways, but having a closed driver with in-house development is an option which some companies would choose, so it's an option that should exist for them in an easier way than it does now. Linux software development = hard = less Linux goodness. Linux development = easy = more Linux goodness, is all I'm saying.
Sure, open sourcing Flash would make Flash much easier to bug fix and you'd suddenly have all the improvements that open source has, I agree. I'm not arguing against open source, but I am arguing that allowing closed source on Linux or allowing users to even use open source drivers and to easily install those drivers without having to compile them first, will help both open and closed source projects and companies. There will still be demand for Adobe to open source Flash, that will never and has never gone away, hence Gnash and Swfdec and such. That will only continue, as open source software carries very visible advantages. Again, it's just that there are advantages, and it's good to have the option, for users and companies to install binaries easily. It will allow open source projects to function more easily with Linux, it will allow users to not have to be compilation geniuses, etc.
Any way, I still want open source software versions of everything to exist and I hope with those things, but I also want easy ways to install all software to come to Linux. It will help everyone to see that happen more.
OTOH, the last time I bought a bit of hardware that claimed Linux
compatability on the box it was a big fat goose egg. The alleged
support was for a binary driver for a particular kernel. Getting it
to work with Linux would have been more trouble than I wanted to
deal with (nevermind the average consumer).
Right, so someone needs to develop a stable but extensible API for Linux kernel driver installation so that you don't have to recompile everything, or they have to open source their drivers, or create a mechanism to automatically compile a kernel module. The last solution is a pain in the butt, the middle solution is ideal for consumers, and the former would help having for the companies that want to play hard ball, so consumers have the option of using binaries instead of having to recompile, and so Linux can have true "third-party" driver support without these parties having to kiss the kernel dev's toes.:)
Any ways to increase Linux's modularity and capabilities while adding stability and improvements through extensibility are good, and will help with Linux's adoption rate. If that means closed-source companies can more easily target Linux, so be it, it won't stop me from wanting open source solutions and more both open and closed solutions will come with the increasing adoption. All users will win as Linux becomes more powerful, customizable, flexible, and modular.
ATI cards might end up with a penguin logo but I'm not sure I would
want one for any OS.
Sure, and that's exactly what I'm talking about. You have the option to use nVidia's cards for 3D programs for instance because they provide a closed source driver. You have a choice. I myself will buy ATI if I start actually seeing all this promised open source support actually come about. It would make it easier for nVidia to have better Linux driver support if the Linux kernel supported APIs for binary drivers. They wouldn't then be forced to include stuff to build the kernel driver on the fly, and upgrading your kernel wouldn't hose your system if you manually installed their driver, causing you to have to reinstall it. If Linux gets some stable API for drivers, which is completely possible to do in a satisfactory, extensible way which will not hamper any kind of technological progress (on the contrary, will allow speeding it up by giving this modularity), it will really help to improve the driver installation world for anyone wanting to install drivers which are outside the kernel and repositories, and with the development of a good packaging API will also allow these OEMs to only have to create a single package to register itself with your package manager, removing the need for manual installation completely and allowing for easy system upgrades straight from the OEM.
Aah, Sourceforge being one big cross-distro Linux repository, I can't wait.
Because most of the people read the boxes for Windows support? Not anymore. It has been accepted that, whether there is a nice Windows logo on there or not, it will work with Windows unless it says "For Mac" or is made by Apple. Linux will be the same, no need for fancy logos, etc. Though I do try to buy things that have Linux on the system requirements (such as flash drives, all will work with Linux I know, but I would rather buy the one that specifically mentions it, vote with your wallet)
Yes, but in this case Linux doesn't always have out-of-the-box hardware support with some things especially if they are "extreme" peripherals, like, say, tablets, webcams, VFDs, and remotes. I think right now it would help Linux out to have Tux on the boxes not only to ensure compatibility, but to also advertise for Linux. Microsoft pushed very hard getting massive Vista logos on everything, so I hope it'll happen to Linux too eventually.:)
But the thing is, if they would just release the specs for the hardware, even under a NDA, someone could write a kernel driver for it, include it with the main kernel and all would be good. And there are a lot of people that are willing to do it. And I honestly don't want to do what I have to do with Windows and that is install some driver, which installs some proprietary application to do something that should be done with a generic driver for things such as printers, USB drives, etc. And it is really bad if you lose the CD that comes with it and then have unusable hardware... So, in the way, free reversed engineered drivers are slow, but they are better than the super-proprietary, niche drivers that the manufacturers want to give us for No-Good-Reason (TM).
But it doesn't always happen, companies aren't always willing to do this, so like I said, if a way is given to these companies to go either the open or closed source route for drivers, there will be more options, and thus there will be more Linux support. That will in no way prevent Linux users who want it to push for and use only those drivers that are open sourced, and it will help them get more attention because their platform will have more attention. In other words, any kind of support for Linux will help all Linux users in some way. If Linux had 90% of the market right now, there would be that many more developers out there with an interest in writing software for Linux, both closed and open source.
No one wants to install crapware on their system, but having the option of either installing crapware in order to use some piece of hardware, or not being able to use the hardware at all, there are many users out there who would choose to use the hardware any way. If you want to not use it because it's not open source, or because it installs crapware, that's great, that's fine, it's up to you, and I wouldn't like it either. The key is that you always have a choice, and my point is that the more choices we as Linux users have available to us, the better, period, as it increases adoption which increases development which increases our choices further. Don't get me wrong, I love installing Linux and having most everything just work out of the box, it's one of the great strengths of Linux, not that other OSes don't have a lot of included driver support as well, but having the choice between, say, a working Wacom tablet so that I can draw, and no working tablet at all, I'll choose the working one. The ideal choice for me and any user who cares about openness is an open source driver, but it's nice to have a proprietary driver rather than none at all when you're stuck without a perfect solution. The open source drivers already have the advantage of being plug'n'play since they're already included. Besides, the kernel developers should not have control over everyone downstream, you shouldn't have to kiss their toes in order to get your driver to be included, so having an API there in order for anyone to be able to add a driver to their system
First I just have to say, awesome journal. Thank you so much for promoting cross-anything usability. In order for everyone to have access to all software, having that software use modular/extensible APIs/ABIs so that they can always function in the best way in any environment is very important. The Freedesktop project is very important in helping to bring more interoperability to the Linux system, so I wish them all luck in this struggle. It'll be amazing when a way can be found to make any program have the look and feel of the native desktop or whatever user-defined look that they want, and when configuration files and data can all be stored in similar locations, like just off the user's home directory, instead of being buried inside.kde or.gnome. Heck, I'll be happy when my KDE program menu icons start displaying correctly in Gnome.
While it's fine and great that Ubuntu has become a noticed distro, I'll be happier when "Linux" becomes more common. When you can download virtually any distro and it will simply be a specific selection of Linux software, but you can go out and easily download and install any Linux software or drivers you want. Then, it won't need to be "Ubuntu", it will just need to be "made for Linux". Some distros may not be concerned with cross-distro software portability because they have an interest in users coming to them for help, instead of to the actual upstream providers of the software, since some of these distros are based on wanting to create a need for support. However, just like not having desktop standards hurts everyone, not having easy cross-distro software installation does the same. Fortunately, there are projects like the Burgdorf Packaging API which are working on solving this issue, as well as more top-level solutions like Zero Install, and of course both of these projects could use more support from everyone.:)
But with Ubuntu you don't need that just about everything will work without any configuration.
You're right to some degree there, however the parent's point about penguins on the boxes is a huge problem. For Linux to be "easy", it has to have hardware which tells consumers that it's Linux-compatible. But the thing in the way of solving that is Tux's catch22: "Linux won't get support until it gets widely used, but it won't see wide use until it gets support." The problem is being solved, it's just slow. Even the supposed thing with ATI/AMD releasing their new graphics cards, the Radeon HD 48x0's, that would have Tux on the box never happened. Disappointing. However, since driver installation is still insane on Linux, it's not too surprising that manufacturers don't support it better. If they had a kernel module or API which OEMs could use for quick driver installation so you wouldn't have to compile or reinstall your driver for every kernel upgrade you went through, and could also provide an install package that could register itself with the most common package managers out there by using a universally accepted packaging API, then I think you'll start seeing that happening more. Examples of this effort include the Burgdorf Packaging API here. (Before someone says it, yeah I know giving it to the kernel devs to have them package it for you is another option, but Linux needs to be modular enough to allow either method to occur. Anything that helps adoption by helping easy installation is a good thing, and will increase Linux's adoption, and that's all I want to see happen. Users still will have the choice to use binary blobs or not, but they will have a lot more choices when Linux adoption becomes greater.)
I'm anxious to see progress with hardware support by having databases, or better yet more online stores selling Tux-compatible hardware so you never have to go to the store to begin with.
...all the old Linux users who tout things like "Linux doesn't need to do that, it works fine as it is" or "Stop trying to make Linux like Windoze" and other such crap would get a life. Linux needs is to push the envelope and adapt to new ideas. It's for everyone, so if someone is having a problem, they can and should resolve that problem, always, period, and there's always a way to do it with software. What it all comes down to is every user deserves to have Linux do what they want and need, the only question is finding others who agree with you and can help get it created. Linux needs change, so it's sad to see visions being bashed.
I'm anxious for the Linux user base to increase, as it means more new ideas can be introduced, and the percentage of users saying "you can't" will be replaced by those saying "how can we".
Slashdot Mirror
I agree that the LSB shouldn't be a collection of required software as much as a group to help form and extend standardized APIs. It should be the glue that holds Linux together, not necessarily something that requires packages A, B, and C. I just think that if you deal with package dependencies intelligently, there's no reason to have the LSB tell you you need to have certain libraries. If a program needs certain other dependencies, it should just be able to quickly and easily find, download, and install them, in an intelligent way. So yeah, I hope the LSB evolves into the solidification and reporting of APIs for Linux's "glue" to help with modularity and to keep Linux powerful, but not necessarily a rule book. It should change with the times, not force the past on the future necessarily. I think there are certain programs that should be included on any distro though, like cp, or ls, but chances are pretty good those will always be there of course. If software installation is easy and intelligent, if you wanted a program that you were used to using it should be very very simple for you to get it. I like Ubuntu for notifying me of what package contains the program I am wanting to use.
I think it would be cool to click on a web link, and have the package manager pop up and ask if you want to install the package. You could then click OK, and it would check to see what software is required, and if you already have that software installed, and then only download the software you don't have.
The LSB Packaging API is just an API to allow the installation of any kind of software package. So, it's a very welcome part of any distro. The rest of the LSB? Maybe not as much. All I want is for Linux to be modular so that any software can be easily installed and will integrate well. For all the software that gets used, I think that popular demand should be the deciding factor, so the "distros" who want to be "popular" are going to include those popular packages. It's sort of the software version of natural selection. ^^
I'll chime in too and say also that I don't think that's correct. Now to demonstrate my possibly flawed understanding of economics (but I thiiiiiiink I'm right).
:P Ask your friend in another country to compare prices of items, and also compare what percentage those items cost roughly equivalent job positions. By doing this, you should be able to find out how much harder it is to survive doing roughly the equivalent work in two different countries. Add in research for the cost of electronics, and you'll have some idea of how much more or less electronics cost in comparison to food and other "basics". Then, last but not least, it should give you some idea of whether or not the conversion ratio between the currencies of each country is a good number or not.
When they converted it to U.S. dollars, it was converted to U.S. dollars. That means that the value of the U.S. dollar vs. the U.K. pound should have been taken into account, via the conversion process. So, when comparing two items of the same price units, a higher price on an item is supposed to mean that a higher percentage of one's paycheck should be going into paying for that item, meaning that the item is more expensive for them. One problem I see is what is the conversion ratio based on, and is it a good number. If you're basing it off an average of several different kinds of items, that may be the best way to figure out how much two currencies are worth verses each other. But, this could be skewed for lots of reasons, like what if it doesn't take into account certain items which are heavily influenced by gross national production (GNP), and what about politics? For instance, now I don't know exactly how much they produce, but lets say China produced amazingly high amounts of rice. Because of this, rice in China was very cheap. When calculating how much a yuan was worth vs. other currency, if you did not take rice into account, the yuan would not be worth as much as if you did take it into account. It would be worth more because rice would be one thing you could buy cheaply in that country, and that means higher value.
So, back to the original topic, what if electronics weren't taken into account when factoring the value of the Pound? If electronics were much more costly for whatever stupid reasons there (which they are), that would mean that the value of the pound should be decreased further, so when viewing the price of the U.K. electronics, the price would be wrongly inflated when it should be lower. Suddenly, this could make the $600 British item be actually worth $500 in reality.
Now, you can do this experiment in your very own home across the internet!
Giving a binary base for privative software vendors throwing their software wherever they like to, with half-assed start/stop scripts and without integration with the native package management tools of my distribution of choice?
Uh that's exactly what the LSB is trying to put a stop to. Currently, software installation sucks because it doesn't have integration with the native package manager. One of the reasons for forming a cohesive, extensible packaging API is so that any package can communicate with the package manager about it's existence. Normally, this isn't done unless you use packages for your specific version of your specific distro. This is beyond retarded, and will keep Linux fragmented and away from ordinary users who don't know what the fuck configure make make install means, not to mention have no clue how to solve problems in doing that when they arise.
Currently the Burgdorf API is the incarnation of the LSB Packaging API and it would be nice to receive more help on such a critical issue. The article was spot on in saying that this will also lead to increased stability in other APIs as it's silly to install ten different versions of one library just because it's API isn't stable. Updating the library, that's mostly OK, but the rigidity of library APIs will become more apparent/annoying once Linux programs are actually portable (yes, I know binaries exist, I'm talking about packages for automatic updates, package manager awareness, etc).
Everyone should support good standardized APIs for Linux to help make this happen. While some users will be OK with never installing any software outside their own little world except for what their distro maintainers bundle up for them, many users are interested in having direct access to so-called "third-party" programs, not only for their binaries but for automatic updates among other things. Who's not satisfied with being stuck with version X just because they're using distro X of a program they love? I don't think most users are, and they shouldn't have to wait for the distro gift if they don't know how to compile, or the annoyances of running a "disconnected" binary in which they have to create manual menu items for and manually update.
If Linux is to ever be actually available to the masses, for it to gain momentum through the easy sharing of software outside the box which is the immediate software repository, and make it actually easy for Linux software developers to write software for any and all Linux distros without their blessed consent, this project is critical. Any user that wants free, unfettered, easy access to software has every interest in installing the LSB packaging API or using a distro with it already installed.
P.S. Yeah, there are other answers like Klik, Autopackage, Zero Install, and others, but an API to allow any package to be installed so that it will provide immediate integration with the package manager is much more helpful. Until the packaging API is finished though these solutions will help.
Some hardware, like ATI, has it's own BIOS on-board so that communication with the device is easier. I believe that an API is possible even for things which change quickly as long as there's enough planning to cope with such extreme changes, but to simplify the API, things like these on-board BIOSes certainly do help.
You shouldn't have to develop programs that are DE-centric. If Cocoa is so much better than GTK and QT, Freedesktop.org needs to help push some new APIs that GUI front-ends can use to create programs more rapidly that are not specific to one DE. wxWidgets seems to be really far behind and it's an API to allow modularity that's needed, not a specific library. Linux should push hard to get some professional, clean, and polished APIs together to make programming for Linux a snap, so it doesn't matter what DE the user prefers using.
If QT has a feature GTK doesn't, and you write your program to use that feature, make QT be a required dependency or whatnot until GTK can fill in that hole with something. The future of Linux is modular programming, so the sooner it's embraced the better off everyone will be and the easier access to software and less duplication of work will exist, among other benefits. Don't let Linux fragment, it needs all the help it can get. Open APIs that are well planned out and built will save everyone, users and developers alike, from being locked into massive software stacks. Modularity = win win for everyone.
Linux has several systems which are very unmodular and need to be scrapped and replaced with much more modular, flexible, and extensible systems. Use and help improve the existing APIs that are great out there, or come up with your own, but planning and planning for new plans to come about later (extensibility) is certainly one of the more important steps of a project. Of course it requires good coders and artists, too, and general community interest and support.
Don't forget good tools, libraries, and APIs. If you have a massive software stack that's completely unmodular because it uses no APIs or plugins or anything, making it incredibly difficult to add or remove features and actually work on the damn thing, that will help kill the project. You won't have such horrible problems with feature bloat if you make the system modular so that modules can compete.
Quite simply, don't forget the planning.
This would be good for both open and closed software. Modular programming is intelligent and should be done where ever possible. Giving users more choice isn't a bad thing. The need for open source software will never go away. More freedom in every way for the Linux desktop will be good and will only spur adoption and growth, and that increase of both closed and open source software will help everyone, including users who only use open source software. Adoption helps everyone.
I'd most like to see acceleration for the open source codecs like Vorbis, Snow, Dirac, and others, but mpeg is better than nothing.
I'm in love. Thank you. ^^
That's really great that some developers take the modular and API structural systems to heart. The divisioning of work is a great feature that allows for much easier development among other things. I hope the Linux kernel also becomes more modular and flexible in the future, and all software really. I think due to competition you'll see this kind of thing more and more, because the huge unmodular software stacks will become more ignored because they are more difficult and less usable, while the ones that are more modular and thus powerful will see more adoption.
I'd really like to see some standardization APIs created for more devices so that you only need one driver per hardware class. Imagine if you could just remove the whole proprietary problem with devices so that drivers were simple and new hardware was much easier to support. Perhaps some completely new interface standards could really help, just like how firewire made media drivers obsolete. Any new features can simply be extended to the firewire driver and that one driver updated to take advantage of newer hardware. Perhaps it could even be like OpenGL where devices could actually implement their own newer functions without *having* to have an update to OpenGL. Wouldn't it be nice to see the same thing for graphics cards? ^^
Well mobile and affordable/portable chips is a really big thing right now. Sure, users wanting powerful systems may not choose VIA but the market for small and portable computers is quite large. ^^
Lucky, that's cool. I don't know which I'd blame more for it not being sold much here, a general fear of change and stupidity with electronics, or MS business strongholds.
Even in their stores though? Best Buy of course sells it online, as well as the EEE PC, but that's what I was told when asking for the EEE in-store, and it was a manager even who said it. Not that managers are always right, and Best Buy *is* mostly a MS shop at least.
Sure, because MS would prefer to get as much money from you as possible, but if not they'll give you their OS for free just to have you using it at the very least as doing so helps them. Piracy helped make MS what they are today. It's really too bad schools don't band together and support the Linux OS instead, they could even each pay some money toward Linux software development, though I'm sure most of the crappy Windows educational software (and it IS crappy) will run through Wine any way.
Installing certain programs by default? That's what a distro is. As long as I can so-called "customize" my system by installing any of these programs that Dell is installing, I'll be fine. You don't need to buy a Dell computer to get certain programs though, unless they're the only provider and they aren't open sourced and you can't buy just the program from them, or unless you simply want those programs to be default. I'll take anything over Windows when I buy a complete computer, since I don't use it, and certainly having a good default program selection is a perk if that's the software you want.
Hmm, that's interesting and seems to be pretty good, but of course in a way I guess it's a little more "top level" sorta than the LSB Packaging solution. Or, well, maybe it would achieve the same thing but since the LSB is, well, the LSB, it will probably have good adoption and it seems that quite a few things may get addressed with it. The OpenSuse Build Service still needs to take specific distros into consideration, but after the LSB Packaging standard is finalized, it should level the playing field completely so that no annoying distro-specific crap has to be taken into account while packaging, since those things make packaging difficult. The LSB API should have enough information to easily allow any package manager to be able to deal with packages correctly on any system, provided that the solution is robust/extensible, etc, which is of course what everyone wants to make it be.
Don't get me wrong, I'm rooting for any and all solutions, but while not knowing too much in detail about what's out there, I would guess the LSB solution will probably be what will eventually be the solution, I just hope it won't take too long to do so. Until then, when and if that happens, these other projects can try to fill that spot but I just don't know if I'll be able to shake off the feeling that it's duct tape until the LSB solution arrives to wield it all together. ^^
Intel, how about supporting the LSB Package project so that once solidified will allow systems to install both RPM and DEB packages, as well as any others. Once software is easily installable cross-distro, distros will be reduced to mere collections of specific software, and you won't need to make silly decisions like that based on formats because any format will be possible.
Take a look at, and help with, the Burgdorf Packaging API, the current proposed solution in the making.
Oops I meant I help with those things, with open source projects I mean. :)
That's easy to solve. The whole point of an API is to allow a compatibility layer so that B can always communicate with A. If done right, this layer can be easily extensible to allow the adoption of new ideas and better ways of doing things. If there are certain things that the kernel absolutely must need to have in order for this compatibility layer to function, this minimal set of kernel requirements can be deemed LSB minimal. That way, driver developers can have a nice API to develop for and they don't have to worry about incompatibilities. It's the same way with anything else, like OpenGL for instance, or HTML, or any other standard. There's so many ways of helping to implement this, it's completely possible to do.
Yes, the NDA way is another solution as well, but the above API would allow an NDA to not be needed. These companies wouldn't have to trust any third-party developers with an NDA, it would allow them to do it themselves easily. Like I said, the more solutions that Linux can bring to the table, the better. The more it will help with Linux adoption. Anything that helps a small part of Linux will also help everyone else using and developing for Linux, that's the beautiful way Linux works. If you make it easier to install drivers or software or anything, it will help everyone, it's great. ^^ So, it's just a way in which Linux could improve itself, and that's good for all. I prefer open drivers just as much as anyone else as it helps with many things in many ways, but having a closed driver with in-house development is an option which some companies would choose, so it's an option that should exist for them in an easier way than it does now. Linux software development = hard = less Linux goodness. Linux development = easy = more Linux goodness, is all I'm saying.
Sure, open sourcing Flash would make Flash much easier to bug fix and you'd suddenly have all the improvements that open source has, I agree. I'm not arguing against open source, but I am arguing that allowing closed source on Linux or allowing users to even use open source drivers and to easily install those drivers without having to compile them first, will help both open and closed source projects and companies. There will still be demand for Adobe to open source Flash, that will never and has never gone away, hence Gnash and Swfdec and such. That will only continue, as open source software carries very visible advantages. Again, it's just that there are advantages, and it's good to have the option, for users and companies to install binaries easily. It will allow open source projects to function more easily with Linux, it will allow users to not have to be compilation geniuses, etc.
Any way, I still want open source software versions of everything to exist and I hope with those things, but I also want easy ways to install all software to come to Linux. It will help everyone to see that happen more.
OTOH, the last time I bought a bit of hardware that claimed Linux compatability on the box it was a big fat goose egg. The alleged support was for a binary driver for a particular kernel. Getting it to work with Linux would have been more trouble than I wanted to deal with (nevermind the average consumer).
:)
Right, so someone needs to develop a stable but extensible API for Linux kernel driver installation so that you don't have to recompile everything, or they have to open source their drivers, or create a mechanism to automatically compile a kernel module. The last solution is a pain in the butt, the middle solution is ideal for consumers, and the former would help having for the companies that want to play hard ball, so consumers have the option of using binaries instead of having to recompile, and so Linux can have true "third-party" driver support without these parties having to kiss the kernel dev's toes.
Any ways to increase Linux's modularity and capabilities while adding stability and improvements through extensibility are good, and will help with Linux's adoption rate. If that means closed-source companies can more easily target Linux, so be it, it won't stop me from wanting open source solutions and more both open and closed solutions will come with the increasing adoption. All users will win as Linux becomes more powerful, customizable, flexible, and modular.
ATI cards might end up with a penguin logo but I'm not sure I would want one for any OS.
Sure, and that's exactly what I'm talking about. You have the option to use nVidia's cards for 3D programs for instance because they provide a closed source driver. You have a choice. I myself will buy ATI if I start actually seeing all this promised open source support actually come about. It would make it easier for nVidia to have better Linux driver support if the Linux kernel supported APIs for binary drivers. They wouldn't then be forced to include stuff to build the kernel driver on the fly, and upgrading your kernel wouldn't hose your system if you manually installed their driver, causing you to have to reinstall it. If Linux gets some stable API for drivers, which is completely possible to do in a satisfactory, extensible way which will not hamper any kind of technological progress (on the contrary, will allow speeding it up by giving this modularity), it will really help to improve the driver installation world for anyone wanting to install drivers which are outside the kernel and repositories, and with the development of a good packaging API will also allow these OEMs to only have to create a single package to register itself with your package manager, removing the need for manual installation completely and allowing for easy system upgrades straight from the OEM.
Aah, Sourceforge being one big cross-distro Linux repository, I can't wait.
Because most of the people read the boxes for Windows support? Not anymore. It has been accepted that, whether there is a nice Windows logo on there or not, it will work with Windows unless it says "For Mac" or is made by Apple. Linux will be the same, no need for fancy logos, etc. Though I do try to buy things that have Linux on the system requirements (such as flash drives, all will work with Linux I know, but I would rather buy the one that specifically mentions it, vote with your wallet)
:)
Yes, but in this case Linux doesn't always have out-of-the-box hardware support with some things especially if they are "extreme" peripherals, like, say, tablets, webcams, VFDs, and remotes. I think right now it would help Linux out to have Tux on the boxes not only to ensure compatibility, but to also advertise for Linux. Microsoft pushed very hard getting massive Vista logos on everything, so I hope it'll happen to Linux too eventually.
But the thing is, if they would just release the specs for the hardware, even under a NDA, someone could write a kernel driver for it, include it with the main kernel and all would be good. And there are a lot of people that are willing to do it. And I honestly don't want to do what I have to do with Windows and that is install some driver, which installs some proprietary application to do something that should be done with a generic driver for things such as printers, USB drives, etc. And it is really bad if you lose the CD that comes with it and then have unusable hardware... So, in the way, free reversed engineered drivers are slow, but they are better than the super-proprietary, niche drivers that the manufacturers want to give us for No-Good-Reason (TM).
But it doesn't always happen, companies aren't always willing to do this, so like I said, if a way is given to these companies to go either the open or closed source route for drivers, there will be more options, and thus there will be more Linux support. That will in no way prevent Linux users who want it to push for and use only those drivers that are open sourced, and it will help them get more attention because their platform will have more attention. In other words, any kind of support for Linux will help all Linux users in some way. If Linux had 90% of the market right now, there would be that many more developers out there with an interest in writing software for Linux, both closed and open source.
No one wants to install crapware on their system, but having the option of either installing crapware in order to use some piece of hardware, or not being able to use the hardware at all, there are many users out there who would choose to use the hardware any way. If you want to not use it because it's not open source, or because it installs crapware, that's great, that's fine, it's up to you, and I wouldn't like it either. The key is that you always have a choice, and my point is that the more choices we as Linux users have available to us, the better, period, as it increases adoption which increases development which increases our choices further. Don't get me wrong, I love installing Linux and having most everything just work out of the box, it's one of the great strengths of Linux, not that other OSes don't have a lot of included driver support as well, but having the choice between, say, a working Wacom tablet so that I can draw, and no working tablet at all, I'll choose the working one. The ideal choice for me and any user who cares about openness is an open source driver, but it's nice to have a proprietary driver rather than none at all when you're stuck without a perfect solution. The open source drivers already have the advantage of being plug'n'play since they're already included. Besides, the kernel developers should not have control over everyone downstream, you shouldn't have to kiss their toes in order to get your driver to be included, so having an API there in order for anyone to be able to add a driver to their system
First I just have to say, awesome journal. Thank you so much for promoting cross-anything usability. In order for everyone to have access to all software, having that software use modular/extensible APIs/ABIs so that they can always function in the best way in any environment is very important. The Freedesktop project is very important in helping to bring more interoperability to the Linux system, so I wish them all luck in this struggle. It'll be amazing when a way can be found to make any program have the look and feel of the native desktop or whatever user-defined look that they want, and when configuration files and data can all be stored in similar locations, like just off the user's home directory, instead of being buried inside .kde or .gnome. Heck, I'll be happy when my KDE program menu icons start displaying correctly in Gnome.
:)
While it's fine and great that Ubuntu has become a noticed distro, I'll be happier when "Linux" becomes more common. When you can download virtually any distro and it will simply be a specific selection of Linux software, but you can go out and easily download and install any Linux software or drivers you want. Then, it won't need to be "Ubuntu", it will just need to be "made for Linux". Some distros may not be concerned with cross-distro software portability because they have an interest in users coming to them for help, instead of to the actual upstream providers of the software, since some of these distros are based on wanting to create a need for support. However, just like not having desktop standards hurts everyone, not having easy cross-distro software installation does the same. Fortunately, there are projects like the Burgdorf Packaging API which are working on solving this issue, as well as more top-level solutions like Zero Install, and of course both of these projects could use more support from everyone.
But with Ubuntu you don't need that just about everything will work without any configuration.
You're right to some degree there, however the parent's point about penguins on the boxes is a huge problem. For Linux to be "easy", it has to have hardware which tells consumers that it's Linux-compatible. But the thing in the way of solving that is Tux's catch22: "Linux won't get support until it gets widely used, but it won't see wide use until it gets support." The problem is being solved, it's just slow. Even the supposed thing with ATI/AMD releasing their new graphics cards, the Radeon HD 48x0's, that would have Tux on the box never happened. Disappointing. However, since driver installation is still insane on Linux, it's not too surprising that manufacturers don't support it better. If they had a kernel module or API which OEMs could use for quick driver installation so you wouldn't have to compile or reinstall your driver for every kernel upgrade you went through, and could also provide an install package that could register itself with the most common package managers out there by using a universally accepted packaging API, then I think you'll start seeing that happening more. Examples of this effort include the Burgdorf Packaging API here. (Before someone says it, yeah I know giving it to the kernel devs to have them package it for you is another option, but Linux needs to be modular enough to allow either method to occur. Anything that helps adoption by helping easy installation is a good thing, and will increase Linux's adoption, and that's all I want to see happen. Users still will have the choice to use binary blobs or not, but they will have a lot more choices when Linux adoption becomes greater.)
I'm anxious to see progress with hardware support by having databases, or better yet more online stores selling Tux-compatible hardware so you never have to go to the store to begin with.
...all the old Linux users who tout things like "Linux doesn't need to do that, it works fine as it is" or "Stop trying to make Linux like Windoze" and other such crap would get a life. Linux needs is to push the envelope and adapt to new ideas. It's for everyone, so if someone is having a problem, they can and should resolve that problem, always, period, and there's always a way to do it with software. What it all comes down to is every user deserves to have Linux do what they want and need, the only question is finding others who agree with you and can help get it created. Linux needs change, so it's sad to see visions being bashed.
I'm anxious for the Linux user base to increase, as it means more new ideas can be introduced, and the percentage of users saying "you can't" will be replaced by those saying "how can we".