I am getting ready to test a new PHP application and need to figure out what are the different options/configurations of my users.. so I can fully test on each.

Can anyone tell me what are the different popular control panels? (I realize there are many many options, so I'm just looking for "mainstream" or "most popular" configurations..)

Here's what I have:

1) Plesk - Linux
2) Ensim - Linux
3) Ensim - Windows
4) CPanel - Linux
5) H-Sphere - Linux
6) H-Sphere - Windows
7) Cobalt Raq

Any others?

Thanks!

you missed just a few

DirectAdmin
Sphera linux
Sphera Windows
Hostopia
Etrinix.com Windows
Helm
HOSTFLOW
HostGUI
Hosting Controller Windows
Virtuozzo VPS Linux
ConFixx
webcp.can-host.com

There are more but the most popular on the forum is cPanel, Plesk and Ensim. I have been watching and using DirectAdmin and it's coming along very nicely, they seem to be updating the panel on a regular bases.

Originally posted by leeb
There are more ...

I realize there are maybe dozens of control panels available. However I am only looking for the very highest popular panels.

Is is not practical for me to test on EVERY possible configuration, so I must take the top 10 and work with that. As long as the application works with the top 10, then it will work with the majority..

Thanks!

DirectAdmin is definately moving up the list. With the levels of support, upgrades and improvements and personalized service, the other guys better wake up!

So, don't forget them in your testing.

I suspect it won't be long before you'll start seeing alot more "MUST have DirectAdmin" in place of the current "MUST have cPanel" statements when people are requesting hosting plan offers ! :)

Ensim Webppliance Pro was left out.

The most popular are probably:
Cpanel,Ensim,Ensim Pro, Plesk, H-Sphere and Direct Admin (coming along).

Originally posted by UH-Matt
Ensim Webppliance Pro was left out.

The most popular are probably:
Cpanel,Ensim,Ensim Pro, Plesk, H-Sphere and Direct Admin (coming along).

What is the difference between Ensim and Ensim PRO?

I think Ikonware will be popular as well. It is built by a good firm and they provide support for many hosts so it should catch on quickly.

one of the difference is the ability to collect customer data on bandwidth and storage and pass that through the api to the billing software so the host can take advantage of that.

there are other issuse but thats the one we worked with the most.

Hey,
Let me give the most popular list around. This is purely based on the number of hosting companies we deal with.

Cpanel - The most popular till date. Ease of use it's biggest plus
Plesk - Big winner on price
Ensim - Reliable company. Growing well.
H-sphere - A lot of features.

These are the ones you must test.

Generally when looking at a panel look at the following -
1) TOS for a year.
2) Ease of use.
3) Stablity of the software
4) Speed what language it is written it. Perl is slow.
5) On the high end look for features like clustering.

Regards
Amar

I'd drop the Cobalt RAQ from your list!

You should also consider 42go : http://www.projektfarm.de

Helm ?

Originally posted by eHostSpace
Helm ?

He listed it already

Originally posted by bobcares
Hey,
Let me give the most popular list around. This is purely based on the number of hosting companies we deal with.


Thanks. :) That is a good list, because I know you guys do support for many companies... so you would know what is popular and what is not.

Cheers!

Originally posted by bobcares


4) Speed what language it is written it. Perl is slow.

Regards
Amar

Perl is not slow. For an interpreted language, it's probably one of the fastest, most powerful ones available--if not the fastest. I think you're confusing CGI with Perl. CGI is an interface and has no more to do with Perl than PHP or apples. Anyway, CGI is usually slower than PHP as per the interface, because PHP is usually run as a web server module--though you can run it through/as CGI, just as you can with Perl--and PHP will be just as slow, if not slower.

How exactly is Perl "slow"? Even in a control panel, how is it "slower" than PHP, for example? Perl, like PHP, can be run as a web server module as well. Of course, if you're writing a control panel in a language, you can't take advantage of it being a web server module or not (unless you run it with the backend as Apache--which would be foolish and insecure), so comparing Perl with anything else doesn't mean much as for how fast it runs, if you want to blame the interface people use for CGI scripts (Perl does a lot more than that, and very well).

You're not going to get much faster than C, following that, C++, following that, Perl, PHP,... Python, Ruby and other languages compare equally as well when running as a daemonized process.

Perl, in fact, is very, very well suited for this type of interface, more than many other languages. The only reason why anyone could take advantage of PHP, is because it runs as a web server module--and who'd use Apache for the base of their control panel anyway?

Oh, I see that you are with ikonware (I didn't notice this when I started responding, so don't think I'm insulting you). The CGI *interface* is what's slow and the overhead it causes by spawning an individual, new, additional process for each hit on the script. If you have a daemonized process and don't use Apache (for goodness sakes!) as the back engine of a control panel, then it doesn't suffer from the CGi interface, because it's threaded, or forking, or multiplexing, or whatever you want to use.

Perl has a feature that's been out for years that converts Perl code into C, which is then compiled. Thus, you can compile it, so it's close to the speed of compiled C/C++. So, I really fail to see how you claim Perl is slow. It's a language and it's hardly slow. Don't blame the language on the interface people often run it through.

As for your claim, I can see why you think it--because the entire backend of your control panel is an Apache server running as root. Albeit you surely modified the configuration to run slightly more securely, this is a huge mistake.

I'm not saying this to hassle or bash you, but as a friendly warning; Apache is not completely secure, it is not meant to run and serve files and process as root user or any privileged user. Thus, there are major security issues with your design.

Not to mention, these issues exist, simply and solely because you are running Apache improperly, but in addition, any trivial or less major bug in Apache--and this happens enough--that would otherwise cause a small risk, would open up your entire server to being rooted.

There's absolutely no way you can get around these facts, you should not use this method and it's a serious design flaw and basis for the main engine of your control panel. That said, since you use Apache and it would fork off new processes for each hit on a Perl script with _your_ control panel set up, this should not be something practiced in the real world due to major security issues.

So, while for _your_ set up, Perl may run slower (because you choose to not instead use mod_perl or fastCGI with your current design), it's only due to how you're running it. Compared PHP and Perl side by side, non compiled, as a daemonized process, using threading/multiplexing, Perl will usually run faster and at least be as fast.

Of course, in fairness to Perl and PHP, since C/C++ would be better (as the engine, not individual binaries compiled, like you use--this still has the overhead, and just calling compiled files after the fact doesn't help), is that a control panel should not ever be getting such hits and traffic that it would even matter.

In other words, with proper checks to prevent attacks or DoS's, you will not need to use compiled C for the backend--no control panel should get that many hits in that short of a period, unless it's an attack, and you should deal with them accordingly in the program.

I'm not sure I see the reason for the C++ in your program you state it has? The bianries are rather large for being compiled C++--where these the result of the perlcc converted and then you compiled that? Nonetheless, it mustn't serve a great purpose, since the main engine is interacting with it in a manner that would not take advantage of it being compiled C++. I just wondered why you then mentioned that Perl is "slow"?

Thus, any language would work, as long as it's implemented and designed properly with the backend and how it runs and makes the calls and so on. Any good implementation, you'd absolutely not notice any difference between Perl and C or C++, or PHP, or Python, or anything else. Besides, you can always compile Perl's C code--which is close to being as efficient as compiled C (though not quite as fast).

Again, you will not notice any difference at all, unless there's a flaw in the design of the program, for this type of particular program. In fact, Perl would probably be the best choice, with C/C++ a close alternative, if you wanted to spend the time--which it would probably not be worth it since Perl is already so well suited and has all the modules to do most of it in a nice OO oriented design.

Anyway, that's my response to why Perl may be slower for how you designed your control panel, but in any other environment, even your own if you decided to go that way, it would be just as fast. Feel free to take my suggestions and warnings if you like, and this is not to flame you or your product, but I thought I'd state the facts in response to your claim about Perl being slower--among other things.


Another point about Perl, is that it already does all the checks for you, so you don't have to worry about stack/buffer overflows and other type of attacks/exploits. Not that you can't do the same with other interpreted languages or languages like C/C++, etc., because you surely can, but it takes more planning and time and checking with C/C++.

Originally posted by Tim_Greer
You're not going to get much faster than C...

Assembler for the web!

Assembler.NET

:D

Originally posted by mrzippy
Assembler for the web!

Assembler.NET

:D

Huh?? How is this 'faster' running than C? Or are you joking? :-)


.

Originally posted by Tim_Greer
Huh?? How is this 'faster' running than C? Or are you joking? :-)

