Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
Rudi Ahlers wrote:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
I can't help thinking that you are just about to repeat all the security mistakes those other tools have spent years correcting and that you'd be much better off using one of the existing tools or making minor mods.
Having said that, it's really about time for someone to tackle this in java - perhaps with most of the details in a backend LDAP database.
On Sun, Jun 14, 2009 at 8:31 PM, Les Mikesell lesmikesell@gmail.com wrote:
Rudi Ahlers wrote:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users /
databases
/ FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? /
others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
I can't help thinking that you are just about to repeat all the security mistakes those other tools have spent years correcting and that you'd be much better off using one of the existing tools or making minor mods.
Having said that, it's really about time for someone to tackle this in java - perhaps with most of the details in a backend LDAP database.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the coder does :) What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't make a difference either.
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
LDAP can / would but be one component of the whole thing, and I'm not very fond of JAVA, since it's rather slow. Ideally I need something which could interact with the OS layer directly
Rudi Ahlers wrote:
On Sun, Jun 14, 2009 at 8:31 PM, Les Mikesell lesmikesell@gmail.com wrote:
Rudi Ahlers wrote:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users /
databases
/ FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? /
others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
I can't help thinking that you are just about to repeat all the security mistakes those other tools have spent years correcting and that you'd be much better off using one of the existing tools or making minor mods.
Having said that, it's really about time for someone to tackle this in java - perhaps with most of the details in a backend LDAP database.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the coder does :)
I didn't mean the language is going to cause the problem. I meant that coding mistakes are inevitable when you start from scratch and take years to find and fix - a headstart those other frameworks already have.
What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't make a difference either.
That's all almost irrelevant. Unless you make horrible coding mistakes, nothing you do within the programming language will take significant time compared to reading/writing the config files and database activity.
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
Measure what's really happening.
LDAP can / would but be one component of the whole thing, and I'm not very fond of JAVA, since it's rather slow. Ideally I need something which could interact with the OS layer directly
Java is only slow when you have to start a new JVM. I'd expect this to be run under tomcat or similar web container where the JVM would always be running. Again, measure a few things to get the idea. A tomcat app is easy enough to test - there are a few packaged ones to get the idea. As far as talking to the OS goes, all languages have ways to do that. Perl is probably the closest-to-native for most things - and has modules with embedded C-library access for anything else you might need. But java has built-in remote execution if you want to make this work on more than one machine.
On Sun, Jun 14, 2009 at 9:19 PM, Les Mikesell lesmikesell@gmail.com wrote:
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the
coder
does :)
I didn't mean the language is going to cause the problem. I meant that coding mistakes are inevitable when you start from scratch and take years to find and fix - a headstart those other frameworks already have.
What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't
make
a difference either.
That's all almost irrelevant. Unless you make horrible coding mistakes, nothing you do within the programming language will take significant time compared to reading/writing the config files and database activity.
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
Measure what's really happening.
LDAP can / would but be one component of the whole thing, and I'm not
very
fond of JAVA, since it's rather slow. Ideally I need something which
could
interact with the OS layer directly
Java is only slow when you have to start a new JVM. I'd expect this to be run under tomcat or similar web container where the JVM would always be running. Again, measure a few things to get the idea. A tomcat app is easy enough to test - there are a few packaged ones to get the idea. As far as talking to the OS goes, all languages have ways to do that. Perl is probably the closest-to-native for most things - and has modules with embedded C-library access for anything else you might need. But java has built-in remote execution if you want to make this work on more than one machine.
-- Les Mikesell lesmikesell@gmail.com
Well, my experience with JAVA, JS & JSP (I know they're all different) has been that it's slow on the user's end of view.
I have some clients with JBOSS / Tomcat, and while it's powerful, it also takes up a lot of resources. Ideally, whatever I use needs to be quick, and low on resources. cPanel, for one, needs a minimum of 512MB RAM to function properly. And while hardware is cheap these days, 512MB is still a lot. Other control panels will work hapily with 256, or perhaps even 128MB RAM.
On Sun, 2009-06-14 at 20:54 +0200, Rudi Ahlers wrote:
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the coder does :) What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't make a difference either.
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
How now, do you figure PHP is all that slow? Since you have a background in PHP why not use it? Maybe your not skinning the cat right? PHP is already used in admin apps and it works. Create a Three Tier Web Application to run on the one admin server. Calls can be made via rpc or xml web services to the clients. May take a while to think it out in your brain but it will work. I do it with .Net.
On Sun, Jun 14, 2009 at 9:55 PM, JohnS jses27@gmail.com wrote:
On Sun, 2009-06-14 at 20:54 +0200, Rudi Ahlers wrote:
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the coder does :) What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't make a difference either.
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
How now, do you figure PHP is all that slow? Since you have a background in PHP why not use it? Maybe your not skinning the cat right? PHP is already used in admin apps and it works. Create a Three Tier Web Application to run on the one admin server. Calls can be made via rpc or xml web services to the clients. May take a while to think it out in your brain but it will work. I do it with .Net.
Hi John,
Well, it's my understanding that compiled languages perform much better than scripting languages for this kind of operating, due to the fact that the script runs on top of the scripting engine, which in turn runs on top of the web server.
I know a lot of control panels run either PERL, C{+/++/#}, Python.
Rudi Ahlers wrote on Mon, 15 Jun 2009 18:23:42 +0200:
Well, it's my understanding that compiled languages perform much better than scripting languages for this kind of operating, due to the fact that the script runs on top of the scripting engine, which in turn runs on top of the web server.
The time it takes is marginal, we are not talking about a word processor or painting program. A shopping cart needs more ressources than a webhosting control panel and guess what most of them are coded in? Scripted languages.
Kai
On Mon, 2009-06-15 at 18:23 +0200, Rudi Ahlers wrote:
On Sun, Jun 14, 2009 at 9:55 PM, JohnS jses27@gmail.com wrote:
On Sun, 2009-06-14 at 20:54 +0200, Rudi Ahlers wrote: > > > > Hi Les, while I understand where you're coming from, I don't quite > agree with you. A programming language doesn't make security mistakes, > the coder does :) What I'm looking for, is which programming language > will be best, i.e. fastest. My OS of choice would be CentOS, but even > then that won't make a difference either. > > I can do most of this in PHP, but I do think PHP is a bit slow for > this, being a scripting language, and not a compiled language. How now, do you figure PHP is all that slow? Since you have a background in PHP why not use it? Maybe your not skinning the cat right? PHP is already used in admin apps and it works. Create a Three Tier Web Application to run on the one admin server. Calls can be made via rpc or xml web services to the clients. May take a while to think it out in your brain but it will work. I do it with .Net. _______________________________________________Hi John,
Well, it's my understanding that compiled languages perform much better than scripting languages for this kind of operating, due to the fact that the script runs on top of the scripting engine, which in turn runs on top of the web server.
I know a lot of control panels run either PERL, C{+/++/#}, Python.
--- Don't base your decision on speed on alone. Speed is not not everything in life. Who cares about speed? I don't. I use slow .Net to make DCOM and SOAP calls to do different server functions to Powershell.
Some of the biggest sites on the net run .Net and PHP and have an uptime of infinite 9. PHP-Facebook --- Myspace-.Net. All calls for myspace are made to .cfm? -> .Net backend. That said I believe you could do it in PHP.
John
Rudi Ahlers wrote on Sun, 14 Jun 2009 20:54:00 +0200:
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
It's not slow at all. I have written such an interface 5 or more years ago for our needs and it's split in two parts. I first wrote a lot of small scripts that do only a specific task and are controlled by command-line arguments. This backend was done in Perl, because I felt familiar with it for shell tasks at that time. I could have used PHP or Python (if I knew that better). Then I wrote the frontend for it in PHP.
Ideally I need something which could interact with the OS layer directly
In my eyes this is a bad idea. There is no direct interfacing between the two. The backend takes the commands from a text file that the frontend writes. One could also interface via database. There is no way to smuggle any system commands in because system commands are never carried out directly.
Instead of writing it all yourself, have you looked at ISPConfig? I have switched to ISPConfig (2) for our newer virtual machines last year and it's working really well. Although it's not as custom as my own interface I decided to go with that for our reseller customers because it's closer to what other interfaces look/do/provide and it would have needed a lot of extra coding to add this all to my own.
Kai
On Mon, Jun 15, 2009 at 10:31 AM, Kai Schaetzl maillists@conactive.comwrote:
Rudi Ahlers wrote on Sun, 14 Jun 2009 20:54:00 +0200:
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language.
It's not slow at all. I have written such an interface 5 or more years ago for our needs and it's split in two parts. I first wrote a lot of small scripts that do only a specific task and are controlled by command-line arguments. This backend was done in Perl, because I felt familiar with it for shell tasks at that time. I could have used PHP or Python (if I knew that better). Then I wrote the frontend for it in PHP.
Ideally I need something which could interact with the OS layer directly
In my eyes this is a bad idea. There is no direct interfacing between the two. The backend takes the commands from a text file that the frontend writes. One could also interface via database. There is no way to smuggle any system commands in because system commands are never carried out directly.
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
Instead of writing it all yourself, have you looked at ISPConfig? I have switched to ISPConfig (2) for our newer virtual machines last year and it's working really well. Although it's not as custom as my own interface I decided to go with that for our reseller customers because it's closer to what other interfaces look/do/provide and it would have needed a lot of extra coding to add this all to my own.
I had a look at it, and other control panels as well, but really don't like it, and don't really want to "interfere" with the GNU stuff. The CP I have in mind will most probably be for in-house use, but also for client's use.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
um, thats somewhat mixed up. user -> browser -> apache -> php that interprets your script -> OS function
with a native compiled language like C++, its user -> browser -> apache -> compiled C++ binary -> OS function
not really -that- different, as theres far more overhead in all the rest of the process than in the actual script or program,unless its doing something very computationally intensive.
also note, PHP is a preloaded module, while your C++ program probably gets forked on every webpage, unless you write it as an apache module... ooops.
On Mon, Jun 15, 2009 at 6:48 PM, John R Piercepierce@hogranch.com wrote:
Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
um, thats somewhat mixed up. user -> browser -> apache -> php that interprets your script -> OS function
with a native compiled language like C++, its user -> browser -> apache -> compiled C++ binary -> OS function
not really -that- different, as theres far more overhead in all the rest of the process than in the actual script or program,unless its doing something very computationally intensive.
also note, PHP is a preloaded module, while your C++ program probably gets forked on every webpage, unless you write it as an apache module... ooops.
Thanx John, I didn't think about it this way :)
But would PHP be able to perform all tasks that PERL / C++ can?
On Mon, 2009-06-15 at 19:45 +0200, Rudi Ahlers wrote:
On Mon, Jun 15, 2009 at 6:48 PM, John R Piercepierce@hogranch.com wrote:
Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
um, thats somewhat mixed up. user -> browser -> apache -> php that interprets your script -> OS function
with a native compiled language like C++, its user -> browser -> apache -> compiled C++ binary -> OS function
not really -that- different, as theres far more overhead in all the rest of the process than in the actual script or program,unless its doing something very computationally intensive.
also note, PHP is a preloaded module, while your C++ program probably gets forked on every webpage, unless you write it as an apache module... ooops.
Thanx John, I didn't think about it this way :)
But do keep in mind that only the data space and certain system-related structures must be duplicated, all in memory, when this fork occurs. Text and instruction space is not duplicated (it's shared by all instances) and the same is true for underlying librariy code, like glib*. The possibility of multiple threads also exists to affect that.
So the hit on performance will be very small. I don't know how this compares to things like PHP, having never had the interest, opportunity, ... to become familiar with it.
<snip>
Rudi Ahlers wrote:
But would PHP be able to perform all tasks that PERL / C++ can?
I don't see why not. Many of the existing control panels are written in PHP. PHP can manipulate files, execute system commands, and so forth. PEAR http://pear.php.net/packages.php includes a vast number of libraries for specific tasks.
Rudi Ahlers wrote on Mon, 15 Jun 2009 18:31:40 +0200:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
Just forget that it is slow, it isn't.
Kai
On 06/15/2009 05:31 PM, Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
you might find that this is the fastest way of doing things in a single stack, if you dont have state movement. Have you looked at the complexity of getting a java stack or a ruby stack up ( as a comparison ) ?
- KB
Karanbir Singh wrote:
On 06/15/2009 05:31 PM, Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
you might find that this is the fastest way of doing things in a single stack, if you dont have state movement. Have you looked at the complexity of getting a java stack or a ruby stack up ( as a comparison ) ?
With java, you should be able to use the stock openjdk and tomcat5 packages (finally!) and be all set so it is a matter of dropping war files in the right place. Even complex things like hudson or opengrok will 'just work' (and if you do any software development you should look at both).
On the other hand the guy here using ruby doesn't think the packaged Centos stuff is usable. Realistically, it is hard to keep complex modular tools where you want to use at least some of the very latest parts in sync with what an enterprise distribution packages. That might be sort-of a plus for python if you can live with whatever version yum needs and pay attention to what is going to break when it does version changes.
On Wed, Jun 17, 2009 at 2:54 PM, Les Mikeselllesmikesell@gmail.com wrote:
Karanbir Singh wrote:
On 06/15/2009 05:31 PM, Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
you might find that this is the fastest way of doing things in a single stack, if you dont have state movement. Have you looked at the complexity of getting a java stack or a ruby stack up ( as a comparison ) ?
With java, you should be able to use the stock openjdk and tomcat5 packages (finally!) and be all set so it is a matter of dropping war files in the right place. Even complex things like hudson or opengrok will 'just work' (and if you do any software development you should look at both).
On the other hand the guy here using ruby doesn't think the packaged Centos stuff is usable. Realistically, it is hard to keep complex modular tools where you want to use at least some of the very latest parts in sync with what an enterprise distribution packages. That might be sort-of a plus for python if you can live with whatever version yum needs and pay attention to what is going to break when it does version changes.
-- Les Mikesell lesmikesell@gmail.com
Hi Les,
This is something I need to take into consideration, and I've been looking at many different control panels to see how they handle it, and it seems that a lot of vendors have their own repository, which the client (or setup script) will add to the yum repositories list, and from there I could control the software being used. i.e. If I know my stuff works well on Apache 2.2.0, but not yet on 2.2.3 (for example), I could have the Apache 2.2.0 rpm in my repository, untill such a time that I feel it's ready to add 2.2.3.
On Jun 17, 2009, at 8:54 AM, Les Mikesell lesmikesell@gmail.com wrote:
Karanbir Singh wrote:
On 06/15/2009 05:31 PM, Rudi Ahlers wrote:
What I meant was, PHP talks to PHP script engine, which talks to Apache, which then talks to system commands. - is there a quicker way of doing it?
you might find that this is the fastest way of doing things in a single stack, if you dont have state movement. Have you looked at the complexity of getting a java stack or a ruby stack up ( as a comparison ) ?
With java, you should be able to use the stock openjdk and tomcat5 packages (finally!) and be all set so it is a matter of dropping war files in the right place. Even complex things like hudson or opengrok will 'just work' (and if you do any software development you should look at both).
On the other hand the guy here using ruby doesn't think the packaged Centos stuff is usable. Realistically, it is hard to keep complex modular tools where you want to use at least some of the very latest parts in sync with what an enterprise distribution packages. That might be sort-of a plus for python if you can live with whatever version yum needs and pay attention to what is going to break when it does version changes.
That is the truth.
I wish the enterprise distros would "unbundle" the LAMP stack from the core OS, it just moves too fast to include in a long-term support program. They should make it a separately maintained but compatible add-on feature set (make a separate repo of it), maybe with a stable and current version branch.
I have always felt the distros include way too much in the core OS which could be better off in an "extras" or even "contrib" repo. Things like openoffice, firefox and the like don't need to be in the OS distribution, but available to install the latest stable version from the add-ons repo. Doesn't mean you can't include these on the media, sure, just as a separate repo on the media.
It would be making, supporting and updating the core OS a magnitude less complex and would put the burden of making sure the LAMP or add- on packages are compatible with the core OS onto their respective maintainers or groups, but with proper notification and testing cycles it could be managed successfully.
I also think there should be a single version of an OS that stays more current over time, not the bleeding edge but the stable edge. Instead of backporting kernel features, make small point jumps along the way, say from 2.6.18 to 2.6.20 when the latest is 2.6.26 and when the latest is 2.6.30 move to 2.6.24 and so on.
I think I've wandered too far OT now...
-Ross
Ross Walker wrote:
With java, you should be able to use the stock openjdk and tomcat5 packages (finally!) and be all set so it is a matter of dropping war files in the right place. Even complex things like hudson or opengrok will 'just work' (and if you do any software development you should look at both).
On the other hand the guy here using ruby doesn't think the packaged Centos stuff is usable. Realistically, it is hard to keep complex modular tools where you want to use at least some of the very latest parts in sync with what an enterprise distribution packages. That might be sort-of a plus for python if you can live with whatever version yum needs and pay attention to what is going to break when it does version changes.
That is the truth.
I wish the enterprise distros would "unbundle" the LAMP stack from the core OS, it just moves too fast to include in a long-term support program. They should make it a separately maintained but compatible add-on feature set (make a separate repo of it), maybe with a stable and current version branch.
Even better: admit that you will often need two or more versions of every package to be installed simultaneously and make the package manager able to deal with that (i.e. satisfying dependencies separately, keeping them in different locations, etc.). It's not easy but that's why you want a program do do it for you instead of tracking them yourself under /usr/local or /opt. I suspect that a lot of places end up running whole virtual or physical machines just because they need to keep one old app working along with its replacement.
I have always felt the distros include way too much in the core OS which could be better off in an "extras" or even "contrib" repo. Things like openoffice, firefox and the like don't need to be in the OS distribution, but available to install the latest stable version from the add-ons repo. Doesn't mean you can't include these on the media, sure, just as a separate repo on the media.
Again, this would really need the ability to install more than one. And worse, some way to know when to integrate the libraries and when to isolate them which is probably impossible to know for sure.
It would be making, supporting and updating the core OS a magnitude less complex and would put the burden of making sure the LAMP or add- on packages are compatible with the core OS onto their respective maintainers or groups, but with proper notification and testing cycles it could be managed successfully.
Testing is the hard part here. It only works if you know that what you tested is more or less the same thing that ends up running. When multiple components, multiple versions and multiple repos are involved it becomes very hard to know that. Particularly when your update tool doesn't know where the version it is updating came from and will happily overwrite it with something else from somewhere else.
I also think there should be a single version of an OS that stays more current over time, not the bleeding edge but the stable edge. Instead of backporting kernel features, make small point jumps along the way, say from 2.6.18 to 2.6.20 when the latest is 2.6.26 and when the latest is 2.6.30 move to 2.6.24 and so on.
Agreed, but that more or less demands a stable device driver interface so you can easily adapt the newest hardware to the kernel you are running. Which sort-of rules out Linux.
I think I've wandered too far OT now...
Yes, but most CentOS users probably face exactly these same problems due to the nature of what it provides and what else you want the same machine to do.
________________________________
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Rudi Ahlers Sent: Sunday, June 14, 2009 11:54 AM To: CentOS mailing list Subject: Re: [CentOS] which programming language for server-side admin tasks
On Sun, Jun 14, 2009 at 8:31 PM, Les Mikesell lesmikesell@gmail.com wrote:
Rudi Ahlers wrote: > Hi, > > I would like to spend some time learning a new coding language, but > specifically for server side admin stuff, i.e. setting up users / databases > / FTP accounts / virtual domains on Apache, etc. > > I already know PHP, but realize it's not quite suited for this kind of > admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others? > > Can someone give me some pointers on this? > > I basically need to write a control panel, with web access for admins to > manage servers, similar to what cPanel / WebMin / Plesk / etc does right > now, but something more customized for our needs. I can't help thinking that you are just about to repeat all the security mistakes those other tools have spent years correcting and that you'd be much better off using one of the existing tools or making minor mods. Having said that, it's really about time for someone to tackle this in java - perhaps with most of the details in a backend LDAP database. -- Les Mikesell lesmikesell@gmail.com _______________________________________________
Hi Les, while I understand where you're coming from, I don't quite agree with you. A programming language doesn't make security mistakes, the coder does :) What I'm looking for, is which programming language will be best, i.e. fastest. My OS of choice would be CentOS, but even then that won't make a difference either. I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language. LDAP can / would but be one component of the whole thing, and I'm not very fond of JAVA, since it's rather slow. Ideally I need something which could interact with the OS layer directly
-- Kind Regards Rudi Ahlers CEO, SoftDux Hosting Web: http://www.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532
If you're looking for shear speed, C++. However if you're looking for ease of programming paradigm with OO ideas, etc, then Ruby or Python. If however you want a middle ground, go Perl. It is fairly fast (faster than Python and Ruby), and is fairly extensible for talking to the OS. Note however Perl's object framework leaves much to be desired from OO purists.
-- Gary L. Greene, Jr. IT Operations Minerva Networks, Inc. Cell: (650) 704-6633 Phone: (408) 240-1239
On Mon, Jun 15, 2009 at 7:09 PM, Gary Greeneggreene@minervanetworks.com wrote:
If you're looking for shear speed, C++. However if you're looking for ease of programming paradigm with OO ideas, etc, then Ruby or Python. If however you want a middle ground, go Perl. It is fairly fast (faster than Python and Ruby), and is fairly extensible for talking to the OS. Note however Perl's object framework leaves much to be desired from OO purists.
-- Gary L. Greene, Jr. IT Operations Minerva Networks, Inc. Cell: (650) 704-6633 Phone: (408) 240-1239
Thanx Gary, this is a quick analasys of what I'm looking for, and helps a lot :)
I have done some PERL coding on websites before, but very little, yet it was very easy to pickup with my PHP skills.
As a front-end, I would consider Ruby, and / or AJAX. Could these inteface well with PERL?
Rudi Ahlers wrote:
Thanx Gary, this is a quick analasys of what I'm looking for, and helps a lot :)
I have done some PERL coding on websites before, but very little, yet it was very easy to pickup with my PHP skills.
As a front-end, I would consider Ruby, and / or AJAX. Could these inteface well with PERL?
Apples and oranges... Ajax is mostly javascript running on the browser side and can work with any interactive web server, where ruby and perl are scripting languages that work on the server side. If you want speed, you'd use mod_perl under apache or a standalone mongrel running ruby.
However, it is probably a lot easier if you want ajax to use one of the server libraries that integrate things (Google Web Toolkit for java, Yahoo! UI Library for php, Ruby-on-Rails) or at least a library like jquery.
On Mon, Jun 15, 2009 at 8:14 PM, Les Mikeselllesmikesell@gmail.com wrote:
Apples and oranges... Ajax is mostly javascript running on the browser side and can work with any interactive web server, where ruby and perl are scripting languages that work on the server side. If you want speed, you'd use mod_perl under apache or a standalone mongrel running ruby.
However, it is probably a lot easier if you want ajax to use one of the server libraries that integrate things (Google Web Toolkit for java, Yahoo! UI Library for php, Ruby-on-Rails) or at least a library like jquery.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________
Fair enough, but AFAIK AJAX is quicker to the end user than Ruby,although Ruby could use AJAX as well.
So, from what I've gathered here, it could be a good idea to work with PERL + Ruby, and then add AJAX for the interface.
Rudi Ahlers wrote:
On Mon, Jun 15, 2009 at 8:14 PM, Les Mikeselllesmikesell@gmail.com wrote:
Apples and oranges... Ajax is mostly javascript running on the browser side and can work with any interactive web server, where ruby and perl are scripting languages that work on the server side. If you want speed, you'd use mod_perl under apache or a standalone mongrel running ruby.
However, it is probably a lot easier if you want ajax to use one of the server libraries that integrate things (Google Web Toolkit for java, Yahoo! UI Library for php, Ruby-on-Rails) or at least a library like jquery.
Fair enough, but AFAIK AJAX is quicker to the end user than Ruby,although Ruby could use AJAX as well.
So, from what I've gathered here, it could be a good idea to work with PERL + Ruby, and then add AJAX for the interface.
I'd investigate perl and ruby, then pick one or the other before going very far. The only reason to mix them would be that you want a spiffy new user interface made from ruby-on-rails but you already have, or have found existing, perl code to do the grunge work on the server side.
On 06/15/2009 07:44 PM, Rudi Ahlers wrote:
Fair enough, but AFAIK AJAX is quicker to the end user than Ruby,although Ruby could use AJAX as well.
I think what Les was trying to point out to you, a bit more politely, is that you need to go read up on some of these things, you are making little sense here. eg. you would in many cases be writing your ajax handers in ruby. So comparing them is like - I think the engine is faster than the rest of the car.
- KB
On 06/15/2009 06:09 PM, Gary Greene wrote:
If you're looking for shear speed, C++. However if you're looking for ease of programming paradigm with OO ideas, etc, then Ruby or Python. If however you want a middle ground, go Perl. It is fairly fast (faster than Python and Ruby), and is fairly extensible for talking to the OS. Note however Perl's object framework leaves much to be desired from OO purists.
I know that there are a *lot* of reasons to run with perl, however if you dont already know it - I see *no* reason to learn it as a language anymore. You are much better off working with the likes of python ( which isnt much slower than perl at most things ) or ruby ( which reduces the development time so much that its worth the slightly lower performance it has now - but thats also changing )
- KB
Karanbir Singh wrote:
On 06/15/2009 06:09 PM, Gary Greene wrote:
If you're looking for shear speed, C++. However if you're looking for ease of programming paradigm with OO ideas, etc, then Ruby or Python. If however you want a middle ground, go Perl. It is fairly fast (faster than Python and Ruby), and is fairly extensible for talking to the OS. Note however Perl's object framework leaves much to be desired from OO purists.
I know that there are a *lot* of reasons to run with perl, however if you dont already know it - I see *no* reason to learn it as a language anymore. You are much better off working with the likes of python ( which isnt much slower than perl at most things ) or ruby ( which reduces the development time so much that its worth the slightly lower performance it has now - but thats also changing )
I still see CPAN as a huge plus for perl since it often makes it possible to some very complex tasks with only a few lines of your own code. But maybe I just haven't found the corresponding resource for other languages. I think java might be close to a match but without a central place to find it. And it is much more verbose so even if you find libraries to do most of the grunge work you'll still be typing a lot.
Am 14.06.2009 um 20:00 schrieb Rudi Ahlers:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
The problem is that once you look closely at these kinds of software, you realize that what you're really looking at is an EAI (Enterprise Application Integration) type of task. You have different applications, maybe different databases that you need to synchronize and provision.
Commercial control-panels have more or less solved that - for their specific set of problems. Trying to integrate other kinds of software into them is usually just a futile exercise. E.g., most would like to integrate their own infrastructure for web-hosting or email-hosting (or both...) into one of the leading control-panels. There is Parallels Operations Automation and Parallels Business Automation - but the cheaper versions of them only support the other software in the "Parallels-universe" and the other versions I haven't been able to get my hands on and test.
In sourceforge.net, you can find some projects that aim to build opensource version of control-panels - few (if any) are in a state that would allow deployment in a mission-critical way (which they will be, after some time). Most applications of this type that are developed in-house at ISPs or telcos are probably to specific to the company they were developed for and this can never be released as opensource - or only with a significant efforts that nobody can afford (time- and money-wise).
It's a big problem - and a solid, sustainable solution will IMO require not only solid coding-skills, but also a talented software- architect.
Rainer
Rainer Duffner wrote:
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others?
Can someone give me some pointers on this?
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
The problem is that once you look closely at these kinds of software, you realize that what you're really looking at is an EAI (Enterprise Application Integration) type of task. You have different applications, maybe different databases that you need to synchronize and provision.
Webmin takes a somewhat different approach in working more-or-less directly with the stock application config files. Side effects are that you can still edit these file directly but the web interface can only slightly simplify operations and can't do much to combine what should be similar concepts.
On Sun, Jun 14, 2009, Rudi Ahlers wrote:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
We use python for most of the things we write now after having used perl for about 15 years.
You may find that webmin is useful for this type of thing as it can be configured to allow users to do pretty much anything, and to limit what they can do. On the other hand, IHMO it's written in pretty ugly perl, and I have found some major problems (e.g. happily removing the entire /home directory when changing a user's $HOME with a type). When we do set this up, we generally restrict access to the local LAN and a very small set of public IP addresses.
There is also a webmin companion program, usermin, which allows users to do many of their own user maintenance functions. Unfortunately I have seen it used in several cases to change mail user's shell from /bin/false to /bin/bash then giving access to the shell. Again, this can be restricted to the private LAN as webmin allows.
As for starting from scratch to do these things, it's probably a better idea to take something that does most of what you want and hack it to your needs. As others have said, this can help avoid the many pitfalls that one can find when doing security related administrative tasks. As an example, webmin allows one to specify a post-processing python script for user administration, and we provide one for our SMB customers that automatically updates things like Samba and jive_messanger user info in a single step.
Bill
Rudi Ahlers wrote:
Hi,
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
I already know PHP, but realize it's not quite suited for this kind of admin, and I suppose I need to look @ PERL / Python / C++ / Ruby? / others?
Can someone give me some pointers on this?
Python has become quite common for sysadmin stuff. Indeed, a lot of RedHat/Fedora (e.g. anaconda, the installer) and Ubuntu tools are really Python scripts. The code is quite readable and usually, there are Python bindings for almost every popular C library.
GUI can quickly be made with PyGTK or WxPython.
Programming language runtime performance is usually not an issue for sysadmin tasks, since most of the time you r program will have to wait for some disk I/O, a backup tape, etc.
I basically need to write a control panel, with web access for admins to manage servers, similar to what cPanel / WebMin / Plesk / etc does right now, but something more customized for our needs.
-- Kind Regards Rudi Ahlers CEO, SoftDux Hosting Web: http://www.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532
Peter
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2009-06-15 at 09:16 +0200, Peter Hopfgartner wrote:
Python has become quite common for sysadmin stuff. Indeed, a lot of RedHat/Fedora (e.g. anaconda, the installer) and Ubuntu tools are really Python scripts. The code is quite readable and usually, there are Python bindings for almost every popular C library.
Python will let you develop programs very quickly, the first time. The problem is that you'll have to go back and redo the code when a different version of python is released. There are major incompatibilities between 2.5 and 3.0. If you have a lot of code and/or use the low level C bindings, it can be a major effort to make your code run under a new release. Take a look at the poor folks at zope.org. They've been beaten half to death with almost every release.
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
GUI can quickly be made with PyGTK or WxPython.
And, of course, there's glade to help.
The bottom line is that you can probably get your project done faster in python. But if you have a lot of code that you're going to need to maintain, you're much better off with java, which actually has a lot of input from the user community, and respects their user base.
Dave
David G. Mackay wrote:
On Mon, 2009-06-15 at 09:16 +0200, Peter Hopfgartner wrote:
Python has become quite common for sysadmin stuff. Indeed, a lot of RedHat/Fedora (e.g. anaconda, the installer) and Ubuntu tools are really Python scripts. The code is quite readable and usually, there are Python bindings for almost every popular C library.
Python will let you develop programs very quickly, the first time. The problem is that you'll have to go back and redo the code when a different version of python is released. There are major incompatibilities between 2.5 and 3.0. If you have a lot of code and/or use the low level C bindings, it can be a major effort to make your code run under a new release. Take a look at the poor folks at zope.org. They've been beaten half to death with almost every release.
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important. This shouldn't have come as a surprise. By comparison, perl has been around longer and through more changes and yet about the only thing you might have to check on a program written for perl 1.x to run under 5.x would be whether you have @ in double-quoted strings that you wanted to remain literal.
GUI can quickly be made with PyGTK or WxPython.
And, of course, there's glade to help.
The bottom line is that you can probably get your project done faster in python. But if you have a lot of code that you're going to need to maintain, you're much better off with java, which actually has a lot of input from the user community, and respects their user base.
One other consideration is that perl probably has the current advantage in terms of available code library modules. Pretty much anything you can imagine doing has already been done and contributed to CPAN so often the code you have to write yourself is trivial with the modules doing the bulk of the work. Java may be catching up in this regard but I don't think there is a central place to find available code.
On Mon, 2009-06-15 at 10:04 -0500, Les Mikesell wrote:
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important. This shouldn't have come as a surprise. By comparison, perl has been around longer and
Judging by some of the comments on the fedora-devel list, it did anyway.
through more changes and yet about the only thing you might have to check on a program written for perl 1.x to run under 5.x would be whether you have @ in double-quoted strings that you wanted to remain literal.
I used to do a lot of coding in perl, but I found that I liked python better. I still like python for quick and dirty one-offs, but I'm not going to use it for large and persistent projects.
One other consideration is that perl probably has the current advantage in terms of available code library modules. Pretty much anything you can imagine doing has already been done and contributed to CPAN so often the code you have to write yourself is trivial with the modules doing the bulk of the work. Java may be catching up in this regard but I don't think there is a central place to find available code.
Google? ;)
I guess the real question is how well java is going to prosper under Oracle's ownership. Then again, with openjdk, it might not matter too much.
Dave
David G. Mackay wrote:
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important. This shouldn't have come as a surprise. By comparison, perl has been around longer and
Judging by some of the comments on the fedora-devel list, it did anyway.
Maybe some of those developers are young enough to not understand the history. Or to have learned from experience that it matters.
One other consideration is that perl probably has the current advantage in terms of available code library modules. Pretty much anything you can imagine doing has already been done and contributed to CPAN so often the code you have to write yourself is trivial with the modules doing the bulk of the work. Java may be catching up in this regard but I don't think there is a central place to find available code.
Google? ;)
How do you tell google to _not_ give you text matches that are really not about downloadable code modules in the language you want this week?
I guess the real question is how well java is going to prosper under Oracle's ownership. Then again, with openjdk, it might not matter too much.
I don't think that can become much of an issue. On the other hand, some of the other interesting projects (glassfish, opengrok, etc.) might be more likely to go away or change.
On Mon, 2009-06-15 at 14:30 -0500, Les Mikesell wrote:
David G. Mackay wrote:
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important. This shouldn't have come as a surprise. By comparison, perl has been around longer and
Judging by some of the comments on the fedora-devel list, it did anyway.
Maybe some of those developers are young enough to not understand the history. Or to have learned from experience that it matters.
The ones that I'm thinking about were from the RHEL engineering staff. That doesn't preclude them from being young, but they were surprised by the extent of the incompatibilities. Maybe the young ones are all that will be left after the ones that are charged with making some of the Fedora 11 stuff acceptable to a professional user base have committed ritual sepuku.
Google? ;)
How do you tell google to _not_ give you text matches that are really not about downloadable code modules in the language you want this week?
Well, I try to make my searches specific to what I'm looking for. The more key words that I can throw at it, the less extraneous cruft comes up.
I guess the real question is how well java is going to prosper under Oracle's ownership. Then again, with openjdk, it might not matter too much.
I don't think that can become much of an issue. On the other hand, some of the other interesting projects (glassfish, opengrok, etc.) might be more likely to go away or change.
Yeah, I've been tracking the Wonderland project. So far I haven't heard much from the development team one way or the other.
Dave
David G. Mackay wrote:
Google? ;)
How do you tell google to _not_ give you text matches that are really not about downloadable code modules in the language you want this week?
Well, I try to make my searches specific to what I'm looking for. The more key words that I can throw at it, the less extraneous cruft comes up.
That doesn't mesh very well with finding stuff that you don't know exists yet. For example there is a nice pure-java clone of rrdtool called jrobin that opennms uses to store and graph time-series values. But if you didn't already know that, how would you find it? Even the bigger things like cifs-in-java don't seem to be very well exposed.
On Mon, 2009-06-15 at 15:33 -0500, Les Mikesell wrote:
David G. Mackay wrote:
Well, I try to make my searches specific to what I'm looking for. The more key words that I can throw at it, the less extraneous cruft comes up.
That doesn't mesh very well with finding stuff that you don't know exists yet. For example there is a nice pure-java clone of rrdtool called jrobin that opennms uses to store and graph time-series values. But if you didn't already know that, how would you find it? Even the bigger things like cifs-in-java don't seem to be very well exposed.
True, but if I don't know that it exists, I'm probably not trying to find it. To find out about the items that are, to me, unknown, I do things like subscribing to technical mailing lists, etc. Then, there are sites like java.net that specialize in java.
Dave
At the risk of adding more wood to this fire...
On Mon, Jun 15, 2009 at 11:04, Les Mikeselllesmikesell@gmail.com wrote:
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important.
Not true. There is a 2to3 program bundled with Python 3 that will take care of most issues in the migration of Python 2 to Python 3. It's true that some changes will affect scripts in a way that 2to3 can't help, but those are mainly issues with the introduction of the distinctions of "bytes" and "characters" in Python 3, which IMO are a much needed feature.
Python 1 to 2 also introduced many changes, but AFAIR there were only new (more OO-like) ways to do things, the old ones (not so OO) became "deprecated" but scripts continued to work. But this was ages ago and I don't think it's that relevant to this discussion...
By comparison, perl has been around longer and through more changes and yet about the only thing you might have to check on a program written for perl 1.x to run under 5.x would be whether you have @ in double-quoted strings that you wanted to remain literal.
Excuse me? Have you heard about Perl 6? It's a complete rewrite of the grammar of the language. They even want to change "." as the concatenation operator. If not by the fact that they started working on it about 7 or 8 years ago and it is complete vaporware, it would be have been a *major* compatibility breaking change.
Now, talking about Java, that's a nightmare... I, as a sysadmin, have to maintain three or four JVM versions around in my machines, because each developer needs a different one of them. Some say their code must run in 1.5 and is not compatible with 1.6, some use GWT and need a 32-bit JVM, I also need another 32-bit 1.6 JRE for Firefox which is more stable, now there is OpenJDK (which does not have browser plug-in) to complete the mess. One of the developers said he needed jdk_1.5.0_06 and he would not use jdk_1.5.0_15jpp because he was not sure that the results would be the same. Not to mention that they have very specific constraints on the versions of Tomcat and all the other components... And while it is possible (though I doubt it) that a Java program written in JDK 1.0.2 would still run in OpenJDK 1.6, the language is completely changed, most methods were deprecated, there are new ways to do *everything* from strings to basic I/O (Input/Output Streams -> Readers/Writers) to Class Templates (whatever they call them) to Graphic UI (AWT -> Swing -> whatever they're using today) to Databases and threading/networking. I learned Java 10 years ago and did not keep up... my knowledge of it is worth almost zero today.
I won't say one is better than the other. Each one has its advantages and its own problems. You should choose one based on your personal choice, and learn how to switch to another one for a specific project if it seems it could be the right tool for the job.
On different e-mails, Rudi Ahlersrudiahlers@gmail.com wrote:
I can do most of this in PHP, but I do think PHP is a bit slow for this, being a scripting language, and not a compiled language. [...] I'm not very fond of JAVA, since it's rather slow. [...] Well, it's my understanding that compiled languages perform much better than scripting languages for this kind of operating [...] I had a look at it, and other control panels as well, but really don't like it, and don't really want to "interfere" with the GNU stuff. The CP I have in mind will most probably be for in-house use, but also for client's use. [...] CentOS would be my primary OS of choice, but I suppose it would be good to make the code more portable, and accommodate other Linux distro's, and probably OS's [...] But would PHP be able to perform all tasks that PERL / C++ can? [...] I have done some PERL coding on websites before, but very little, yet it was very easy to pickup with my PHP skills. As a front-end, I would consider Ruby, and / or AJAX. Could these inteface well with PERL? [...] AJAX is quicker to the end user than Ruby [...] So, from what I've gathered here, it could be a good idea to work with PERL + Ruby, and then add AJAX for the interface.
Rudy,
It's clear by now that you don't know what you want.
Worse, you want something that is flexible and portable enough, and yet you want to use 4 or 5 different languages (that you haven't learned yet!) to build it and handle the complex interactions between them.
And yet you believe you won't fall into the security pitfalls of writing not only a web application, but one that interacts with the core components of the OS.
Do yourself (and us all!) a favor and just "hack" one of the existing control panels to do what you need on your setup. And if you'll do extensive programming (meaning more than one line fixes) on it, choose one written in PHP which is the language you already know and master.
On the other hand, if what you want is to learn new languages, choose one and learn it well, but choose something simple (and not a flexible portable control panel) as your test application. Expect it not to be so good on the first try, but then try again and again (or try other kinds of applications) until you master it. Don't mix languages until you really master both of them.
I hope you don't see this as a discouragement, but as an advice of someone who has seen many projects like the one you outlined flunk...
Cheers, Filipe
Filipe Brandenburger wrote:
At the risk of adding more wood to this fire...
On Mon, Jun 15, 2009 at 11:04, Les Mikeselllesmikesell@gmail.com wrote:
Yes but it has been obvious for a long time that python does not consider backwards compatibility to be important.
Not true. There is a 2to3 program bundled with Python 3 that will take care of most issues in the migration of Python 2 to Python 3. It's true that some changes will affect scripts in a way that 2to3 can't help, but those are mainly issues with the introduction of the distinctions of "bytes" and "characters" in Python 3, which IMO are a much needed feature.
So there are parts that will change in mysterious ways that not even a pre-planned translator can fix predictably... And you'd like me to let something like that have administrative control of my machines? No, thanks.
Python 1 to 2 also introduced many changes, but AFAIR there were only new (more OO-like) ways to do things, the old ones (not so OO) became "deprecated" but scripts continued to work. But this was ages ago and I don't think it's that relevant to this discussion...
The scripts did not continue to work. I remember updating a Red Hat machine probably in the 6.x era and having mailman just stop working because of a gratuitous syntax change.
By comparison, perl has been around longer and through more changes and yet about the only thing you might have to check on a program written for perl 1.x to run under 5.x would be whether you have @ in double-quoted strings that you wanted to remain literal.
Excuse me? Have you heard about Perl 6? It's a complete rewrite of the grammar of the language. They even want to change "." as the concatenation operator. If not by the fact that they started working on it about 7 or 8 years ago and it is complete vaporware, it would be have been a *major* compatibility breaking change.
Yes, I know about perl 6 and the fact that the developers have been responsible enough not to release it in a form that will break perl <6 programs. And I expect it to stay that way. Plus, perl has always been designed to support multiple concurrent installations although RPM packaging doesn't deal with it well.
Now, talking about Java, that's a nightmare... I, as a sysadmin, have to maintain three or four JVM versions around in my machines, because each developer needs a different one of them.
Blame Red Hat for most of that. If they had shipped a working version or worked together with Sun to provide an easy third party RPM install that landed in the expected place, nobody would have used anything else.
Some say their code must run in 1.5 and is not compatible with 1.6,
1.6 has some bugs, depending on the version.
some use GWT and need a 32-bit JVM,
That's a quirk of their hosted mode for debugging and should eventually have a workaround. I don't think it matters where the production runtime runs - I'm fairly sure OpenNMS uses gwt and I have both 32 and 64 bit JVMs running it unchanged. They package all the compiled java as noarch rpms.
I also need another 32-bit 1.6 JRE for Firefox which is more stable, now there is OpenJDK (which does not have browser plug-in) to complete the mess.
Again, blame Red Hat packaging.
One of the developers said he needed jdk_1.5.0_06 and he would not use jdk_1.5.0_15jpp because he was not sure that the results would be the same.
Too lazy to try and see? That seems very unlikely to break.
Not to mention that they have very specific constraints on the versions of Tomcat and all the other components... And while it is possible (though I doubt it) that a Java program written in JDK 1.0.2 would still run in OpenJDK 1.6, the language is completely changed, most methods were deprecated, there are new ways to do *everything* from strings to basic I/O (Input/Output Streams -> Readers/Writers) to Class Templates (whatever they call them) to Graphic UI (AWT -> Swing -> whatever they're using today) to Databases and threading/networking. I learned Java 10 years ago and did not keep up... my knowledge of it is worth almost zero today.
Agreed on that point, but the changes are big improvements and I think you are judging the language comparing a decade old version to next year's python which seems a bit unfair. And as you obviously know, it it fairly self-contained and easy to run multiple versions concurrently although again, rpm packaging and the alternatives system don't really understand this concept very well.
I won't say one is better than the other. Each one has its advantages and its own problems. You should choose one based on your personal choice, and learn how to switch to another one for a specific project if it seems it could be the right tool for the job.
The unfortunate thing is that as projects evolve, you end up finding parts of what you want in one language and other parts in different ones so you can't easily combine them. For example, I'd love to be able to integrate the data from OpenNMS (snmp, network monitoring in java with a postgresql backend database and jrobin time-series data), Ocsinventory-ng (C++, and perl agents, php/perl servers with a mysql database) and racktables (php/mysql). Each does something the others miss, but each has its own copy of the relevant data.
On 06/15/2009 03:22 PM, David G. Mackay wrote:
Python will let you develop programs very quickly, the first time. The problem is that you'll have to go back and redo the code when a different version of python is released. There are major incompatibilities between 2.5 and 3.0.
afaik, this is the first time there is such a major change coming down the python line - even then, I feel its been well documented and there are atleast a couple of automated harness to help along the process.
I agree its not ideal, far from it - for anyone on any language. But then if you look at it py3 isnt going to be around for c5 or c6, who knows what other tooling might be available further into the future.
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
But the changes have been known for a while right ? and are'nt most people already making changes that allows their code to migrate well over to 3.0 when its around ?
The bottom line is that you can probably get your project done faster in python. But if you have a lot of code that you're going to need to maintain, you're much better off with java, which actually has a lot of input from the user community, and respects their user base.
Given that large numbers of java people are jumping ship into the ruby camp, I dont know how much of that is really true anymore. More and more of the companies that I know about ( specially the really smart ones ) are either already on ruby for a significant portion of their work, or are in the process of moving.
Karanbir Singh wrote:
Given that large numbers of java people are jumping ship into the ruby camp, I dont know how much of that is really true anymore.
With Red Hat's history of shipping 'something like java' that doesn't really execute java code, that doesn't seem too surprising. And maybe it is too late to fix now.
More and more of the companies that I know about ( specially the really smart ones ) are either already on ruby for a significant portion of their work, or are in the process of moving.
A guy using it here seems to have some version dependencies that take code changes after ruby updates, but maybe that's a learning curve instead of language instability.
On 06/15/2009 06:16 PM, Les Mikesell wrote:
More and more of the companies that I know about ( specially the really smart ones ) are either already on ruby for a significant portion of their work, or are in the process of moving.
A guy using it here seems to have some version dependencies that take code changes after ruby updates, but maybe that's a learning curve instead of language instability.
I wont be surprised, also rubygems is just cpan done even worse than cpan ever was. Its surprising that amongst such smart people, they all still foot pedal something that is just so broken by design ( look at it this way, they didnt realise there could be something like 'arch' for a long time, even now - by design gem is completely arch blind )
Karanbir Singh wrote:
On 06/15/2009 06:16 PM, Les Mikesell wrote:
More and more of the companies that I know about ( specially the really smart ones ) are either already on ruby for a significant portion of their work, or are in the process of moving.
A guy using it here seems to have some version dependencies that take code changes after ruby updates, but maybe that's a learning curve instead of language instability.
I wont be surprised, also rubygems is just cpan done even worse than cpan ever was. Its surprising that amongst such smart people, they all still foot pedal something that is just so broken by design ( look at it this way, they didnt realise there could be something like 'arch' for a long time, even now - by design gem is completely arch blind )
Which is a big part of the beauty of java. The people writing it understood that it would run on more than one kind of CPU and under more than one OS from day one. There are still some version differences, but few are because of bad design or not understanding the requirements.
On Mon, 2009-06-15 at 16:12 +0100, Karanbir Singh wrote:
On 06/15/2009 03:22 PM, David G. Mackay wrote:
Python will let you develop programs very quickly, the first time. The problem is that you'll have to go back and redo the code when a different version of python is released. There are major incompatibilities between 2.5 and 3.0.
afaik, this is the first time there is such a major change coming down the python line - even then, I feel its been well documented and there are atleast a couple of automated harness to help along the process.
That's correct, if you stick to pure python coding. Once again, if you look at zope, which makes extensive use of the C api, they've had fits with just about every release.
I agree its not ideal, far from it - for anyone on any language. But then if you look at it py3 isnt going to be around for c5 or c6, who knows what other tooling might be available further into the future.
Also, there are several engineers at Red Hat that are very unhappy with the impact that the 3.0 release is going to have on them.
But the changes have been known for a while right ? and are'nt most people already making changes that allows their code to migrate well over to 3.0 when its around ?
Probably. However, most developers would rather spend their resources on adding new features to their product rather than making changes just to stay compatible with the current language version. I believe that, even with the migration tools, people are still going to have to manually convert portions of their code. I haven't really followed it that closely since I won't be converting more than a few short scriptlets.
The bottom line is that you can probably get your project done faster in python. But if you have a lot of code that you're going to need to maintain, you're much better off with java, which actually has a lot of input from the user community, and respects their user base.
Given that large numbers of java people are jumping ship into the ruby camp, I dont know how much of that is really true anymore. More and more of the companies that I know about ( specially the really smart ones ) are either already on ruby for a significant portion of their work, or are in the process of moving.
Sigh. Yet another language. I guess that I'll have to take a look at ruby.
Dave
On 06/14/2009 07:00 PM, Rudi Ahlers wrote:
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
If you are targetting CentOS and/or Linux only - doing this in anything other than python just does not make sense to me. Ruby, perhaps - but you will need to redo or atleast work with a lot of the underlaying systems.
-KB
PS: you still dont really seem to trim your replies, having bad mailing list etiquette after having been on the list for so long is odd.
I currently use ruby for a lot of my sysadmin tasks. I think python and ruby are the best choices now - I've tried both languages and found them both easy to work with. I chose ruby because it felt more comfortable to be somehow. For most people, the choice between the 2 languages will come down to personal taste, IMHO.
Pat and Lori Boyer wrote:
I currently use ruby for a lot of my sysadmin tasks. I think python and ruby are the best choices now - I've tried both languages and found them both easy to work with. I chose ruby because it felt more comfortable to be somehow. For most people, the choice between the 2 languages will come down to personal taste, IMHO.
Would you expect ruby to be able to scale up to projects like OpenNMS, Alfresco, or what Pentaho does?
On 06/15/2009 06:09 PM, Les Mikesell wrote:
Would you expect ruby to be able to scale up to projects like OpenNMS, Alfresco, or what Pentaho does?
I would, easily. It all depends on what sort of resources you have at hand and what its going to cost you. atleast 4 of the top 10 most-traffic websites out there right now rely quite heavily on ruby.
Karanbir Singh wrote:
On 06/15/2009 06:09 PM, Les Mikesell wrote:
Would you expect ruby to be able to scale up to projects like OpenNMS, Alfresco, or what Pentaho does?
I would, easily. It all depends on what sort of resources you have at hand and what its going to cost you. atleast 4 of the top 10 most-traffic websites out there right now rely quite heavily on ruby.
I meant scale in terms of program size and complexity. You can hook a web interface to a database in about any language and crank things through as fast as the database can respond - especially if you load-balance across a bunch of servers. But how complicated can you make something before you hit a wall with multiple developers clobbering each other or becoming so version-dependent that you are afraid to update anything?
On 06/15/2009 08:15 PM, Les Mikesell wrote:
I meant scale in terms of program size and complexity. You can hook a web interface to a database in about any language and crank things through as fast as the database can respond - especially if you load-balance across a bunch of servers. But how complicated can you make something before you hit a wall with multiple developers clobbering each other or becoming so version-dependent that you are afraid to update anything?
you should look at ruby, it fix's most of the issues that people have with java code growing too large to manage :) its one of the key issues cited by people moving from java to things like ruby. Specially people who work with tdd and agile tools.
On Mon, Jun 15, 2009 at 5:13 PM, Karanbir Singhmail-lists@karan.org wrote:
On 06/14/2009 07:00 PM, Rudi Ahlers wrote:
I would like to spend some time learning a new coding language, but specifically for server side admin stuff, i.e. setting up users / databases / FTP accounts / virtual domains on Apache, etc.
If you are targetting CentOS and/or Linux only - doing this in anything other than python just does not make sense to me. Ruby, perhaps - but you will need to redo or atleast work with a lot of the underlaying systems.
-KB
PS: you still dont really seem to trim your replies, having bad mailing list etiquette after having been on the list for so long is odd. _______________________________________________
CentOS would be my primary OS of choice, but I suppose it would be good to make the code more portable, and accommodate other Linux distro's, and probably OS's (probably only limited to the *nix family) as well. Some of my friends prefer Debian.
Apart from the packaging, different paths to programs (Apache, MySQL, Exim, etc), and init scripts, I don't think this would be too difficult to accomplish. There are other differences I obviously need to look out for as well, since configuration files on different systems could be in different places,and sometimes even have different layouts, but even this should be as simple as keeping a list of options per distro being used.
-
Bill Campbell -
David G. Mackay -
Filipe Brandenburger -
Gary Greene -
John R Pierce -
JohnS -
Kai Schaetzl -
Karanbir Singh -
Les Mikesell -
Pat and Lori Boyer -
Peter Hopfgartner -
Rainer Duffner -
Ross Walker -
Rudi Ahlers -
William L. Maltby