Linux - NewsThis forum is for original Linux News. If you'd like to write content for LQ, feel free to contact us.
All threads in the forum need to be approved before they will appear.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Following a contest."The Great Linux Desktop Migration Contest asked for entries in three categories: write an essay on the Benefits of Migrating to Linux; present an example of a Phased Migration Plan; and give us three Tips for Migrating." resulted in very good tips
some of the tips by the winner of the contest David D. Scribner
Before migrating any workstations over to GNU/Linux and the plethora of tools and utilities there, install cross-platform basic applications on the Windows workstations. These would include OpenOffice.org and Mozilla/FireFox at minimum and should be configured to replicate the users' setup for Microsoft Office and Internet Explorer (templates, configuration [paths, to name one], import Favorites, and so on). Also, configure areas of advantage
Give employees training on the new applications, detailing how they can use them to accomplish the same tasks they achieved in the past. The training, which can be one-on-one or as a group, also gives you the opportunity to expound on why the switch is being made: to thwart vendor lock-in
the full article with more details and other tips can be found here
yes,what i too had been thinking was , that desktop is the only area which is making linux to stay behind other OS, there is no question over the stability of linux in the role of differnt servers .all these linux distributions need to focus more on desktop to attract home users to linux .
I think that once a few Linux distributions find that very fine line between "user friendly" and "power-user friendly", it'll really take off. For now, I think it's mostly up to those who know how to configure a nice Linux system to make it easy to use for those who we can talk into giving it a try.
I think that this presents the issue of 'OS forking'. What I mean by this is that to gain greater market share (ie a larger user base) then the desktop distros need to be geared towards the 'inept user'. I beleive there are some already which do this. But the problem arises that the differences between distros for power users and distros for users with little techie experience who may not be willing to learn and just want simple applications which get their job done, may widen to the point where they are effectively different OSes. I think that this may also be a very interesting time.
If in a perfect world linux took a majority market share then there would probably be an explosion of new distros. If they all 'evolve' from similar beginnings and change until they are effectively different OSes then it may show a parallell to evolutionary theory. What exactly defines an OS? How much does an OS have to evolve from it's base OS to become an OS in it's own right and not just an adaptation of it's base? The obvious answer is the kernel, the thing which all linux distros have in common. But there are many variations of the kernel in use even today. Some which come tailored for a specific distro, or some which individuals modify to suit their particular needs.
Even though each distribution uses essentially the same kernel with different options enabled by default, it's already apparent that despite the gross similarities between distributions in many cases software made for one is not compatible with another without being seriously tweaked. This became apparent when I made the switch from Red Hat to Mandrake to Slackware. Many of the RPMs that worked on Red Hat didn't work on Mandrake, even though they're essentially the same distribution with different appearances. Also, most of the source code I downloaded wouldn't work on Mandrake or Red Hat due to their relatively less "standard" directory structures and configurations, while almost every source file I've downloaded compiles and works just fine on Slackware.
I can forsee some point in the very near future, as distributions move farther and farther away from using compiled-from-source software towards proprietary package modules (RPM, DEB, etc.), it will become quite necessary to download binary packages exclusively in order to make sure that it'll work on your particular distribution.
Likewise, many distributions are beginning to include non-GPL software with their packages and custom-made kernels, such as closed-source drivers. This, of course, could be very useful where no GPL equivelants are available, but it would also mean that the corporations that own the software could, to some degree, claim the distributions including it to be their own. (And then we have distributions like Suse that are being bought-out by large corporations.)
I think that while using strict restrictions on the Linux Standard Base will definately go a long way to preserving the continuity and cross-compatibility of Linux, setting some standards on directory structure and system configuration file setups, among other things, is necessary in order to keep Linux from forking too severely.
The issue of non GPL software being included is probably inevitable as GNU growth continues and private enterprise begins to see advantages in developing for the platform. Some small to mid size development houses may have trouble adapting to the open source model. The traditional mode of operation where the company liscenses it's code to users is possibly hard to let go of. Some developers may add unnesesary complexity or engineer problems to ensure revenue for support. Is it feasable for a small software development company to operate under the GPL liscense where they receive revenue only for support? All the examples which I have seen of success using the open source model have been fairly large operations.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.