New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Do we need another open source webhosting panel?
Hey guys,
I was looking at open source webhosting panels like Vesta, Ajenti-V, zPanel, etc.
But they all seem to either lack core features or are a little clunky, UI or install wise.
Would another open source panel benefit the community or am I jus missing something?
I am a Nodejs dev and if there's desire I will definitely try contribute something that is simple to use and does the job. But I need your input, and if it's worth it, I could use motivation / support :-)
Please let me know!
Is another open source panel a good thing?
- Opinion: (apart from the fact CLI > *)59 votes
- Yes, I don't think existing solutions are easy to use30.51%
- Yes, but it's not really needed, but always welcome33.90%
- No, you can customize existing panels enough0.00%
- No, you should try contribute to an existing project23.73%
- No, you're just tacky. Current solutions are plenty easy to use..11.86%
Comments
@joepie91 is our nodejs guru.
I was the one who convinced him in the first place to use it :-) Back when he was still a python addict
Edit: not trying to imply anything. The implementation is not as relevant as the question itself
so can i call you the jedi
or what?
One day everything will be js!
Ideally we should try to contribute to existing projects, but sometimes it depends on how big your dick is, because if any contributor starts to measure project initiator's or other contributors' dick, then the project will suffer from stinking disease and die. Like Kloxo.
One man shows always tend to fail. You better help improve any existing open source projects. That way those chunky, incomplete software becomes better as well.
But if you want something you can sign your name under, go for it.
Yes, but only if done meticulously and the project is open to contributors. You don't want a bus factor of 1
I'm honestly not convinced that this is even a realistic possibility. Nearly all this software (except for maybe Ajenti) has a codebase that is so messy that "fixing" it would involve starting over from scratch. There's also a bit of a theme of non-cooperation in the open-source hosting panel world, for some reason.
The documentation and package management made sure that I never got to the 'addict' stage
Thanks for mention it broer. They have beautiful codes.
Was kind of surprised to find that they appear to have implemented event emitters using decorators. Pretty clever way to solve Python's lack of proper anonymous functions.
That being said, it being Python, it just smells like Another Package Management Nightmare to me. Run anything not-Ajenti alongside Ajenti and there's going to be a reasonable chance of dependency conflicts. Not a nice characteristic for a control panel.
EDIT: Yes, I know virtualenv exists. It's trash.
But there can be a "duct tape" workaround though
Out of topic: No that will never be, extreme amount of reasons which are very strong and realistic.
Unless everything is called js .
And it will be no good as well @ the same time.
Don't stress it, it was just a joke :-)
It was based on the fact people write tons of crazy things in JS because then they can show their crazy masterpieces by just sharing a URL.
You might find this interesting.
Sure, but starting from scratch is no easy work and it's hard to maintain it with 1-2 people. Isn't it the problem with most of these software? They mostly depend on 1 person and when that person decides to quit or have trouble with real life problems the project goes dead/unmaintaned. That was my point. I didn't check their codes.
Having a bus factor of 1 is still a better option than investing copious amounts of time into something that is going to permanently remain a complete mess (and possibly a significant liability). Especially if designed well, it should not be hard for a third party to pick up the project, in the worst case.
Need one written in a clean logical manner so if the developer gets hit by a bus someone can pick it right up
I remember @joepie91 as a python critic and PHP addict.
Fortunately, he got the help he needed.
I've seen JoePie criticize PHP, Javascript, Python and anything considered low-level enough to cause seg faults. I'd suggest the most performant answer is a single bit (switched on) to signify existence. It'll turn off when the universe ends.
Seen a thread on another forum lately asking why there's no Perl love. For me, 'the win' would be C/C++, using all the libs our favourite software runs on today... and Personal Home Pages for the front end. It wouldn't be 2010's without a bunch of unneeded Jquery plugins also.
I criticize most things, because most things suck - just to varying degrees
I would not hesitate to recommend Node.js to most people, but I'm not ignorant of its faults either, and will happily argue about them to resolution.
I once was a big fan of nodejs. I was so excited. But now as we switched our projects to Golang, we will probably not switch back.
If you will make something like cPanel, yea go ahead why not.
My core reason for avoiding Golang is it's terrible error handling. For some unfathomable reason, they've reintroduced the "always check your errors!" model that has caused an endless amount of bugs in C code.
It's not fixable on a language level either, from what I've gathered - Node.js had this same issue with nodebacks, but this has been fixed through Promises. As far as I understand it, no such construct is possible in Golang, which means you have an unfixably broken error handling system, for eternity, with the core developers believing it's no big deal.
That's just not a good base to build things on.
I hate both Golang's error handling and Node's callback hell. But in my mind, the real problem of Nodejs is its single thread programming model. It's unfair that they advertise that their single thread callback makes it faster, the truth is they have no other choice. The unblocking callback can be easily done in other programming languages. But I have to admit that Javascript is a lot more pleasant to write if your app is not super complicated.
You very rarely need more than one CPU core for most processes anyway. There are multithreading, clustering etc libs for node. A lot of native modules maintain their own threads for heavy sync code and then simply call the callback from that thread.
With ES6 Promises + generators + ES7 spawn you can just put yield in front of your async method and it will continue running when it calls back.
Looks like a lot to learn again.
I mean the ES6 and ES7.
Yeah, it's relatively new but it's a lot different way to look at things!
Just googled for a library wrapping the theory up, and this one from mozilla seems nice: http://taskjs.org/ (with a good example code snippet)
Edit: easy to understand theory, with snippets allowing its use today https://jakearchibald.com/2014/es7-async-functions/
I can't stand callback hell either. This is why I strongly encourage people to use Promises by default
It's not really a problem, it just makes it unsuitable for certain kinds of applications - but much, much simpler in the remainder of the cases.
That's not strictly true - both the advertising and your conclusion. In theory it's slower (because all computation happens on one thread), but in practice it's faster for most applications, because all I/O happens asynchronously at no extra time or effort cost to the developer.
They do have a choice - there are various implementations of threads for Node.js, but not much effort goes into those because they're just not worth it. Why would you spend hours implementing threads when 99% of the usecases doesn't need them, and the other 1% is better accommodated by other languages or runtimes anyway?
Sure, and it is done in many other languages. The big difference is that in JS, it occurs on a platform level - this means that you don't get the dependency hell like in Python, where one library only works with async framework A, and the other library only works with async framework B, and you have three different concurrency primitives to abstract around.
The Node.js ecosystem has such good interoperability because this kind of stuff is defined on a platform level, and every single thing adheres to it (and must adhere to it!). That is why you can blindly combine different modules without having to first figure out whether they speak the same event loop implementation. That, in turn, means 100% async I/O coverage across the ecosystem, which removes the need for threads.
Clustering, yes. Threading, not really. All the thread implementations are 'bare' v8 threads, without even access to
requireor anything else that makes them actually usable in a Node.js environment. Nobody has really bothered implementing it fully (except for JXCore, maybe?) because it's just not worth the effort, as described above.False. Most native modules, e.g. Bcrypt use real threads.
Also it's not defined on a platform level, the other way around. Usually impl before spec.
JS works with any code no such thing as type mismatch, so any lib can call or implement e.g. .then() unlike other languages
Why not contribute to the existing panels?
Those are just C++ threads, and are not exposed to the JS part of the code. I'm refering to implementations like threads-a-gogo. Of course you can have 'real' threads in C++, but it doesn't really have anything to do with Node at that point.
It is. There is one global event loop implementation with one set of primitives that everything uses.