Panilux, is a new generation Linux control panel. Built in Nginx support!
- Thread starter rdn
- Start date
I think 2013, based on https://www.linkedin.com/company/panilux
TPerry
Well-known member
Mike Edge
Well-known member
What else is there?
TPerry
Well-known member
A much better, more up to date OS that goes by the name Debian, or it's big cousin Ubuntu.
I run a few CentOS VPS's.... and honestly, I hate them. If it wasn't for the fact I wanted to get exposure to them I wouldn't have any.Good, the sooner Debian can die the better
And I can't tell you exactly what it is about it that I don't like.. it's just one of those undefinable "things".
A much better, more up to date OS that goes by the name Debian, or it's big cousin Ubuntu.
I run a few CentOS VPS's.... and honestly, I hate them. If it wasn't for the fact I wanted to get exposure to them I wouldn't have any.
And I can't tell you exactly what it is about it that I don't like.. it's just one of those undefinable "things".
I feel the same about Debian
TPerry
Well-known member
Well, the other reason I prefer Debian/Ubuntu is that Ubuntu is a heck of a desktop distribution also. The other major complaint I had with it was that you have to either hunt down esoteric repositories for some stuff or you compile yourself - which then makes updating a real pain the keister.I feel the same about Debian
D.O.A.
Well-known member
Just looking through the demo https://demo.panilux.com:1453/ feature wise it's kinda like webmin with modules, except webmin is better 
TPerry
Well-known member
Usually when you see this, it is a pretty good indicator it's in a BETA (or not a full release) stage unless they have a weird numbering strategy.Maybe the site is the one on beta.
Another pretty good indicator is it's not fully prime time ready (not necessarily the version, but the fact that it doesn't fully set it up and that it is using a deprecated mysql extension on it's default install - not mysqli).
Last edited:
Floren
Well-known member
It's time to grow up and get out of Debian's little toys sand box. I was reading this blog entry, recently. I think is been a long time I did not have such a good laugh at the arguments presented by author.
TPerry
Well-known member
Actually it's time for CentOS to get out of the '90s.
My arguments for it.. it's what I'm familiar with, it works and I don't have to spend time compiling source for anything (which I have had to do a time or two on CentOS - I have better things to do with my time than that - I do have a life) and I don't have to worry about missing dependencies that I've come across several times on CentOS installs. It also appears that a some of what he is talking about goes back to a desktop environment (why do you need MP3 codecs on a server really?). I don't think a lot of folks use CentOS in a desktop environ do they?
And until recently, there was no easy upgrade path between versions with CentOS. It required a fresh install (back to the 90's again). The argument I heard was "well, you need to make sure the code and configs are all on the same level". My argument is that the upgrade process should do that for you. Not everybody eats/breathes/sleeps Linux, and upgrades were a major issue with CentOS.
And YOU may not agree with his "arguments" but for him and his settings they may be valid.
I do know (like I said above) that I ran into dependency problems in a base install of CentOS that should really never have happened .I think it was with the PHP stack and some of the PECL's - I don't remember exactly what it was but it happened to 2 of the of the 3 I set up and then I was contacted by another party that was having problems and it was the same issue with them also.
Last edited:
Floren
Well-known member
In 15 years time I use Linux, I NEVER stumbled into a dependency issue on RHEL.
The fact you (and others) are preferring a Linux OS major release upgrade instead of a clean install raises a lot of flags to myself. If you don't know why, there is no point in explaining. There is a reason why the smart minds at Red Had avoided this approach for years. Even now, I will never upgrade a major release and always perform a clean install.
That is because you were trying to something that other 99.9% of RHEL users base have no interest on doing so. I'm part of that 0.1% group also and that is why I created the AXIVO repository. Not everyone wants to use libmemcached, for example.
TPerry
Well-known member
I'll see if I can find what it was again. Had to do with installing one of the PECL's and that some of the libraries were an older version (specifically had to do with upgrading the PHP to 5.6 series if I remember correctly.
Really... and now suddenly the support it because it suddenly became good? I call ********. They didn't provide an upgrade path because of other reasons. That's like saying that every time you upgrade a Windows server you have to fresh install. Idiotic.
Really? They have no desire to run the latest PHP and use all the features of it?
I'll find that error and update this post shortly.
EDIT:
This is similar to one of them
Code:
Setting up Update Process
Package php54-common-5.4.22-1.ius.el6.x86_64 is obsoleted by php-common-5.5.7-1.el6.remi.x86_64 which is already installed
Resolving Dependencies
--> Running transaction check
---> Package php-pecl-zip.x86_64 0:1.12.3-1.el6.remi.5.5 will be obsoleted
--> Processing Dependency: php-pecl-zip(x86-64) for package: php-common-5.5.7-1.el6.remi.x86_64
---> Package php54-common.x86_64 0:5.4.22-1.ius.el6 will be obsoleting
--> Finished Dependency Resolution
Error: Package: php-common-5.5.7-1.el6.remi.x86_64 (@remi-php55)
Requires: php-pecl-zip(x86-64)
Removing: php-pecl-zip-1.12.3-1.el6.remi.5.5.x86_64 (@remi-php55)
php-pecl-zip(x86-64) = 1.12.3-1.el6.remi.5.5
Obsoleted By: php54-common-5.4.22-1.ius.el6.x86_64 (ius)
Not found
Available: php-common-5.4.22-1.el6.remi.x86_64 (remi)
php-pecl-zip(x86-64) = 1.11.0
Available: php-common-5.4.23-1.el6.remi.x86_64 (remi)
php-pecl-zip(x86-64) = 1.11.0
Available: php-pecl-zip-1.12.2-2.el6.remi.5.5.x86_64 (remi-php55)
php-pecl-zip(x86-64) = 1.12.2-2.el6.remi.5.5
Installed: php-common-5.5.7-1.el6.remi.x86_64 (@remi-php55)
Not found
Available: php-common-5.3.3-26.el6.x86_64 (centos6-base)
Not found
Available: php-common-5.3.3-27.el6_5.x86_64 (centos6-updates)
Not found
Available: php-common-5.5.6-1.el6.remi.x86_64 (remi-php55)
Not found
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Last edited:
Floren
Well-known member
They support upgrades for specific/targeted use cases only and do NOT recommend it. Call them to find out why, or inquire a reliable source, not a novice source.
Please enlighten us and tell us why.
Why do you use repositories that are flagged by CentOS? No wonder you get errors. You are using deprecated packages outside CentOS/RHEL supported list and you complain...
Last edited: