There are those who often state that Linux can "only" be a desktop thing, or that it is "only" for servers.
I teach in a division of a junior college which prepares students for the "technology" of going into medicine, biology in general, etc. A particular emphasis is placed on DNA technology and imaging.
We have at one campus, in the physics department, a stand-alone system that runs Scientific Linux and at my campus we have a stand-alone system that runs BioPuppy. The ostensible reason that we cannot run them hooked to the network is that they may be susceptible to hackers, since they are "open", but in reality it is because MS gives discounts for the schools systems and the powers that be do not want to "rock the boat".
As an example of how Linux is highly adaptable to a variety of operating enviornments, I provide the following links to articles which are quite technical, and of little interest to the general reader.
However, buried in the articles which are about using certain "algorithms" (mathematical functions) to analyze digital images of things like gunshot wounds, are references, indirectly, and directly, to the use of Linux both as a "server" and as a "desktop OS" to run the algorithms.
The gist of the subject of the articles is that these algorithms do not work on a "block" pattern, like a checkerboard, (and like the display on your digital monitor) but rather in "concentric circles". Since a gunshot wound, or a carcinoma, is not, by nature, "square" in apparance, the concentric algorithm produces an image which more completely represents the physical situation in the body.
The trick, in this case, is to set up a situation in which the application knows when enough information has been derived from the image and then stops. Otherwise it will continue to analyze the image ad infinitum, in a manner that is rather like working with a fractal.
The software itself can be run under both open source and commercial applications/OS:
http://www.jpathinformatics.org/arti...13;aulast=Hipp
However, to the reason for the post.
In this particular case it is run on a rather plain vanilla Linux OS, one example being CentOS 5.5(based orn RedHat) on a Dell server.
The particular article, which, again, is of a highly technical nature, it is provided so that the reader can confirm by using "find" that CentOS is, indeed, the OS ( year 2011).
http://www.jpathinformatics.org/arti...32;aulast=Wang
The latest mention of CentOS at DistroWatch.
http://distrowatch.com/weekly.php?issue=20120109#news
The CentOS site:
http://www.centos.org/
Below is an article at Polish Linux about tweaking the server OS as a Desktop OS which, of course, can be done with just about any Linux OS including Kubuntu if one wants to spend resources on the desktop interface, which is not usually desired in a scientific environment.
HOWEVER, since the whole of the medical field is being pushed "down" into more and more people with less, and less, education (the "clinic" at your favourite pharmacy) the need for a "pleasant interface" will become more, and more, important.
http://polishlinux.org/redhat/centos-5-free-redhat/
As a last item, this post is not advocating that people abandon ship for CentOS. It's purpose is to:
a) indicate that merely because people make certain statements, that does not mean that the statements are correct.
b) indicate that, if so desired, Linux, including Kubuntu, could be setup to run in many different operating environments, and used for many different tasks and that "commercial" is not necessarily the best way to do things.
c) offer the suggestion that the KDE desktop interface might be of some small use in the near and far term in "technical" situations.
to wit: the particular algorithm itself has an almost trivial learning curve for use. That means that the algorithm can be used by relatively untrained individuals and that the software itself will provide meaningful, and repeatable, results instead of relying on the historically highly accurate analysis of experts.
The problem en fine is that there are literally tens of thousands of images and it is necessary that some way be found to handle the burgeoning volume of information, again reference is made to the above article, this is not a new link
again, en fine... why not have a "plasma widget" that runs the algorithm.
Yes, I know, there will be cries of "Why? Why not just invoke a menu command, it would be more efficient in terms of resources and the point of it all is to run the app, isn't it?"
Well, yes......
But, again....... this whole thing will, probably, very quickly, move to the status of being done by a technician.
I started work on Scanning Tunneling Microscopy literally the year after the "Bucky Ball" was imaged and in the lab where it was imaged(as part of a wider network of attempts to image it). At that time, the STM was considered to be in the realm of high research. Within the time frame of a decade, it is now "technician work"(supervised, of course, by a pHD who is doing the research).
The particular system ran on a 386 dell computer with a rather cludzy "window/menu" interface that was provided by the manufacturer of the STM itself (Burleigh back then). The previous machine, which I also used was using a DOS interface.
However ...young people have grown up with smooth, glossy, sophisticated, interfaces. The day of the cludzy interface, beloved of many of the command line people will soon be in the past.
Place this also in light of how Microsoft is specifically prohibiting manufacturers from even ALLOWING at boot the possibility of loading an OS like Linux on an ARM machine... which ALL of the universities/labs/etc. will soon jump on like dirty on a stick....there will need to be PLENTY of reasons for manufacturers to not want to buy into the forced situation which MS is, yet again, trying to contrive...
And KDE could be one of them.
It might be that the KDE devs should consider somehow integrating the gorgeous interface of KDE onto relatively plain potatoes OS, that is amenable to both the normal and ARM hardware architectures, so that when more and more scientific/medical apps move further down into technician status, that KDE is there to provide a pleasant user experience.
KDE on RedHat:
http://kde-redhat.sourceforge.net/
RedHat using GNOME and KDE
http://people.redhat.com/otaylor/rh-desktop.html
Again, I'm not advocating suddenly moving KDE to rpm! What is being suggested is that KDE consider the idea of working somehow with a "technical" Linux to integrate the KDE desktop on top of what would, otherwise, be considered by a "technician" as an "ugly" desktop.
just a thought, of little worth.
woodsmoke
I teach in a division of a junior college which prepares students for the "technology" of going into medicine, biology in general, etc. A particular emphasis is placed on DNA technology and imaging.
We have at one campus, in the physics department, a stand-alone system that runs Scientific Linux and at my campus we have a stand-alone system that runs BioPuppy. The ostensible reason that we cannot run them hooked to the network is that they may be susceptible to hackers, since they are "open", but in reality it is because MS gives discounts for the schools systems and the powers that be do not want to "rock the boat".
As an example of how Linux is highly adaptable to a variety of operating enviornments, I provide the following links to articles which are quite technical, and of little interest to the general reader.
However, buried in the articles which are about using certain "algorithms" (mathematical functions) to analyze digital images of things like gunshot wounds, are references, indirectly, and directly, to the use of Linux both as a "server" and as a "desktop OS" to run the algorithms.
The gist of the subject of the articles is that these algorithms do not work on a "block" pattern, like a checkerboard, (and like the display on your digital monitor) but rather in "concentric circles". Since a gunshot wound, or a carcinoma, is not, by nature, "square" in apparance, the concentric algorithm produces an image which more completely represents the physical situation in the body.
The trick, in this case, is to set up a situation in which the application knows when enough information has been derived from the image and then stops. Otherwise it will continue to analyze the image ad infinitum, in a manner that is rather like working with a fractal.
The software itself can be run under both open source and commercial applications/OS:
http://www.jpathinformatics.org/arti...13;aulast=Hipp
However, to the reason for the post.
In this particular case it is run on a rather plain vanilla Linux OS, one example being CentOS 5.5(based orn RedHat) on a Dell server.
The particular article, which, again, is of a highly technical nature, it is provided so that the reader can confirm by using "find" that CentOS is, indeed, the OS ( year 2011).
http://www.jpathinformatics.org/arti...32;aulast=Wang
The latest mention of CentOS at DistroWatch.
http://distrowatch.com/weekly.php?issue=20120109#news
The CentOS site:
http://www.centos.org/
Below is an article at Polish Linux about tweaking the server OS as a Desktop OS which, of course, can be done with just about any Linux OS including Kubuntu if one wants to spend resources on the desktop interface, which is not usually desired in a scientific environment.
HOWEVER, since the whole of the medical field is being pushed "down" into more and more people with less, and less, education (the "clinic" at your favourite pharmacy) the need for a "pleasant interface" will become more, and more, important.
http://polishlinux.org/redhat/centos-5-free-redhat/
As a last item, this post is not advocating that people abandon ship for CentOS. It's purpose is to:
a) indicate that merely because people make certain statements, that does not mean that the statements are correct.
b) indicate that, if so desired, Linux, including Kubuntu, could be setup to run in many different operating environments, and used for many different tasks and that "commercial" is not necessarily the best way to do things.
c) offer the suggestion that the KDE desktop interface might be of some small use in the near and far term in "technical" situations.
to wit: the particular algorithm itself has an almost trivial learning curve for use. That means that the algorithm can be used by relatively untrained individuals and that the software itself will provide meaningful, and repeatable, results instead of relying on the historically highly accurate analysis of experts.
The problem en fine is that there are literally tens of thousands of images and it is necessary that some way be found to handle the burgeoning volume of information, again reference is made to the above article, this is not a new link
again, en fine... why not have a "plasma widget" that runs the algorithm.
Yes, I know, there will be cries of "Why? Why not just invoke a menu command, it would be more efficient in terms of resources and the point of it all is to run the app, isn't it?"
Well, yes......
But, again....... this whole thing will, probably, very quickly, move to the status of being done by a technician.
I started work on Scanning Tunneling Microscopy literally the year after the "Bucky Ball" was imaged and in the lab where it was imaged(as part of a wider network of attempts to image it). At that time, the STM was considered to be in the realm of high research. Within the time frame of a decade, it is now "technician work"(supervised, of course, by a pHD who is doing the research).
The particular system ran on a 386 dell computer with a rather cludzy "window/menu" interface that was provided by the manufacturer of the STM itself (Burleigh back then). The previous machine, which I also used was using a DOS interface.
However ...young people have grown up with smooth, glossy, sophisticated, interfaces. The day of the cludzy interface, beloved of many of the command line people will soon be in the past.
Place this also in light of how Microsoft is specifically prohibiting manufacturers from even ALLOWING at boot the possibility of loading an OS like Linux on an ARM machine... which ALL of the universities/labs/etc. will soon jump on like dirty on a stick....there will need to be PLENTY of reasons for manufacturers to not want to buy into the forced situation which MS is, yet again, trying to contrive...
And KDE could be one of them.
It might be that the KDE devs should consider somehow integrating the gorgeous interface of KDE onto relatively plain potatoes OS, that is amenable to both the normal and ARM hardware architectures, so that when more and more scientific/medical apps move further down into technician status, that KDE is there to provide a pleasant user experience.
KDE on RedHat:
http://kde-redhat.sourceforge.net/
RedHat using GNOME and KDE
http://people.redhat.com/otaylor/rh-desktop.html
Again, I'm not advocating suddenly moving KDE to rpm! What is being suggested is that KDE consider the idea of working somehow with a "technical" Linux to integrate the KDE desktop on top of what would, otherwise, be considered by a "technician" as an "ugly" desktop.
just a thought, of little worth.
woodsmoke