I was joking.. sortof.

Actually, I heard there really is a .NET implementation of Assembler. And since assembler is practically only one step removed from machine code it would surely be faster then C.

Although it would be 50 thousand times harder to program. Arg!

Originally posted by mrzippy
I was joking.. sortof.

Actually, I heard there really is a .NET implementation of Assembler. And since assembler is practically only one step removed from machine code it would surely be faster then C.

Although it would be 50 thousand times harder to program. Arg!

Very true about that, assembly being about as fast as you can get. Sounds interesting, but I don't use .NET and don't find it too appealing--probably because there's something I don't know :-).

Originally posted by Tim_Greer
[B]Perl is not slow. For an interpreted language, it's probably one of the fastest, most powerful ones available--if not the fastest. ........

......... :sleeping:


I am sorry I am late in responding. I slept off reading your post ... (just kidding, the post was too long that is all... ;) )

First this entire advice is off the topic, it would have made sense to give it offline. But that is if you wanted to help. I still appreciate it as atleast you have taken your valuable time to go through our site and see what we have to offer. Also, I fully understand that you are just giving a friendly warning and you are not bashing us. I wonder why you felt that we'll feel that you are bashing ? bobcares does a lot of things but we really did not write perl , php or c for that matter. :)

Why are you comparing Perl with PHP? I never said php is fast, did I ?

Why not compare Perl with C++ which is what ikonware is written in.

Now how exactly it is slow. Even in schools they teach about interpreted languages and compiled languages. And I am sure you'll know that compiled languages are anyday faster. I was just trying to say that. But then I am sure you'll have data to back up the speed of perl compared to C or PHP . Where is it? Or is it just written text with a lot of big words. Also have you heard of Zend optimizer.

As far as ikonware goes. Can I know how you know the internal of ikonware. As far as I know you are not a customer of mine. binaries large .... ???? OMG....

I know of one Tim who once said that C++ is the way to go for a control panel. And that we must not write in Perl. Thanks to him we had to rewrite the entire project from Perl to C++. End result we lost money, client and name.... :(

But then people learn and grow with experience....

Perl is a wonderful language and is the fastest for development and it is very easy to learn. But for a control panel it is not ideal. Those who have developed control panels would know that the backend involves quite a lot of work. A simple things like add account means atleast 8 file operations. That takes time.


Have a great day :)

Regards
Amar

Damn, and there was me thinking Tim had hung up his long posting keyboard.

As for people saying you'll be seeing a lot more "must have xyz control panel and lots more hosts will be switching too it", most hosts don't like switching and will stick with a product even though it may be inferior - why? Well it all comes down to costs, it takes a lot of effort and man-power to switch from one system to another, or to support two systems at the same time.

Part I:

Originally posted by bobcares
I am sorry I am late in responding. I slept off reading your post ... (just kidding, the post was too long that is all... ;) )

First this entire advice is off the topic, it would have made sense to give it offline.


It's not off topic, you were talking about reasons to avoid other control panels, stating if they are written in Perl, they are slow. I gave reasons why it may be slow for your setup/design, based on you using Apache as the backend and that you must be thinking about Perl in terms as running as CGI for your design. I don't know how it would have made more sense to say this off-line, when you said that here.


But that is if you wanted to help. I still appreciate it as atleast you have taken your valuable time to go through our site and see what we have to offer.


It only took a second, and it doesn't look like it changed over a few things since you guy's used that same code for the original HostGUI. So it didn't take over a few minutes.


Also, I fully understand that you are just giving a friendly warning and you are not bashing us. I wonder why you felt that we'll feel that you are bashing ?


Usually when I see people say anything to correct your post or point something out or disagree, I usually see that sort of response, so I wanted ot make it clear.


bobcares does a lot of things but we really did not write perl , php or c for that matter. :)


I'm not sure I understand what you're saying. There's no reason for that--you compared the language used (not I), when you said that Perl was slow. I compared them based on your comment and based on the fact that your site clearly says that you have the control panel written in C++ and PHP--and the backend is the Apache web server (running as root, which you don't mention).

I'd therefore think that your comment about Perl being slow--and to stay away from control panel's written in Perl--would indeed make a valid comparison with Perl vs PHP in speed, since you mentioned to be cautious of how "slow" Perl is and to not use any panel written in it--yet you wrote your frontend in PHP, that then calls other scripts. So, I'm not sure where you think I was ever speaking of this as if you wrote any of these languages or as if I blamed you for it. You blamed Perl, not I.




Why are you comparing Perl with PHP? I never said php is fast, did I ?


No, but you use PHP and you claim Perl is slow--slow enough for people to basically 'watch out' for any control panel written in it. Since your control panel is coded in PHP and C++, and uses Apache for the backend, I compared this to illustrate that your warning about Perl, is a little odd, since you use PHP, you call to compiled scripts from there (Zend Encoded PHP scripts call to compiled C++ scripts, all done through Apache running as root). The fact you use that set up and mention Perl is slow, as if PHP is fast, is why I made the comparison--it's what you use, after all... or are you saying PHP is slow too, and that people should keep that in mind when considering your control panel? After all, it was worth mentioning, right? :-)


Why not compare Perl with C++ which is what ikonware is written in.


