Oh and one more thing, things are changing, modular programming is becoming more and more popular thankfully. Just so you know. But, things still need more work, and certain companies may not be so eager to see it happen as some companies are competitors. Programs and companies should compete, but everyone's freedom should not suffer because of it, it should not make things more proprietary. Open source is all about working together (at least, often it is) to create great things, but that spirit doesn't have to always exist with open source software, so everyone should know what things limit their freedom.
"...because apt-get developers already thought about it and they still thougth their way was better..."
You're talking about differences between programs. You're on the wrong page. I'm not saying there shouldn't be differences between programs. I'm saying programs should try to use the same interfaces where possible and not just user interfaces if and where desired/able, but inter-program interfaces too, because you should use standardized things where and when possible to make your programs modular. To use your example of apt-get and yum, the interface, i.e. "yum install ", could be the same, or even better if you just make universal system commands like "install" then you could simply make it "install ". Then, for the flags, you could have them use the same names or have aliases for some or whatever you wanted, because that front end is just a simple indexing searcher. Any way, it's entirely possible to do something like that and have it become something universal and part of every system. Then, on the back end, you can use whatever the hell you want to use and the back ends can directly compete. Their quality wouldn't be determined by how difficult the front end was to use. I could use apt-get commands for yum repositories, for example, which I'd love to do because I hate yum's search ability/method. Even if you don't want the same front-end commands, you can standardize it so that it uses the same inter-system communication methods. The one place I know yum doesn't is of course because it is only compatible with RPMs, and not DEBs, and apt-get only is compatible with DEBs and not RPMs. This drastically needs to be changed. You should be able to install DEBs and RPMs on LSB-compliant systems if those packages are LSB-compliant (yes, I know DEB isn't defined in the LSB but it should be because it's just a format).
So, standardize the front ends or whatever interfaces could use with some standardization, or the "languages" or protocols or whatever, and make all the stuff in between completely modular. It's also called a "framework". That's how your internet browser is. That's how any "client" and "server" is (to a greater or lesser degree in some instances though, especially where DRM is used). The FTP protocol gets standardized? Great, now you have lots and lots of different FTP servers and clients that are able to compete with each other because they all communicate using the same protocol. The data is different that gets transmitted, the servers and the clients are all different, but they all use the same powerful protocol.
Standards are good as long as they are scalable and don't lock you in. You may not like them to occur in some areas with some things, but in many areas they are very important, and like I've stated in posts in this thread there are lots of good reasons for making your program as modular and cross-platform and cross-everything as possible.
Exactly right on all accounts. (see my reply to parent also if interested) Everyone should be concerned about bringing "systems" together, because as you do that you bring users and developers together, and make learning and life easier for everyone. I'm happy that there is a growing interest in keeping things modular so that we all have more freedom. It's one of many things that will help to make Linux more powerful, too, but it's simply intelligent programming. If I go to write a program to do something, say, make some sort of widget for the Linux desktop, one of the first things I would look into is how is what I'm doing "normally" done, and what kind of system exists that I need to interface with. I'd look at the current standard that is being used for these desktop widgets, and if I felt the standard was horrible and needed more "language" added to it to allow more powerful commands or whatnot, I would make those proposals and try to work that out until I clarified the standard so that I could do what I needed to do and move on from there. If the standard was built correctly, it would allow scalability for awesome improvements to be added onto it, or it would be such a perfect one that programs would be able to do anything they wanted to basically in a simple, quick, effective way. Doing all this ensures
1. Your program gets more use. 2. Your program can be swapped out for other programs. 3. Your program will always play nicely with the way users have their desktops set up, for example it will use the buttons and colors that the user wants their interface to use instead of forcing upon the user the choices of the programmer which is simply more respectful unless the programmer believes that there is a big need to define their own. 4. Your program can be shared easily and used on any system, which in turn makes it more widely used. 5. Because of it's wide use, more developers and community support will be available to continue and help you improve your program, in turn giving more power and freedom to everyone. 6. Everyone will have more freedom as an effect of your smart programming. and probably a lot more...
I think you misunderstood the way I truly meant my post. I'm not saying to make everything the same. Far, far from it. I'm saying that the common *interfaces* could be made the same, so that things are *modular* and can be more easily swapped out for *other* things, giving users more freedom. If I have to install OS Y (avoiding OS X jokes) in order to get program Y to run, and can only use OS Z to get program Z to run, that's not freedom, that's lock-in. I'm being locked in to this one particular OS to use this program. To reduce things like that, you can put an ABI/API in place so that both programs will run on either OS, even though the programs and the operating systems are different. This concept of having some kind of common method of communication is really what I meant by my post. How far to take it though is an interesting conversation.
I think it would be a pretty cool idea to make it so, for example, all mail programs whether Exim, sendmail, etc used the same points of communication so that users would not have to learn each system. You make one command called "mail" and it can issue standardized commands. Next, the developers of mail programs make it so that their program can understand and interface with the standard. If the standard lacks in any way, improve and/or add onto it. Sure you can make other programs that interface with JUST Exim, but isn't it nice when a program or plugin can be used for more than only one other program or on more than only one platform, etc?:) It's just smart programming is all. Setting things up for interoperability and modularity is becoming the trend, and I'm very happy to see things heading in that direction. More freedom for us all. Not to mention more free time, since we don't have to understand how to use 100,000 different programs/systems because each is so completely different.
P.S.: Did I mention I really don't want to see Linux fragment like Unix did? If you want a good example of lock-in, look at the history of Unix. Sure, if everything is open source that helps tons, but lots of fragmentation of different sorts can still occur, and users and developers should be aware of such things as it effects everything about a program, how widely it gets adopted, how it gets used, etc.
Which is why everything needs to stay on a common standard communication interface while behind-the-scenes system reformation is allowed to occur, and entirely new features are tacked onto the interface as additional settings or new commands, ensuring backwards compatibility.
There is no point in using a completely different interface for two things that do the same thing though, and going back to the topic Upstart is supposed to be "compatible", though it'd be nice to use an identifier/name and flags that didn't change and were uniform so that scripts and the like wouldn't break. I believe Linux could be completely seamless between most all distros if the communities would pull harder at developing standardized interfaces (something that I'm very surprised doesn't occur much more within communities who claim to understand their importance), and the companies would stop trying to pull things in opposite directions, towards fragmentation/proprietarization.
I hope one day us Linux users will actually have the freedom to use whatever system we prefer on whatever "distro" we prefer easily, reducing "distros" to mere package and configuration "groups".
Unfortunately OpenMoko isn't quite ready with the Neo phone, and after unlocking an iphone it can do quite a lot of things, possibly more, when compared to other *existing* phones, but more importantly to me it seems to be one of the most "open" phones that is consumer-ready right now. As soon as the Neo is ready for actual use though, my iphone goes up for sale. I really hope OpenMoko and any other open source mobile projects will have great ease of use so open source can compete well with the iphone.
Not to mention I'm pretty sure several interests have it in for making things more bloated. Hardware vendors profit from "needed" upgrades, and software vendors profit from upgrade treadmills. It's all a very nice game for them.
Oh, and don't forget the lazy programming and crapware that also aid in bloat.
To prevent Linux from following the same path, we just need to make sure software is easily portable so it can be properly competed against. Don't like how slow your distro is running? Replace that bloated app with something else, or get rid of it. Keep a modular, scalable infrastructure and Linux will p0wn all.
Actually I think there are Linux programs available for most all the things you mentioned, but you're right that they are few in comparison. That's why more software companies, teams, and individuals need to port code, or write Linux apps from scratch.:)
More standards and support systems would really help though, especially a universal method to install any Linux app on any Linux distro that supports the standard/system/filetype, I think just that would go a long way in helping things. Everyone should be worrying about improving the kinds and quality of apps, and that can't happen unless it's simple to share them between Linux systems. Want me to send you an app over IM? Oh that's right you don't have dependencies X, Y, and Z like I do, guess you're hosed and need to spend 3 hours trying to recompile and find everything you need.
On the NetMeeting thing though, Linux needs a good video device API for apps like webcamming programs and video editors and such. At least now we have PulseAudio to make sound easy and powerful for apps, and it's compatible with some of the existing Linux sound APIs, but we still need that awesome video API and server system to go along with it (perhaps extend OpenGL?).:)
Oh I completely agree with you on the reasons software patents are ludicrous, but I just wanted to add my reasons for patents in general being ludicrous too. I think there's a lot of evidence to support that.
The bigger problem is that most all patents, at the very least, don't help progress. Companies by nature should be trying to compete with one another, but when patents come along they help companies turn themselves into monopolies, or the monopolies that exist snatch up the patents with their deep pockets, helping them to become bigger monopolies. Ideas should not be controlled by monopolies, whoever has the most money, and that's essentially the system it creates.
Let the companies figure out in their own ways how to get consumers the next best product that they want because a demand for it exists. It's called competition, there will always be a way to create things and as technology progresses this will become even more painfully apparent and the patent issue will become an even bigger blight as information is more freely shared.
The patent system only encourages an abuse of power, get rid of it.
Several nice additions. The thing I'm looking forward to the most is the webcam application. What would be even nicer though perhaps is for other programs (and maybe they can) to be able to use this as a "video device stack" or for a stack to be created, so that programs can much more easily adopt webcam support along with other video devices. This would greatly help out any video editing programs and IM clients (maybe webcam support for Gaim finally?).
Still, I dislike talking about these apps in Gnome-centric fashion, since all apps should be DE agnostic. It's fine to bundle them by default in your DE though, and if the development group is primarily those involved with the DE then fine, but it's still a bit silly. A better article would be "New neat programs, all to be included in Gnome!" or whatnot.:)
And I should know, I'm fortunate enough to be in one of those jobs that is 100% Linux, but I agree that learning several kinds of computers/OSes can certainly be helpful.:)
Have to watch out for those companies that try to change that by using terminology which is only applicable to their own software though, but I've never really seen this strategy work very well as everyone hates it or ends up simply learning aliases.
Which is yet another reason why a universal packaging API is needed more than ever. You can't just rely on source code, because not only is it not always available but often compilation and dependency hell can be a particularly frightening nightmare.
No program for Linux should be difficult to install/run on an LSB-compliant distro, or how about any distro that could use an intelligently-created automatic dependency downloader/installer. For the sake of Zeus, FSM, that guy on the cross, yourself, or whoever you believe in, someone(s) need to fix the Linux 3rd party software installation difficulty problem once and for all so that maybe THEN we can have a year of the Linux desktop finally.
Want to back up your Linux programs to a server or to disk? Good luck installing them on any distro they weren't *meant* for later on. I know Linux users love to say Linux is Linux, but with these kinds of problems it is only remotely true. Fight this proprietarizationness crap with modularity, APIs, and an intelligent system that WORKS.
(Yes, proprietarizationness is a word, with correct spelling, because I have decreed it so in my own dictionary, which I have not yet published yet (and never will).);)
So you're saying this term isn't real because you ultimately always have a choice http://en.wikipedia.org/wiki/Vendor_lock-in, I should stop bitching about laws in the US because I have the choice to leave this country, and you should stop worrying about curing cancer because anyone with it has the option of suicide. My point is that you missed the point. It's not white or black. Things can be made better than they are now. But you are aware that software packaging is a problem apparently, which is good, because that's the only point I'm trying to make here. Whether the answer is as extreme for everyone using Ubuntu and Debian to suddenly all switch to Red Hat, Fedora, or CentOS, or the answer is for those distros to start using RPMs, or (a much better solution) a common API for the package managers is used so that you can install both RPMs and DEB packages with no problems out of the box (I hope the Linux Foundation can help to come up with a solution), something DOES need to happen, because it IS a problem for lots of reasons that I haven't even mentioned yet and if you read that link I sent you you'd read about all the things that are needed but aren't provided currently. I'm trying to give you the hint though that being thick-headed and ignoring that there are current problems with it isn't the solution. I can think of lots of features I want to see added onto a packaging format, and I want to see the formats compete, so I can't wait for a new API allowing this to happen. Also I'd like to see one extension,.LNX or something, to be created as the container format for these formats, then having RPMs and DEBs be sub-formats, among other things. I have lots of other ideas too, there are lots of things that are needed here to make packaging in Linux a snap.:)
Also, didn't you heavily contradict yourself? You probably think that OpenGL is great, and you've already proven to me that you believe standardizing on RPM and the LSB is what we should all use, so you believe in pushing standards apparently, yet you seem to believe that any standards means somehow Linux is no longer free and that we're all in some prison where we're forced to comply. That's messed up, and backwards. Having standards gives us the freedom to be able to share things and communicate on the same frequency. You are using countless standards as you read this, from HTML to other web compliance standards to the software you run and the APIs programs use to communicate with each other, down to the hardware and the common standardized slot types and architecture standards, and even lower to the standards of electricity so that all the playing fields are level and things can compete in the same arena. That's what big corporations don't want. Do you think Pepsi and Coca Cola want you to be able to choose between them? No, they want to pay off the company owning the land and have them sign exclusivity agreements so they can eliminate the competition and thus drive up prices and make a huge profit. Do you think Microsoft wants other operating systems in stores next to theirs, or for computers to come without their OS forced down the throat of consumers, not even having the ability to have the software removed so they don't have to pay for it? I don't mean to be rude, but if you think having standards and a level playing field for competition is bad, you need to wake up. Yes, of course some "standards" could use an improvement, and you know the best way of doing so is by pulling back one level and allowing something to simply be compliant to a standard, so that the competition has room to step forward, and then competition can occur like it should be able to.
There are literally a million examples I could give you, so I'll stop there. Linux standards are good, allowing users to share programs easily that they have created. Right now, that is not done in Linux as much as it should be and there are reasons why and lots of
There is a problem with the current state of packaging in Linux. It shouldn't be so difficult, not only for end users but for developers. Common APIs need to be created so that packaging formats can compete and developers and users can have easy access to a simple system that does the things they need. OK, so RPMs work, why is it then that they are often not available? Maybe it's a format that could use some improvements, but regardless of the ease of use or power of RPMs, depending on one type is silly. The fact is, RPM isn't as common as it could be, regardless of the reasons for that, and that's a pretty critical part of the "Linux platform" for developers wanting to port or create programs for all LSB-compliant distros and for users wanting to just get to their programs without any fuss.
What defines a system should be the APIs so that you have modularity instead of being locked into one kernel, program, library, or format type.
I'm talking about proper support, not theoretical support. The fact is installation often fails a lot of times when trying to install packages outside the repos. There needs to be a universal format that just works, like Windows and Mac have. I wouldn't mind if there were multiple formats, that's fine if there are RPMs and DEBs and Autopackages competing for the spotlight, competition is vital, and you can have that competition if you have standard APIs with the package managers for package formats, but each of those formats need to be able to correctly install themselves on LSB-compliant systems before non-repo software installation as as easy as the aforementioned OSes.
I wish everything was modular like it should be, so "Linux" was a single "platform", and that it didn't matter what distro you were running because it was merely an certain selection of packages and nothing more, and if you liked the good things about one distro but not others, you could install those good things on your own distro.
Linux desperately needs modularity and a universal package management system, so it won't fragment and die like most of Unix.
I'd pay money to get a completely unrestricted piece of software. I'm glad things are moving toward software as a service, because I think it's basically a major part of the solution, but needs much better integration. You're right though, there are some good open source methods of paid development, but like I said there isn't anything very "direct" yet except donations, which IMO are scary and unsafe.
Correct, people would be able to not share, or share, code. They wouldn't be forced by copyright law to share, nor would they be forced not to share. So both "sides" would have their copyright law "fortifications" torn down, and would be back on equal footing. Would there be less code publicly posted in such a world? Not sure, but at least you'd still be able to do so, and you wouldn't have to worry about any annoying legalities about copying, which in essence is a pretty childish concern, because I feel the world should create new ways of propelling software creation without using laws to do so. A true laze-fair economic system. You may tear down some of the collaboration, but you'd tear down the monopolies, too. I think in such a world there may be a good chance there would be more collaboration, since like I said, they would seek new ways of development which can only be done by collaboration. I can think of many ways this could happen, but the closed source industry doesn't seem too interested since they have their copyright laws, and the open source industry doesn't seem too interested because they aren't very interested in seeking hard, direct financial support methods. It's like everyone goes around with blindfolds on because it's how it's always been done in the past. Where has the creativity gone...
Public Domain gives the ability for someone to use your code to restrict someone else's freedom. If you're OK with that, great, thanks for sharing your code regardless, and use that license. If you aren't OK with that though, you may want to use the GPL. If you're partially OK with it, and want some things but not others to be allowed, then pick some other license in "between", but the GPL tries to make sure maximum freedom is kept for everyone else down the line in a balanced and equal way. It's not freedom to take away someone else's freedom, it's freedom for everyone in an equal and respectful manner, that's it's goal and I think it comes real close to achieving that.
I'd love it if copyright was destroyed, but regardless, yes, you are free to contribute to code that companies can use and give nothing back for using, or you can ensure your code remains open and worked on openly, it's up to you. Regardless, thanks for sharing it.:)
Well I don't know if things can be EEE from Public Domain, but they could certainly make their own software from it. More to the point though, if you are a developer who is thinking of releasing your code under Public Domain...why? Why would you want to see your code in a restricting program? How about contribute to projects that give users freedom instead? I mean sure you could say that if you have restricted software that it's better than nothing I guess, but why not contribute to organizations that provide support for truly free programs instead of allowing the restricted ones in?
It's beautiful that your software can limit the freedom of others? OK, if you say so...but I don't understand why you'd think restricting the freedoms of users would be a good thing. Public Domain may be "elegant" in that it has very few words, allowing it to be used to restrict the freedom of others. The GPL is elegant in that it prevents that from happening. It just matters where your priorities are. If you would be perfectly OK with a restrictive piece of software being developed using your code then fine, if you'd prefer that your code stays in friendlier software then IMO that's even better.:) To each their own. Thankfully, users don't have to use those restrictive programs, and I and other consumers prefer software that offers full freedoms would rather pay for and help out it instead.
Wow, this topic always comes up and gets rehashed over, and over, and over...
The best software is one granting maximum freedoms to everyone. If users use software that is closed, it is a risk to them, it makes them reliant on the provider, it is no where near as friendly and does not provide them with complete freedom. No matter what your views on GPL vs. Public Domain or whatnot, this fact remains, that the world is a better place if we all have freedom to fully control the things we use. However, is freedom limited? Notice that I said fully control the things we use, and not free to do whatever the hell we want to. If you were free to hurt others, for example, they would not be free. Our freedoms are restricted to when they interfere with the freedoms of others. In other words, we need to have equal AND positive, caring respect for each other, is what is truly meant by "freedom". Freedom as in the freedom to take away the freedom of others is Public Domain. Freedom as in freedom equally for all is the GPL.
Yes, you could say that true freedom is one in which users are allowed to restrict themselves, and if you want to contribute to a project that makes that possible, use Public Domain. Or, make your software closed source. It does, after all, provide a "quick and dirty" way (because it's not that great of a way) to get money from people to pay for development using copyright law. However, if you want to contribute to software that will always grant users maximum freedom, the right kind of freedom, then you may be more interested in the GPL. There are ways of getting funding for development of such projects.
It's buried very deeply on Dell's site. It may as well not exist at all for most consumers. They will have no idea where to look. What my argument is is that there is NO reason whatsoever for Dell and all the others not to offer a "No OS" option, at the very least, and the effort they'd need to put forth by offering Linux is extremely minimal, as minimal as they care to make it actually to the point of not offering any support whatsoever, even though there are many companies that would love to do support for them.
Slashdot Mirror
Oh and one more thing, things are changing, modular programming is becoming more and more popular thankfully. Just so you know. But, things still need more work, and certain companies may not be so eager to see it happen as some companies are competitors. Programs and companies should compete, but everyone's freedom should not suffer because of it, it should not make things more proprietary. Open source is all about working together (at least, often it is) to create great things, but that spirit doesn't have to always exist with open source software, so everyone should know what things limit their freedom.
"...because apt-get developers already thought about it and they still thougth their way was better..."
You're talking about differences between programs. You're on the wrong page. I'm not saying there shouldn't be differences between programs. I'm saying programs should try to use the same interfaces where possible and not just user interfaces if and where desired/able, but inter-program interfaces too, because you should use standardized things where and when possible to make your programs modular. To use your example of apt-get and yum, the interface, i.e. "yum install ", could be the same, or even better if you just make universal system commands like "install" then you could simply make it "install ". Then, for the flags, you could have them use the same names or have aliases for some or whatever you wanted, because that front end is just a simple indexing searcher. Any way, it's entirely possible to do something like that and have it become something universal and part of every system. Then, on the back end, you can use whatever the hell you want to use and the back ends can directly compete. Their quality wouldn't be determined by how difficult the front end was to use. I could use apt-get commands for yum repositories, for example, which I'd love to do because I hate yum's search ability/method. Even if you don't want the same front-end commands, you can standardize it so that it uses the same inter-system communication methods. The one place I know yum doesn't is of course because it is only compatible with RPMs, and not DEBs, and apt-get only is compatible with DEBs and not RPMs. This drastically needs to be changed. You should be able to install DEBs and RPMs on LSB-compliant systems if those packages are LSB-compliant (yes, I know DEB isn't defined in the LSB but it should be because it's just a format).
So, standardize the front ends or whatever interfaces could use with some standardization, or the "languages" or protocols or whatever, and make all the stuff in between completely modular. It's also called a "framework". That's how your internet browser is. That's how any "client" and "server" is (to a greater or lesser degree in some instances though, especially where DRM is used). The FTP protocol gets standardized? Great, now you have lots and lots of different FTP servers and clients that are able to compete with each other because they all communicate using the same protocol. The data is different that gets transmitted, the servers and the clients are all different, but they all use the same powerful protocol.
Standards are good as long as they are scalable and don't lock you in. You may not like them to occur in some areas with some things, but in many areas they are very important, and like I've stated in posts in this thread there are lots of good reasons for making your program as modular and cross-platform and cross-everything as possible.
Exactly right on all accounts. (see my reply to parent also if interested) Everyone should be concerned about bringing "systems" together, because as you do that you bring users and developers together, and make learning and life easier for everyone. I'm happy that there is a growing interest in keeping things modular so that we all have more freedom. It's one of many things that will help to make Linux more powerful, too, but it's simply intelligent programming. If I go to write a program to do something, say, make some sort of widget for the Linux desktop, one of the first things I would look into is how is what I'm doing "normally" done, and what kind of system exists that I need to interface with. I'd look at the current standard that is being used for these desktop widgets, and if I felt the standard was horrible and needed more "language" added to it to allow more powerful commands or whatnot, I would make those proposals and try to work that out until I clarified the standard so that I could do what I needed to do and move on from there. If the standard was built correctly, it would allow scalability for awesome improvements to be added onto it, or it would be such a perfect one that programs would be able to do anything they wanted to basically in a simple, quick, effective way. Doing all this ensures
1. Your program gets more use.
2. Your program can be swapped out for other programs.
3. Your program will always play nicely with the way users have their desktops set up, for example it will use the buttons and colors that the user wants their interface to use instead of forcing upon the user the choices of the programmer which is simply more respectful unless the programmer believes that there is a big need to define their own.
4. Your program can be shared easily and used on any system, which in turn makes it more widely used.
5. Because of it's wide use, more developers and community support will be available to continue and help you improve your program, in turn giving more power and freedom to everyone.
6. Everyone will have more freedom as an effect of your smart programming.
and probably a lot more...
I think you misunderstood the way I truly meant my post. I'm not saying to make everything the same. Far, far from it. I'm saying that the common *interfaces* could be made the same, so that things are *modular* and can be more easily swapped out for *other* things, giving users more freedom. If I have to install OS Y (avoiding OS X jokes) in order to get program Y to run, and can only use OS Z to get program Z to run, that's not freedom, that's lock-in. I'm being locked in to this one particular OS to use this program. To reduce things like that, you can put an ABI/API in place so that both programs will run on either OS, even though the programs and the operating systems are different. This concept of having some kind of common method of communication is really what I meant by my post. How far to take it though is an interesting conversation.
:) It's just smart programming is all. Setting things up for interoperability and modularity is becoming the trend, and I'm very happy to see things heading in that direction. More freedom for us all. Not to mention more free time, since we don't have to understand how to use 100,000 different programs/systems because each is so completely different.
I think it would be a pretty cool idea to make it so, for example, all mail programs whether Exim, sendmail, etc used the same points of communication so that users would not have to learn each system. You make one command called "mail" and it can issue standardized commands. Next, the developers of mail programs make it so that their program can understand and interface with the standard. If the standard lacks in any way, improve and/or add onto it. Sure you can make other programs that interface with JUST Exim, but isn't it nice when a program or plugin can be used for more than only one other program or on more than only one platform, etc?
P.S.: Did I mention I really don't want to see Linux fragment like Unix did? If you want a good example of lock-in, look at the history of Unix. Sure, if everything is open source that helps tons, but lots of fragmentation of different sorts can still occur, and users and developers should be aware of such things as it effects everything about a program, how widely it gets adopted, how it gets used, etc.
Which is why everything needs to stay on a common standard communication interface while behind-the-scenes system reformation is allowed to occur, and entirely new features are tacked onto the interface as additional settings or new commands, ensuring backwards compatibility.
There is no point in using a completely different interface for two things that do the same thing though, and going back to the topic Upstart is supposed to be "compatible", though it'd be nice to use an identifier/name and flags that didn't change and were uniform so that scripts and the like wouldn't break. I believe Linux could be completely seamless between most all distros if the communities would pull harder at developing standardized interfaces (something that I'm very surprised doesn't occur much more within communities who claim to understand their importance), and the companies would stop trying to pull things in opposite directions, towards fragmentation/proprietarization.
I hope one day us Linux users will actually have the freedom to use whatever system we prefer on whatever "distro" we prefer easily, reducing "distros" to mere package and configuration "groups".
Unfortunately OpenMoko isn't quite ready with the Neo phone, and after unlocking an iphone it can do quite a lot of things, possibly more, when compared to other *existing* phones, but more importantly to me it seems to be one of the most "open" phones that is consumer-ready right now. As soon as the Neo is ready for actual use though, my iphone goes up for sale. I really hope OpenMoko and any other open source mobile projects will have great ease of use so open source can compete well with the iphone.
Not to mention I'm pretty sure several interests have it in for making things more bloated. Hardware vendors profit from "needed" upgrades, and software vendors profit from upgrade treadmills. It's all a very nice game for them.
Oh, and don't forget the lazy programming and crapware that also aid in bloat.
To prevent Linux from following the same path, we just need to make sure software is easily portable so it can be properly competed against. Don't like how slow your distro is running? Replace that bloated app with something else, or get rid of it. Keep a modular, scalable infrastructure and Linux will p0wn all.
Actually I think there are Linux programs available for most all the things you mentioned, but you're right that they are few in comparison. That's why more software companies, teams, and individuals need to port code, or write Linux apps from scratch. :)
:)
More standards and support systems would really help though, especially a universal method to install any Linux app on any Linux distro that supports the standard/system/filetype, I think just that would go a long way in helping things. Everyone should be worrying about improving the kinds and quality of apps, and that can't happen unless it's simple to share them between Linux systems. Want me to send you an app over IM? Oh that's right you don't have dependencies X, Y, and Z like I do, guess you're hosed and need to spend 3 hours trying to recompile and find everything you need.
On the NetMeeting thing though, Linux needs a good video device API for apps like webcamming programs and video editors and such. At least now we have PulseAudio to make sound easy and powerful for apps, and it's compatible with some of the existing Linux sound APIs, but we still need that awesome video API and server system to go along with it (perhaps extend OpenGL?).
Oh I completely agree with you on the reasons software patents are ludicrous, but I just wanted to add my reasons for patents in general being ludicrous too. I think there's a lot of evidence to support that.
The bigger problem is that most all patents, at the very least, don't help progress. Companies by nature should be trying to compete with one another, but when patents come along they help companies turn themselves into monopolies, or the monopolies that exist snatch up the patents with their deep pockets, helping them to become bigger monopolies. Ideas should not be controlled by monopolies, whoever has the most money, and that's essentially the system it creates.
Let the companies figure out in their own ways how to get consumers the next best product that they want because a demand for it exists. It's called competition, there will always be a way to create things and as technology progresses this will become even more painfully apparent and the patent issue will become an even bigger blight as information is more freely shared.
The patent system only encourages an abuse of power, get rid of it.
Several nice additions. The thing I'm looking forward to the most is the webcam application. What would be even nicer though perhaps is for other programs (and maybe they can) to be able to use this as a "video device stack" or for a stack to be created, so that programs can much more easily adopt webcam support along with other video devices. This would greatly help out any video editing programs and IM clients (maybe webcam support for Gaim finally?).
:)
Still, I dislike talking about these apps in Gnome-centric fashion, since all apps should be DE agnostic. It's fine to bundle them by default in your DE though, and if the development group is primarily those involved with the DE then fine, but it's still a bit silly. A better article would be "New neat programs, all to be included in Gnome!" or whatnot.
And I should know, I'm fortunate enough to be in one of those jobs that is 100% Linux, but I agree that learning several kinds of computers/OSes can certainly be helpful. :)
Have to watch out for those companies that try to change that by using terminology which is only applicable to their own software though, but I've never really seen this strategy work very well as everyone hates it or ends up simply learning aliases.
Which is yet another reason why a universal packaging API is needed more than ever. You can't just rely on source code, because not only is it not always available but often compilation and dependency hell can be a particularly frightening nightmare.
;)
No program for Linux should be difficult to install/run on an LSB-compliant distro, or how about any distro that could use an intelligently-created automatic dependency downloader/installer. For the sake of Zeus, FSM, that guy on the cross, yourself, or whoever you believe in, someone(s) need to fix the Linux 3rd party software installation difficulty problem once and for all so that maybe THEN we can have a year of the Linux desktop finally.
Want to back up your Linux programs to a server or to disk? Good luck installing them on any distro they weren't *meant* for later on. I know Linux users love to say Linux is Linux, but with these kinds of problems it is only remotely true. Fight this proprietarizationness crap with modularity, APIs, and an intelligent system that WORKS.
(Yes, proprietarizationness is a word, with correct spelling, because I have decreed it so in my own dictionary, which I have not yet published yet (and never will).)
So you're saying this term isn't real because you ultimately always have a choice http://en.wikipedia.org/wiki/Vendor_lock-in, I should stop bitching about laws in the US because I have the choice to leave this country, and you should stop worrying about curing cancer because anyone with it has the option of suicide. My point is that you missed the point. It's not white or black. Things can be made better than they are now. But you are aware that software packaging is a problem apparently, which is good, because that's the only point I'm trying to make here. Whether the answer is as extreme for everyone using Ubuntu and Debian to suddenly all switch to Red Hat, Fedora, or CentOS, or the answer is for those distros to start using RPMs, or (a much better solution) a common API for the package managers is used so that you can install both RPMs and DEB packages with no problems out of the box (I hope the Linux Foundation can help to come up with a solution), something DOES need to happen, because it IS a problem for lots of reasons that I haven't even mentioned yet and if you read that link I sent you you'd read about all the things that are needed but aren't provided currently. I'm trying to give you the hint though that being thick-headed and ignoring that there are current problems with it isn't the solution. I can think of lots of features I want to see added onto a packaging format, and I want to see the formats compete, so I can't wait for a new API allowing this to happen. Also I'd like to see one extension, .LNX or something, to be created as the container format for these formats, then having RPMs and DEBs be sub-formats, among other things. I have lots of other ideas too, there are lots of things that are needed here to make packaging in Linux a snap. :)
Also, didn't you heavily contradict yourself? You probably think that OpenGL is great, and you've already proven to me that you believe standardizing on RPM and the LSB is what we should all use, so you believe in pushing standards apparently, yet you seem to believe that any standards means somehow Linux is no longer free and that we're all in some prison where we're forced to comply. That's messed up, and backwards. Having standards gives us the freedom to be able to share things and communicate on the same frequency. You are using countless standards as you read this, from HTML to other web compliance standards to the software you run and the APIs programs use to communicate with each other, down to the hardware and the common standardized slot types and architecture standards, and even lower to the standards of electricity so that all the playing fields are level and things can compete in the same arena. That's what big corporations don't want. Do you think Pepsi and Coca Cola want you to be able to choose between them? No, they want to pay off the company owning the land and have them sign exclusivity agreements so they can eliminate the competition and thus drive up prices and make a huge profit. Do you think Microsoft wants other operating systems in stores next to theirs, or for computers to come without their OS forced down the throat of consumers, not even having the ability to have the software removed so they don't have to pay for it? I don't mean to be rude, but if you think having standards and a level playing field for competition is bad, you need to wake up. Yes, of course some "standards" could use an improvement, and you know the best way of doing so is by pulling back one level and allowing something to simply be compliant to a standard, so that the competition has room to step forward, and then competition can occur like it should be able to.
There are literally a million examples I could give you, so I'll stop there. Linux standards are good, allowing users to share programs easily that they have created. Right now, that is not done in Linux as much as it should be and there are reasons why and lots of
Not just me complaining about it.
http://www.linux-foundation.org/en/Packaging
There is a problem with the current state of packaging in Linux. It shouldn't be so difficult, not only for end users but for developers. Common APIs need to be created so that packaging formats can compete and developers and users can have easy access to a simple system that does the things they need. OK, so RPMs work, why is it then that they are often not available? Maybe it's a format that could use some improvements, but regardless of the ease of use or power of RPMs, depending on one type is silly. The fact is, RPM isn't as common as it could be, regardless of the reasons for that, and that's a pretty critical part of the "Linux platform" for developers wanting to port or create programs for all LSB-compliant distros and for users wanting to just get to their programs without any fuss.
What defines a system should be the APIs so that you have modularity instead of being locked into one kernel, program, library, or format type.
I'm talking about proper support, not theoretical support. The fact is installation often fails a lot of times when trying to install packages outside the repos. There needs to be a universal format that just works, like Windows and Mac have. I wouldn't mind if there were multiple formats, that's fine if there are RPMs and DEBs and Autopackages competing for the spotlight, competition is vital, and you can have that competition if you have standard APIs with the package managers for package formats, but each of those formats need to be able to correctly install themselves on LSB-compliant systems before non-repo software installation as as easy as the aforementioned OSes.
I wish everything was modular like it should be, so "Linux" was a single "platform", and that it didn't matter what distro you were running because it was merely an certain selection of packages and nothing more, and if you liked the good things about one distro but not others, you could install those good things on your own distro.
Linux desperately needs modularity and a universal package management system, so it won't fragment and die like most of Unix.
I'd pay money to get a completely unrestricted piece of software. I'm glad things are moving toward software as a service, because I think it's basically a major part of the solution, but needs much better integration. You're right though, there are some good open source methods of paid development, but like I said there isn't anything very "direct" yet except donations, which IMO are scary and unsafe.
Correct, people would be able to not share, or share, code. They wouldn't be forced by copyright law to share, nor would they be forced not to share. So both "sides" would have their copyright law "fortifications" torn down, and would be back on equal footing. Would there be less code publicly posted in such a world? Not sure, but at least you'd still be able to do so, and you wouldn't have to worry about any annoying legalities about copying, which in essence is a pretty childish concern, because I feel the world should create new ways of propelling software creation without using laws to do so. A true laze-fair economic system. You may tear down some of the collaboration, but you'd tear down the monopolies, too. I think in such a world there may be a good chance there would be more collaboration, since like I said, they would seek new ways of development which can only be done by collaboration. I can think of many ways this could happen, but the closed source industry doesn't seem too interested since they have their copyright laws, and the open source industry doesn't seem too interested because they aren't very interested in seeking hard, direct financial support methods. It's like everyone goes around with blindfolds on because it's how it's always been done in the past. Where has the creativity gone...
Public Domain gives the ability for someone to use your code to restrict someone else's freedom. If you're OK with that, great, thanks for sharing your code regardless, and use that license. If you aren't OK with that though, you may want to use the GPL. If you're partially OK with it, and want some things but not others to be allowed, then pick some other license in "between", but the GPL tries to make sure maximum freedom is kept for everyone else down the line in a balanced and equal way. It's not freedom to take away someone else's freedom, it's freedom for everyone in an equal and respectful manner, that's it's goal and I think it comes real close to achieving that.
I'd love it if copyright was destroyed, but regardless, yes, you are free to contribute to code that companies can use and give nothing back for using, or you can ensure your code remains open and worked on openly, it's up to you. Regardless, thanks for sharing it. :)
Well I don't know if things can be EEE from Public Domain, but they could certainly make their own software from it. More to the point though, if you are a developer who is thinking of releasing your code under Public Domain...why? Why would you want to see your code in a restricting program? How about contribute to projects that give users freedom instead? I mean sure you could say that if you have restricted software that it's better than nothing I guess, but why not contribute to organizations that provide support for truly free programs instead of allowing the restricted ones in?
It's beautiful that your software can limit the freedom of others? OK, if you say so...but I don't understand why you'd think restricting the freedoms of users would be a good thing. Public Domain may be "elegant" in that it has very few words, allowing it to be used to restrict the freedom of others. The GPL is elegant in that it prevents that from happening. It just matters where your priorities are. If you would be perfectly OK with a restrictive piece of software being developed using your code then fine, if you'd prefer that your code stays in friendlier software then IMO that's even better. :) To each their own. Thankfully, users don't have to use those restrictive programs, and I and other consumers prefer software that offers full freedoms would rather pay for and help out it instead.
Wow, this topic always comes up and gets rehashed over, and over, and over...
The best software is one granting maximum freedoms to everyone. If users use software that is closed, it is a risk to them, it makes them reliant on the provider, it is no where near as friendly and does not provide them with complete freedom. No matter what your views on GPL vs. Public Domain or whatnot, this fact remains, that the world is a better place if we all have freedom to fully control the things we use. However, is freedom limited? Notice that I said fully control the things we use, and not free to do whatever the hell we want to. If you were free to hurt others, for example, they would not be free. Our freedoms are restricted to when they interfere with the freedoms of others. In other words, we need to have equal AND positive, caring respect for each other, is what is truly meant by "freedom". Freedom as in the freedom to take away the freedom of others is Public Domain. Freedom as in freedom equally for all is the GPL.
Yes, you could say that true freedom is one in which users are allowed to restrict themselves, and if you want to contribute to a project that makes that possible, use Public Domain. Or, make your software closed source. It does, after all, provide a "quick and dirty" way (because it's not that great of a way) to get money from people to pay for development using copyright law. However, if you want to contribute to software that will always grant users maximum freedom, the right kind of freedom, then you may be more interested in the GPL. There are ways of getting funding for development of such projects.
But to each their own.
It's buried very deeply on Dell's site. It may as well not exist at all for most consumers. They will have no idea where to look. What my argument is is that there is NO reason whatsoever for Dell and all the others not to offer a "No OS" option, at the very least, and the effort they'd need to put forth by offering Linux is extremely minimal, as minimal as they care to make it actually to the point of not offering any support whatsoever, even though there are many companies that would love to do support for them.