Because it's not. It's coded in PHP, which uses Zend encoding and runs through Apache and then only calls to very simple, basic C++ compiled binaries for the final calls. It calls to C++ programs, it is not written in it--it is misleading to state otherwise. Also, I compared them, based on this, because the Zend encoded PHP scripts are running through Apache (running as root), which then calls to the C++ binaries--and that method is no faster than Perl would be--this is why I mentioned a daemonized version would be better, especially since you mentioned speed being so important (which it is, I can agree with), and I also mentioned the security risks associated with it, since that too was relevant to the control panel software in question--much more than 1-5% of speed increase with compiled C daemon vs. Perl.



Now how exactly it is slow. Even in schools they teach about interpreted languages and compiled languages. And I am sure you'll know that compiled languages are anyday faster.


When exactly did I say that interpreted would be faster than compiled? It can be, since it depends on how efficient the code and routines are--after all, people can easily write very slow C, C++, etc. code. But, over all, I clearly didn't claim that--in fact, I said that "you're not going to get much faster than C".


I was just trying to say that.


But you ended up saying "Perl is slow". But the fact is, it's not... not enough to make any noticeable difference to anyone, unless there was something wrong with the code. And, you said this, when your current design is slower than that, even if you do call to a C++ program in the end.


But then I am sure you'll have data to back up the speed of perl compared to C or PHP . Where is it?


You're not making sense. Firstly, this depends on the code, how it's implemented and much more. For example, your design runs everything through the Apache web server as the back end for the control panel. This means that unless you run mod_perl, FastCGI, or write a module in Perl, that you'll have to run it as CGI, which will have more overhead--that is due to your design. Mod_perl is faster than a C program running through CGI, but it's not the language that's at fault.

You could write a Apache module in C and it would be faster than the C or Perl CGI script. The same for PHP, if it's a module, CGI, etc. And, any of these being compared in different ways--all of them being daemonized and run more efficiently. Then, is it *encoded* PHP that takes more or less resources, is it running through a web server, rather than deamonized, is it forking, preforking, threaded, multiplexing, or Perl compiled (it can be easily) as C in the end? What exactly do you want me to give examples of? Hey, you said Perl is slow, over all, in the first place... and you can show something to back that up? Should I ask you 'where' that is?

Hey, don't blame me for your design, I was pointing out the problems with it, as I was explaining how your claim that Perl is slow, was not true. I said that someone would have to be foolish to design a control panel to run a web server as the backend and run as root. I then said that I saw you were, so don't think I said that before to flame you--and I then pointed out how your design is insecure, and also that it's not even any faster anyway, due to how it's run--and I then said that I was interested, in light of those facts, of why you just blurted out that "Perl is slow" as if people should automatically stay away from anything coded in Perl, when you use the setup/design you use. Again, not to flame you, but I had to think "WHAT!?". :-)


Or is it just written text with a lot of big words. Also have you heard of Zend optimizer.



Heh heh, see what I mean. Don't blame your design on me. Anyway, like I said, if you want to run Apache as root for your backend and then compare an Apache module running through Apache, instead of a CGI script running through Apache, then if you think that means something, so be it. It would be faster/more efficient to run a daemon over passing everything through a web server. It's insecure, it's slower, it's more overhead, and you can only take advantage of the things that Apache offers--which is not what you want to limit yourself with in regards to a control panel and how it runs. Blame me for that if you wish.

Part II:


As far as ikonware goes. Can I know how you know the internal of ikonware.


Because it hasn't changed since you poornam company was working on the original HostGUI, which ended up having to be trashed. Because I saw how it's all working.


As far as I know you are not a customer of mine. binaries large .... ???? OMG....


Oh, I'm hurt... yeah, anyway, this is why I clearly said I wasn't flaming you, but as I suspected, this would be the response I'd get--but I posted to make a point to the other viewers of this thread, so they can know the actual fasts and truths of the matter and that Perl is a very good choice for a control panel and they should not consider on not using one.


I know of one Tim who once said that C++ is the way to go for a control panel. And that we must not write in Perl. Thanks to him we had to rewrite the entire project from Perl to C++. End result we lost money, client and name.... :(


You lost a client, because your C++ code was poor and your version of the control panel, after 1 or 2 years of your team working on it, had ways to get root from the user side of the control panel, with probably every feature you had on the client-side. That is why you lost your client, they paid you anyway (I can't imagine why) and I'm not sure what you mean about loosing a name.

Anyway, you guys should have said you aren't able to code it in C++--and for the record, that wasn't my idea, NOR was it my idea to use Apache as the backend. When I was asked to look at it, I was told it was to be coded in C++ with a PHP frontend, I saw the code was currently Perl--that was not my decision.

Anyway, what does it matter now? You were fired for being 6 months late, with a basic control panel that has major security bugs in it, and the design, and you were still paid for it anyway, even though they couldn't use the code due to it being so poor--and you still were able to use that code anyway, finish up a few things and release it as your own to make money. This was a _bad_ thing for you?

Not that I really care if you blame me, but I didn't see any of what I did in my original response to you because of the above issues, nor did I make it personal, which you are now trying to do--which only backfires on you anyway--look above. The reasons why I mentioned this, was for the reasons my post outlined, which are clear and not flaming. So, you want to blame me for this, fine.

As for saying it should be in C++ over Perl, I'd have never said this, I would have said C, since it's slightly faster, if I was worried about speed this much. As for PHP, I'd never have said this, there's better ways to use a frontend and PHP is too buggy and insecure (a long history of it, read the security lists) and I'd therefore never use it as a frontend to a control panel and have my entire project at risk if PHP has another issue--especially since your frontend is running as root through Apache. Finally, I'd have said to create a daemon, and never recommend running through Apache. But, apparently all of those designs you created are my fault. Fine.


But then people learn and grow with experience....


And apparently some do not. Tell me, did I personally say this to you, that it was my decision and it must be this way? If you recall, you were already coding it since Dec or Nov of the previous year, the C++ w/ PHP was already the plan. I came in Jul of that next year when I was asked to look. You're trying to make me out to be someone that had to 'learn' what I said in my original post since that time, or that I made a bad decision that you are apparently still using and basing your current product on--for some reason? Neither is true.

Case in point; You claimed Perl is not a good language to use, you claimed Perl is slow, you claim a lot of things.. yet, you state above, that you originally wanted and had coded it in Perl--until some big meanie made you convert it to C++ (not that the Perl code you had was any better or worse than the C++ code). Why then, did you stick with this design and the actual code too? Which story do you plan to stick with? How is any of this, what you did then, or now, my fault? What does this have to do with me? That was just a poor attempt to make me look like the bad guy for pointing out the problems and the reason why Perl might be slow for you--but there's more to it anyway--like that you're not at all a team of Perl programmers.

I didn't say what I did to insult you, but point out the problems, especially in regards to speed and why it may seem like Perl is "slow" to you, due to your design. Your attempts to discredit my post or insight into this issue because you feel insulted are unfair and untrue--don't blame me for your design. This is a design (and code!) you were already paid to have done, it couldn't be used and you ended up using it anyway--I fail to see how you are upset about this.


Perl is a wonderful language and is the fastest for development and it is very easy to learn. But for a control panel it is not ideal.


Perl is more for quick development, it's a complete language. It is, in fact, very ideal for a control panel. And besides, you DID say Perl is slow, so shouldn't you list that as a reason--and then maybe show an example of how it's slower than your design, if it's used properly?


Those who have developed control panels would know that the backend involves quite a lot of work. A simple things like add account means atleast 8 file operations. That takes time.


Ironically, I'd feel I should say this to you. Anyone can throw anything together--what does that mean? I have, in fact, done this very thing, in case you weren't aware and I know everything that's involved and I know that if you claim this, it's based on your not knowing Perl well enough--your code showed that, I don't have to guess. And besides "Those who know", would not claim this when they use a web server as the backend. :-)

I suggest, one day, you learn Perl. Nothing simple takes more code in Perl than it does in PHP or any other language. If you knew Perl, you'd know these things. Given your C/C++, Perl and shell code, I am not surprised you feel this way. Perl's motto, that they live up to very well for people that can code in it, is "Make the easy things easy and the impossible things possible".

I can't think of anything that would take a longer time or more functions or operations to do in Perl that wouldn't take just as long or longer in C, C++, PHP, etc. I'm not going to say "maybe I just know Perl better than you", because I know I do--that's not an insult, I've been coding in it a lot longer than you have and don't just assume it's a poor choice because I don't know how to use it--I don't do that with any language if I can help it.


Have a great day :)

Regards
Amar

Indeed.

Anyway, as much as you feel the need to accuse and belittle me for making a point, they were true and valid. I didn't pick on the quality of your coding in my last post--and I didn't want to bring it up in this one, because it makes my post look petty. However, people don't know what I do about it, the code and the design. I had to deal with this code of yours for a year and I do know and I think it's pretty relevant to your trying to act like what I said is something that can just be dismissed and how you were the victim of other people's decisions.

That control panel was supposed to be coded in C++ and PHP from the start, and that wasn't my decision nor design. Instead, you blame a warning from me about your still current design, from that old one, with even most of the same code, which is 100% true and relevant--you'll see when the next Apache or PHP exploit come out--just as you always blame others and accuse them of things (I won't get into that). The facts are facts, I've pointed them out, there's no reason for this to get personal. If you have a problem, email me. This is all I will say to you, tell stories if you feel the need. Whatever...

How is this even a conversation? I think we can all agree on some simple facts here:

Compiled languages are faster then interpreted languages generally.
Perl is not really a "slow" language (meaning, runtime is not any slower then a comparable languages runtime).

Now Tim, I do question some of the things you said. First, saying "Perl is usually faster then PHP" is rubbish. It depends entirely on the point of the script. Would you still make the above statement if the script were doing massive amounts of DB calls to MySQL? The design of PHP makes it's modules (such as *SQL, Curl, encryption etc) run faster then Perl modules, since the support is compiled into the PHP binary.

Regardless, when it comes to coding for the web, using mod_perl and mod_php would result in VERY little difference in runtime if the code is written well. Sure Perl may be .00343 seconds faster on one page and PHP may be .00344 seconds faster on the next, it's silly to go into so much detail. I'd honestly be willing to bet perlcc and zend encoding result in pretty close speed increases overall (Not because the Zend Engine runs faster then the C/C++ engine, but mostly because perlcc doesn't make the most efficient code).

All that said and done, anyone who picks a control panel based soley on the language it was written in is a moron anyway. Let's see... I really like PHP, yet I use CPanel...

Originally posted by comphosting

Now Tim, I do question some of the things you said. First, saying "Perl is usually faster then PHP" is rubbish. It depends entirely on the point of the script. Would you still make the above statement if the script were doing massive amounts of DB calls to MySQL? The design of PHP makes it's modules (such as *SQL, Curl, encryption etc) run faster then Perl modules, since the support is compiled into the PHP binary.


Yes, it depends on how you run it, but as a deamonized version, which you'd want to use, it is not faster. Like I said, Perl is usually faster, but I didn't say it was signficantly faster and it depends on what you're doing, the environment you're running them in, etc.


I'd honestly be willing to bet perlcc and zend encoding result in pretty close speed increases overall (Not because the Zend Engine runs faster then the C/C++ engine, but mostly because perlcc doesn't make the most efficient code).


Perlcc doesn't make the most efficient code, as much as C coded efficiently would, of course. However, the difference between Zend and compiled Perl->C code, is pretty significant.


All that said and done, anyone who picks a control panel based soley on the language it was written in is a moron anyway. Let's see... I really like PHP, yet I use CPanel...

You'd probably be right, which is why his comments telling people to be wary of the speed of the language it's written in is something to take into consideration, and then goes on to say "Perl is slow", is why I responding pointing these things out.

My comment wasn't about PHP being slower, it was that it's slower in the way it is running in their product. I don't think anyone will notice Perl being any slower than PHP if they are set up properly, even if it might be a little faster--but that all depends and like I said, set up properly, I doubt anyone would notice any difference at all in the speed. I hope that's more clear.

As said by my guru.
"you would only fight a battle where you lose because even if you win you lose your time"

I am not wasting my time here because I fully realize what you are upto as always.


Regards

Amar

Yes, it depends on how you run it, but as a deamonized version, which you'd want to use, it is not faster. Like I said, Perl is usually faster, but I didn't say it was signficantly faster and it depends on what you're doing, the environment you're running them in, etc.

True enough. I guess at least you and I can agree the speed of Perl or PHP shouldn't be a deciding factor.

Perlcc doesn't make the most efficient code, as much as C coded efficiently would, of course. However, the difference between Zend and compiled Perl->C code, is pretty significant.

I'll have to agree I suppose, since I've never tested it, and I guess I'd be hard-pressed to believe that Zend is anywhere near as fast as C. Personally, I'll let Perl have perlcc... phpcc program would just cause more 12 year old's to write crappy PHP code... we have enough of those.

You'd probably be right, which is why his comments telling people to be wary of the speed of the language it's written in is something to take into consideration, and then goes on to say "Perl is slow", is why I responding pointing these things out.

Agreed... it was rather silly, but that's an assumption people make when they only run Perl in a CGI enviornment. People hardly seperate the difference between Perl & CGI. But I have run applications as a CGI and as an Apache mod, and I have to say the difference did take me by surprise. I don't think many people realize the overhead that CGI causes.

My comment wasn't about PHP being slower, it was that it's slower in the way it is running in their product. I don't think anyone will notice Perl being any slower than PHP if they are set up properly, even if it might be a little faster--but that all depends and like I said, set up properly, I doubt anyone would notice any difference at all in the speed. I hope that's more clear.

Yes I completely agree. In some situations the difference is noticable, but primarily to a programmer looking for a noticable difference.

I guess the moral of this story, is to choose a control panel based on your experience, independant reviews... and TESTING. Most companies will give a trial license, so if you are serious about hosting, take advantage of the license and see what fits you best... Just don't make untrue comments about Perl or Tim tends to come after you ;).

Tim_Greer would please stop writing books and just give a couple of paragraphs to your answers, man this a discussion board not a book store.

Originally posted by MikeeeZB
Tim_Greer would please stop writing books and just give a couple of paragraphs to your answers, man this a discussion board not a book store.

Nothing is more annoying then someone that can't comprehend a discussion, and therefore adds garbage to it.

DISCLAIMER: Yes I did just do the one thing I bitched about, but hey, we all know I'm not trying to increase my post count.

Originally posted by bobcares
As said by my guru.
"you would only fight a battle where you lose because even if you win you lose your time"

I am not wasting my time here because I fully realize what you are upto as always.


Regards

Amar

And, like I said, this was expected. No one can point anything out. Everything I pointed out was completely valid and true. There's nothing you can argue, which is why you simply accuse people of flaming you or being petty and say this nonsense.


Yes, apparently people are just out on a mission to make you look bad--let's just ignore every single valid point made and you can sell your insecure control panel by claiming that others that are coded in other langiages are too slow because they aren't yours. Wonderful. Oh yeah, I'm really 'up to' something for pointing out a problem (many). :-)

Originally posted by MikeeeZB
Tim_Greer would please stop writing books and just give a couple of paragraphs to your answers, man this a discussion board not a book store.

Calm down. If you can't handle reading over a few paragraphs that make several points (hence the reason for more than two), without getting all flustered, then don't read my posts. Not everything can (*or should*) be summed up. It's a dicussion, if covering all the relevant points and making points to back them up bothers you, I can't imagine why you'd come to a web board in the first place. Anyway, this is way too off topic, so move on.

Originally posted by comphosting

Personally, I'll let Perl have perlcc... phpcc program would just cause more 12 year old's to write crappy PHP code... we have enough of those.



I'm not sure I understand what you mean about perlcc causing more 12 year olds to write crappy code, if PHP had this feature?

...the moral of the story is that the code will only be as efficient (note the choice of word) as the quality of the coding. Cr*p C code could easily be slower than good Perl code, and cr*p Perl code could be slower than good PHP code.

Once you stick it behind a web server and run a control panel with it, the user is unlikely to notice at all, so long as it "seems" fast enough to them and it uses server resources such that it doesn't adversely affect performance, you've done your job.

So, please leave your coding prejudices at home and compare products based on end-user experience and systems administrator experience.

And my final words, Perl is fab, but other languages can be too ;) :cool: :stickout:

Originally posted by chirpy
...the moral of the story is that the code will only be as efficient (note the choice of word) as the quality of the coding. Cr*p C code could easily be slower than good Perl code, and cr*p Perl code could be slower than good PHP code.

Once you stick it behind a web server and run a control panel with it, the user is unlikely to notice at all, so long as it "seems" fast enough to them and it uses server resources such that it doesn't adversely affect performance, you've done your job.

So, please leave your coding prejudices at home and compare products based on end-user experience and systems administrator experience.

And my final words, Perl is fab, but other languages can be too ;) :cool: :stickout:

Indeed, it is the code, how skilled the coder is, as well as other factors such as the environment it runs it--as to not only how efficient and fast it runs, but how secure or stable it is. I'll say two more paragraphs (gasp! :-) and end my participation in this--it's up to the reader to decide and educate themselves if they need or want to from there;

Some environments are more or less stable or secure, as mentioned in this thread (even if it was "mean" for me to illustrate those reasons), and while some are more resource intensive, have a larger memory footprint, or are higher or lower level, etc., they can work--any of them--as long as they are coded well and run in a well suited environment.

I'm not saying this for any other reason than a warning, but I highly suggest no one have the idea of running the Apache web server as root, this is very dangerous and there's nothing you can do, short of coding your own daemon, to get around that issue. If that makes me a big meanie with ulterior motives and adds suspicion for some people, then do be it.

I highly suggest no one have the idea of running the Apache web server as root

I can only wholeheartedly agree. You're a fool if you do so and are simply asking for hackers to come visit you and do naughty things to your server - you'll usually never know until it's waaaay too late.

Why would anyone take such a stupid risk? Using a daemon in whatever language you use with a sensible secure handshaking protocol is just plain common sense. Don't risk your company on someone elses code (Apache - it's great, but do you know every line of its code?), at least if you code a daemon you (should) know exactly what is going on.

I find it amazing at the number of control panels that directly control the system through there interface.. Thats trouble waiting to happen..

And then the people that feel they are secure just because they use a background process, yet pass the command to run from the control panel to that background process... So even though your panel is not running as root, bad commands can still be passed on... More secure, yes because you don't have to worry about apache exploits, but still bad, since a small code mistake can kill you.

The control panel itself should do nothing but parse data and pass it on to another program that accepts only very specific requires and commands..

This makes it next to impossible to send fake signals.. run fake commands and a number of other possible exploits get shoot out of the water with just a little though.
[PHP]
Bad
Client -> Server "passwd user password"

Good
Client -> Server "changepass|user|password"
$action = explode("|",$incoming);
check $action[0] for valid command
check $action[1] for valid username
check $action[3] for bad info/possible command line injection hacks.

{/PHP]
This makes it impossible to pass any command you wish, Lets you do multiple checks on each piece of the puzzle.

escapeshellcmd is not the holy grail of protection people.. I fear the control panels that rely on that alone.

Originally posted by cyberlot


Good
Client -> Server "changepass|user|password"
$action = explode("|",$incoming);
check $action[0] for valid command
check $action[1] for valid username
check $action[3] for bad info/possible command line injection hacks.





Yes, checking for input is a given. What you need to check for, all depends on the valid characters that may be contained in the field--and how you pass those to programs, if you need to, and the interface and how that interface may pose risks. Checking for pipe and semicolons and so on for any field that will be piped to a program as in exec("/bin/program $field") is a bad idea even if you check the fields. Passing fields in that env is a risk for such information.

Suppose someone's running a tool to view the processes? They could see these fields being passed to the other program. How you intend to pass the commands safely to not have the arguments able to be seen or stored in a /proc/\d+ pid env, etc. is something to consider as well, of course.

You are actually better off having it all exclusive to the control panel process itself for those reasons. Yes, that can open you to mistakes and issues with locking and things that tools will do for you and check for any changes, etc., but if you can't safely code for that and deal with it properly, you shouldn't be writing a control panel.

However, there's great ways to do this without the worry if someone's changing or writing to the same file by using a different tool anyway. While it's true that relying on system tools to do work for you more securely and properly, it's not that difficult for a GUI to interface and be perfectly secure.

Also, it's not as if some of these tools don't have problems of their own, if you were to try and pass arguments to them--and that could be less safe and may be unneeded. It really all depends on how you do it, but I'd worry about the backend and interface being a risk if they weren't implemented properly.

Don't mistake what I'm saying now to mean that there's any good reason to reinvent the wheel, but for interaction on some levels, it can be as safe or safer to use something that will work within the program/process itself (you should be dropping the privileges anyway), rather than passing arguments to existing tools.

Please please please tell me your joking, Your last post was one big joke right?

You did not program everything through a single system because you thought your commands would otherwise be seen through process utilitys..

Please do not tell me your programming a control panel and you can't even figure out how to secure communications between 2 processes.

Geez... if anyone out there wants a control panel with some thought, and not put together by a hack with duct tape.. Contact me.. I would be more then happy to take your money.

God I feel soooo sorry for you that I just had to give you some much needed help..


SSL SOCKETS =
1. Commands that can not be seen on the process list.
2. Secure, can not be sniffed by local users.


And get this.. This is the LEAST secure/First method I considered using and something ANY programmer worth anything should of thought of..

Your whole, Well your commands passed would be visible in the process list is a bunch of crap and shows your either stupid or lazy.

Hey Hey... all this talk about panels. I didn't see HostGUI mentioned.... I heard it is due to be released soemtime around May 2002.

:D :D :D

Originally posted by cyberlot
Please please please tell me your joking, Your last post was one big joke right?


No, I wasn't joking.


You did not program everything through a single system because you thought your commands would otherwise be seen through process utilitys..


No, I didn't.


Please do not tell me your programming a control panel and you can't even figure out how to secure communications between 2 processes.


I'm not telling you that, no. You're assuming.


Geez... if anyone out there wants a control panel with some thought, and not put together by a hack with duct tape.. Contact me.. I would be more then happy to take your money.

Uh huh. You either didn't listen to what I said, or you weren't able to comprehend it. Either way, this isn't going to reflect on you well.

Originally posted by cyberlot
God I feel soooo sorry for you that I just had to give you some much needed help..


Your responses are making you look "not smart".


SSL SOCKETS =
1. Commands that can not be seen on the process list.
2. Secure, can not be sniffed by local users.


So, you're going to pass arguements to a program through the web over SSL? I think you're confused, of course you'd use SSL for the connection between the client and server, but not between the control panel and the tools it passes arguments to.


And get this.. This is the LEAST secure/First method I considered using and something ANY programmer worth anything should of thought of..


Yes, no kidding. Of course, that's not what I was talking about--your original post didn't mention this either. We were talking about how things are done on the system.


Your whole, Well your commands passed would be visible in the process list is a bunch of crap and shows your either stupid or lazy.

You have absolutely no idea what you're talking about, or who you're passing your nonsense to. If you didn't understand what I said (which was relevant in response to what you said), then that's your issue, not mine. However, I'm thrilled to see you think so highly of yourself. Oddly enough, it just doesn't do a thing for me.

Originally posted by Tim_Greer
I'm not sure I understand what you mean about perlcc causing more 12 year olds to write crappy code, if PHP had this feature?

Meaning there would be even more crappy PHP coders, because then they could write "executable" code with PHP... we already have enough ****ty PHP programmers as it is :)

Originally posted by comphosting
Meaning there would be even more crappy PHP coders, because then they could write "executable" code with PHP... we already have enough ****ty PHP programmers as it is :)

I'm not sure I understand how allowing someone to run a script as compiled or non compiled (interpreted) would make the coder or quality of code any worse. I mean, it would be the same code, they could just compile it. Do you mean that you couldn't see how bad the code was, if it was compiled? If so, I can understand in what way you mean this could be a bad thing. And, trust me, there's probably just as many bad Perl and C, C++ coders out there as one's that code badly in PHP.

Originally posted by Tim_Greer
I'm not sure I understand how allowing someone to run a script as compiled or non compiled (interpreted) would make the coder or quality of code any worse. I mean, it would be the same code, they could just compile it. Do you mean that you couldn't see how bad the code was, if it was compiled? If so, I can understand in what way you mean this could be a bad thing. And, trust me, there's probably just as many bad Perl and C, C++ coders out there as one's that code badly in PHP.

Exactly what I was getting at. At one point, it wasn't so bad, but now with Zend and Ioncube, crappy coding is not only accepted, but rather easy. You may be right about the crappy coders in all languages, but it seems the ease of learning PHP's basics, makes it a big target.

Sorry for my last post, I found it slightly hard to understand how you could
not see the simple point I was making and did let myself get out of control.


Anyway Tim, its called PHP's socket commands which support SSL encryption.

Your client, which doesnt run as root, sends this information through a encrypted channel to your root deamon.

The root deamon then handles everything securely including calling the proper tools or editing the proper files directly.

Since your control panel is not directly running as root.. Minor flaws are less likely to make you open to hacking, and known apache flaws will not give a user root access.

My comments came out of your specific defense of your method as stated by you.

Checking for pipe and semicolons and so on for any field that will be piped to a program as in exec("/bin/program $field") is a bad idea even if you check the fields. Passing fields in that env is a risk for such information.
And

How you intend to pass the commands safely to not have the arguments able to be seen or stored in a /proc/\d+ pid env, etc. is something to consider as well, of course.


By this quote alone you yourself assumed I had no idea what I was talking about, And at the same time suggested that you are using your method due to this "restriction" that does not exist if you code properly.

So before you try to defend yourself by saying im not making myself look smart.. Take a step back as I have done, and review your own comments.

Originally posted by comphosting
Exactly what I was getting at. At one point, it wasn't so bad, but now with Zend and Ioncube, crappy coding is not only accepted, but rather easy. You may be right about the crappy coders in all languages, but it seems the ease of learning PHP's basics, makes it a big target.

The majority of bad coders I've seen are primarily PHP and Perl coders--but there are a lot of skilled coders in both as well, luckily. Any scripting language that's popular draws a lot of people that think they can just throw something together and think as long as it works from what they can see, that's all there is to it.

PHP draws more of these type, because they don't have to learn about other things like permissions and ownership issues as much as they do with Perl and CGI. But, it's probably equal. Anyway, I think you'd have a pretty good idea of the quality of code, even if you couldn't see it if someone was that bad, it's usually pretty obvious.

So what you're saying is, by using PHP Sockets for an encrypted connection, it's full-proof? Nope, there's still a single point of failure in the connection with the backend. Using the method you've mentioned, if there were a security breach in PHP Sockets, it would be no different then running Apache as root in the backend, or any other method for that matter.
The very definition of a control panel, requires them to be reliant on third-party software. Running Apache as root is probably the stupidest thing you can do, but a serious flaw in PHP could make your design FAR more dangerous under certain circumstances.
My point? It's all moot... You still rely on the security and stability of third-party software. Unless of course, you intend to write the httpd server, mail server, ftp server, dns server AND operating system it runs on yourself.

Originally posted by cyberlot
Sorry for my last post, I found it slightly hard to understand how you could
not see the simple point I was making and did let myself get out of control.


Anyway Tim, its called PHP's socket commands which support SSL encryption.

Your client, which doesnt run as root, sends this information through a encrypted channel to your root deamon.

The root deamon then handles everything securely including calling the proper tools or editing the proper files directly.

Since your control panel is not directly running as root.. Minor flaws are less likely to make you open to hacking, and known apache flaws will not give a user root access.

My comments came out of your specific defense of your method as stated by you.


And


By this quote alone you yourself assumed I had no idea what I was talking about, And at the same time suggested that you are using your method due to this "restriction" that does not exist if you code properly.

So before you try to defend yourself by saying im not making myself look smart.. Take a step back as I have done, and review your own comments.

Originally posted by cyberlot
Sorry for my last post, I found it slightly hard to understand how you could
not see the simple point I was making and did let myself get out of control.


I can say the same... let's not argue about that.


Anyway Tim, its called PHP's socket commands which support SSL encryption.


And that is irrelevant to what you originally stated.


Your client, which doesnt run as root, sends this information through a encrypted channel to your root deamon.


Why waste the extra processing? The end result of the daemon that's running as root, will still be doing the same things anyway.


The root deamon then handles everything securely including calling the proper tools or editing the proper files directly.


And why exactly would you need the top layer in PHP to call a process running as root to then do the work? That's a lot of nonsense. You shouldn't be writing it in PHP anyway, and why even bother with the top layer with the bugs and security issues it has? If your checking goes awry, then the rest of the steps are vulnerable--so you have to have the root daemon check anyway... why check twice?


Since your control panel is not directly running as root.. Minor flaws are less likely to make you open to hacking, and known apache flaws will not give a user root access.


Yes, if you're stupid enough to run Apache as root and use PHP for the panel's frontend at the same time. But, who the hell was talking about doing that anyway? This is what I discouraged. So, like I said, this is irrelevant. Why would you at all reply on PHP running with Apache, root or not? As non root, you still have the ability for people to exploit vulnerabilities and alter or bypass the frontend. It simply doesn't make sense to bother with.


My comments came out of your specific defense of your method as stated by you.


My method? Explain.



And


By this quote alone you yourself assumed I had no idea what I was talking about,


Yes, that is correct, that is what I thought.


And at the same time suggested that you are using your method due to this "restriction" that does not exist if you code properly.


But it does exist, and I did *clearly* state that it "depends on how it's done" and that I did not claim it couldn't be done securely. Your ranting is what made me come to the conclusion I did. I am not interested in hearing how smart you think you are. It's better to stick to the facts and the discussion.


So before you try to defend yourself by saying im not making myself look smart.. Take a step back as I have done, and review your own comments.

You know, we can argue about how smart we both think we are all day, but it's probably a waste of time. If you choose to interpret what I said for anything other than what I said, then we're not going to get anywhere and there's no reason to continue this discussion (assuming we could call it one).

Anyway, you were not at all clear on how you were going to pass those arguments to the tools in question. I stated this method _could_ be insecure and it is more secure to not do this (it's not going to be _less_ secure to not do it). You may pass from PHP top end to the root daemon using a secure socket, because that's the only way you know how to pass arguments between commands securely, but that's not always the best solution, and it's wasteful.

Also, consider that once the root daemon runs it, it's still going to make the calls to the tools in questions and it has to pass these commands with these arguments in a secure manner as well--so now you do three times the amount of checks and calls, and it's not anymore secure, it's less portable and it's a waste of processes, and coding time. But you know what, do it however you want. If it's a secure, stable and good product that doesn't suffer from problems like the aforementioned one(s), then good luck to you... it'll be nice to see another alternative.

Originally posted by comphosting
So what you're saying is, by using PHP Sockets for an encrypted connection, it's full-proof? Nope, there's still a single point of failure in the connection with the backend. Using the method you've mentioned, if there were a security breach in PHP Sockets, it would be no different then running Apache as root in the backend, or any other method for that matter.
The very definition of a control panel, requires them to be reliant on third-party software. Running Apache as root is probably the stupidest thing you can do, but a serious flaw in PHP could make your design FAR more dangerous under certain circumstances.
My point? It's all moot... You still rely on the security and stability of third-party software. Unless of course, you intend to write the httpd server, mail server, ftp server, dns server AND operating system it runs on yourself.

This is only one of many possible risks with such methods--though I actually did think he was literally talking about just passing he arguments as in my original example, given his posts. I'm glad to see that he's not considering that, but I thank you for pointing out one of many faults in this logic and illustrate why this isn't the "best" method and one of the reasons for it. There's just too many points of failure with such a method to make it more secure than the methods previously mentioned. If this individual chooses to take that as a challenge or an insult, then whatever.

Holy cow. I am sorry I even replied in this thread. Unsuscribe. :D

Im pretty sure no where did I say "fool proof" Just mentioned. There is going to be a fail point in almost anything, plus I would not use SSL/sockets alone for verification. ( In reality I wasn't planning on using SSL at all, I have another method in mind, this was just the easiest and does not give away any secrets )

However you can try your best to reduce your risk.

Originally posted by cyberlot
plus I would not use SSL/sockets alone for verification.

Jesus... this control panel idea of yours is going to have some major overhead... by the time it's finished "verifying" it'll be three times slower then Cpanel

Originally posted by cyberlot
Im pretty sure no where did I say "fool proof" Just mentioned. There is going to be a fail point in almost anything, plus I would not use SSL/sockets alone for verification. ( In reality I wasn't planning on using SSL at all, I have another method in mind, this was just the easiest and does not give away any secrets )

However you can try your best to reduce your risk.

Well, I can't imagine what you were arguing about then. I explained how it's more of a risk in different methods, with and without SSL. I don't see the point to all the extra work--this doesn't equate to 'easier', especially with all the points of potential failure, what with the web server, PHP and functions or modules PHP uses (which isn't uncommon).

Why didn't you/don't you, instead, outline the way you think makes it better and how it illustrates that my idea of not relying on the method you prefer, is somehow ridiculous or inferior--that's what you said after all, I'd like to see you outline how this is so. After all, you seem to think it's stupid or lazy. Explain how that is--since you assume to know what I was talking about--and I can explain that I wasn't talking about that how you thought, if at all. Anyway, all in all, no one's ever argued that using whatever workable method to improve security is a bad thing.

PS: Regarding points of failure, an exclusive system of your own (no it doesn't have to be one program or process!) doens't have to suffer from any points of failure, which was my 'point' that I hope I didn't 'fail' to make clear to anyone else.

I gave suggestions not specifics because I feel its unique in some methods and has advantages I care not to give away. I was just trying to point out some possible issues and give just the basic details of possible solutions.

Just because there is more then one process does not mean more overhead/slower.. Example in point.. Apache, Mysql, all use multiple processes to speed things up..

As to all my verification causing some overhead.. Since the main engine and the user control panel are 2 seperate pieces of the puzzle, the overhead will have less affect on what a customer sees. Worse possible thing, A persons forward takes 30 seconds to be active, but the person will never see that at there end. And that is a very extreme example. If this means a more secure panel ( which cpanel by many peoples accounts is not ) then I think that minor tradeoff is well worth the effort.

When it comes to security a person should never say things like "I don't see the point to all the extra work". Instead all possible methods should be reviewed and tradeoffs considered.

A person should look at the clearest route to break there product and see if there is a solution to protect against that route. Will that solution add to your overhead.. Yes in most cases.. Is that increase extreme? Does your security increase enough for this solution to be valid.

Consider this.. Why do police travel in pairs ( on average, in america ). It increases department costs, It requires twice as many people to cover the same amount of space, but overall the positive side of having to police officers together outway the possible downsides.

Why do planes have redutant systems.. they could reduce the size and weight of the plane im sure by removing them.

One must decide from the start what aspects of there program are most important to them and build on those aspects.

Control panels, no not just control panels but programs in general today are overloaded with features that people rarely use, they put them in for the sole reason to sell more product and in the end some control panels are bursting with bugs and security risks. In the end we have bloated products that force us to upgrade just to use the basic of functions.

Some of us like to think "outside" of this box. I myself plan on making security one of the most important items on my list.. How about you.

cyberlot - I think the point Tim was making was that your example of SSL sockets between two processes merely moved the problem to the layer below the PHP, where you still have the same issue of executing the commands you want carried out - You just moved it down a layer and added overhead with no tangible benefit.

Originally posted by cyberlot
I gave suggestions not specifics because I feel its unique in some methods and has advantages I care not to give away. I was just trying to point out some possible issues and give just the basic details of possible solutions.


Well, this didn't change anything. You didn't outline how the other method would be worse and the method you mention suffers from more problems.


Just because there is more then one process does not mean more overhead/slower.. Example in point.. Apache, Mysql, all use multiple processes to speed things up..


Well, that doesn't make sense. Instead of one process, you have three or more. We're not talking about threading, we're talking about a call to PHP, through Apache, to a daemon, and then to a tool. This is inefficient, has many points of failure and security risks.


As to all my verification causing some overhead.. Since the main engine and the user control panel are 2 seperate pieces of the puzzle, the overhead will have less affect on what a customer sees.


It may not be slow enough for them to notice, true. But you have multiple points of failure.


Worse possible thing, A persons forward takes 30 seconds to be active, but the person will never see that at there end. And that is a very extreme example. If this means a more secure panel ( which cpanel by many peoples accounts is not ) then I think that minor tradeoff is well worth the effort.


There's absolutely no reason to have such a trade off. This is only a trade off if you implement it in a poor method that you have to face it as a trade off. There's no reason for it. Also, your method you mentioned is less secure than Cpanel.


When it comes to security a person should never say things like "I don't see the point to all the extra work". Instead all possible methods should be reviewed and tradeoffs considered.


You refuse to read posts for what they actually say. No one said that the extra work isn't worth it if it'll improve security. You're trying very hard to twist what people said. The fact is, people clearly said this is a lot of extra work for no added security, and in fact, it's less secure.


A person should look at the clearest route to break there product and see if there is a solution to protect against that route.


Ideally, there should be no way to break it.


Will that solution add to your overhead.. Yes in most cases.. Is that increase extreme? Does your security increase enough for this solution to be valid.


No one argued that security isn't worth added overhead if it's reasonable.


Consider this.. Why do police travel in pairs ( on average, in america ). It increases department costs, It requires twice as many people to cover the same amount of space, but overall the positive side of having to police officers together outway the possible downsides.


This is irrelevant to this discussion. Don't pretend that you are thinking more clearly of efficiently than others because they point out flaws in your method or design.


Why do planes have redutant systems.. they could reduce the size and weight of the plane im sure by removing them.


You're just typing nonsense, security and such is not anything that anyone in this thread, at any point, said anything against ot showed signs of not thinking it was important or obvious.


One must decide from the start what aspects of there program are most important to them and build on those aspects.


Yes, and that is a given. That has no relevance to this debate though. Everyone recognizes all of these things, and using that frame of mind, pointed out how your system would fail to be more secure.


Control panels, no not just control panels but programs in general today are overloaded with features that people rarely use, they put them in for the sole reason to sell more product and in the end some control panels are bursting with bugs and security risks. In the end we have bloated products that force us to upgrade just to use the basic of functions.


Yes, that's true.


Some of us like to think "outside" of this box. I myself plan on making security one of the most important items on my list.. How about you.

Most people do like to think "outside the box". Because we see faults in the design you claim is better, is not reason to think everyone else is static. As for making security the foremost issue, I agree on that. You sarcastically ask "What about you". Odd, you seem to neglect that you're the person that outlined the idea that was most insecure. This response is not a logical or good way to justify that.

This is my last toss on the subject as its going no where..

As you pointed out, I didn't outline my method period, so I would like you to explain how its less secure then your method.

Multiple points of failure, Again my method has never been explained fully so how bad these failures are.

How is it a poor method, again you don't know exactly what im doing.

As to my analogy, sorry do tech support alot and tend to toss those out in a attempt to bring a point into the light when someone isnt understanding. Analogys by there use tend to be irrelevant to the subject because they are a method to use terms a person might understand further to explain a point.

Originally posted by cyberlot
This is my last toss on the subject as its going no where..


Agreed.


As you pointed out, I didn't outline my method period, so I would like you to explain how its less secure then your method.


Read, for once, what I said. I didn't say your method you don't want to 'disclose' is, I said this about the method you outlined.


Multiple points of failure, Again my method has never been explained fully so how bad these failures are.


I only pointed this out with the methods you outlined--not your method you claim you don't want to disclose. And, that's fine, I'm not interested. I just made a point about the method you did outline.


How is it a poor method, again you don't know exactly what im doing.


Like I said, again, I never said that about the method(s) you didn't outline, only about the one's you did.


As to my analogy, sorry do tech support alot and tend to toss those out in a attempt to bring a point into the light when someone isnt understanding.


The problem is, it's you that fails to understand and you aren't reading what people are saying. A good example if that you continue to claim that "How can you say this about something I didn't outline"--I never did this, I only did about the things you _did_ outline. So, you assume I'm the one that doesn't understand? Give me a break.


Analogys by there use tend to be irrelevant to the subject because they are a method to use terms a person might understand further to explain a point.

But the fact is, everyone already understood the things you were trying to make a point about. You explained the obvious. No one asked and no one showed any signs of lacking the comprehension or understanding--there was no need... we all know. The fact is, you are just acting like you're more security conscious than the rest of us for some reason. Why you feel the need to act and think this way, I can't imagine--but there's no justification for it.

I didn't outline a poor method--you did, and you were called on it and people outlined how it would be worse. How you conclude this means that we are the one's that need examples to better explain things, is just madness. Anyway, I didn't reply to rip into you.

I didn't say your method would fail that I never heard you outline, only the one you did--and to example how it has faults (since you outlined it as if people should use it). How was I to know you just wanted to waste people's time? Really, I'm curious now of how you can be in the frame of mind to equate your lack of understanding to things outlined in the post and the facts, to actually convince yourself that the other people are the one's that suffer from the problem? Never mind, I don't care. I get it, you outline an idea and we example how it's not better, so you have to tell yourself that it's us with the problem, not you. Fine, I've seen this sort of thing a million times.

i have 2 dedicated servers since April working with hosting#accelerator.com and i don't have any problem.

-- WINDOWS CP --

My problem is linux cp :(