DirectAdmin v1.640 has been released

fln said:
@quags we could introduce a special variable in directadmin.conf to enable such mode. However I think it only hides the real issue instead of fixing. Could you give me more details why would you like to keep only one instance of dataskq running?

Even if single dataskq instance takes quite some time to execute it truncates the task log so that subsequent concurrent dataskq calls will have nothing more to do. Strictly serializing all dataskq calls is trivial to implement but could have a very nasty consequences. For example if you start a backup for a huge account it could take hours to finish, with concurrent dataskq disabled all other actions would be stuck until the large backup or restore job gets finished.

If you are worried about multiple backup jobs running concurrently you can limit them to with the max_concurrent_backups config parameter in the directadmin.conf file, link to feature description.
Click to expand...
I don't always force one run, but on my systems I have a set up where if the load goes above a certain amount I begin limiting to 1. Normally, it is running standard with as many processes as it wants - but in the past there have been enough times where high load, or high io plus dataskq running every minute is not optimal.
 
Key change with this release is moving dataskq execution away from cron into the main directadmin web server
Click to expand...

Does this mean we should remove this line from /etc/cron.d/directadmin_cron?

Code: 
* * * * * root /usr/local/directadmin/dataskq
 
Thanks for clarification @quags. If we have the situation where server just can not keep up with the load, just reducing the dataskq execution interval should be sufficient, for example da config-set dataskq_run_interval 5m --restart.

We will keep this in mind, and try to come up automatic dataskq execution throttling if we see that the system just can't keep up. This is also the reason why we moved dataskq execution inside the main DA web server. To be able to have a more fine grained control. The plan is to actually separate long-running tasks from short running tasks. Long running tasks would be allowed to run concurrently, while short running tasks could be executed sequentially since concurrent execution will only make things worse on a busy server.
 
fln said:
This line should be automatically removed after the upgrade. DA takes care to remove it as part of the upgrade.
Click to expand...
Thank you. It appears I am still on DirectAdmin 1.63.5 ? (I upgraded on Saturday) so that explains why it was not yet removed.
Do I have to run a special command to update it to 1.640?
 
Whats going on with you guys?

Why do you think that some would invest time and money to create good sounding translations just to share them with competitors without getting any compensation. Maybe some wanted to gain a small edge against local competitors by having professional sounding ui instead of a cheap bunch of bot translated and badly maintained scraps of words? Furthermore when you care so much about sharing with the community, why do you force your customers do that by removing the ability to use custom language (de is not available right now) at all? Would it not be much more reasonable to provide translations for your customers when you want to release us from the burden to create these translations all by ourselfs?

Very dissapointing...
 
reonhoub2 said:
Whats going on with you guys?

Why do you think that some would invest time and money to create good sounding translations just to share them with competitors without getting any compensation. Maybe some wanted to gain a small edge against local competitors by having professional sounding ui instead of a cheap bunch of bot translated and badly maintained scraps of words? Furthermore when you care so much about sharing with the community, why do you force your customers do that by removing the ability to use custom language (de is not available right now) at all? Would it not be much more reasonable to provide translations for your customers when you want to release us from the burden to create these translations all by ourselfs?

Very dissapointing...
Click to expand...
thank you already that someone is my opinion, you are right on the point! we have invested several man-weeks of work for our 3 translations, which we can now no longer use, and are not willing to leave this to the cheap competitors, which then uses our work, which we fianced.

if the whole thing was open source, we would have no problem with it. but DA is paid SW, and now wants the paying customers to make their own product more attractive in exchange for nothing, the customers deliver the highest quality translations.

one of our unique selling points is that we are 4-language and deliver high quality services, availability and comprehensibility. so we see no reason to simply give this away so that afterwards everyone also owns one of our greatest advantages. we've done many translations in 3 languages (some in 4), also for the evil panel, rv global and site.pro and always got something for it back. so we stick on 1.639
 
Last edited:
apogee said:
one of our unique selling points is that we are 4-language
Click to expand...
I agreed somehow.

TIP for DA :

Could this be a good problem solver here:?
For the good translations you get from Persons or Company's there should be some Copyright / Advertising that must stay there in those translations so DA Users/ admin could see who did the work!
Or a little fee as Softaculous kind of thing when using one. ( spend button? )
 
@reonhoub2, @apogee. I do understand your points. Let me give you more details regarding this situation.

Right now we are working heavily on refactoring Evolution skin. Improving and updating it usually causes a series of trivial changes to the translation files. Because we use gettext (PO format) for translation engine even simple text indentation change in English version can cause translation entry to be no longer matched with the original string. Apart from trivial changes, a style or phrasing improvement in English always causes translations for other languages to break (because translation IDs are English translated string).

Usually for a person speaking this language and using the tools for managing translations it is very easy to fix. By maintaining personal translation files you are actually forced to follow, track and fix all the changes manually. Our end goal is to reduce the amount of poor quality translations and consolidate the translation efforts.

Personal translation files is also a double edge sword, by using your own translations you can create better user experience but also you can create worse user experience just the same. Ideally we would like to have a community based translations for the most common languages but still allow server administrators to customize it if they believe they can improve it.

Our goal is NOT to prevent you from using your custom translations or force you to share it. This change of not allowing to add new translation to Evolution but allowing you to override an existing one is a side effect of the Evolution structural changes. Could you give me the list of translation short codes that you would like to be available for translation replacement in next DA release? We have seen requests for de (German), de_CH (German Switzerland), it (Italian) so far.
 
fln said:
Thanks for clarification @quags. If we have the situation where server just can not keep up with the load, just reducing the dataskq execution interval should be sufficient, for example da config-set dataskq_run_interval 5m --restart.

We will keep this in mind, and try to come up automatic dataskq execution throttling if we see that the system just can't keep up. This is also the reason why we moved dataskq execution inside the main DA web server. To be able to have a more fine grained control. The plan is to actually separate long-running tasks from short running tasks. Long running tasks would be allowed to run concurrently, while short running tasks could be executed sequentially since concurrent execution will only make things worse on a busy server.
Click to expand...
A simple setting that prevents long running tasks when load is higher than a set value, could do the trick for most people I think
 
fln said:
@reonhoub2, @apogee. I do understand your points. Let me give you more details regarding this situation.

Ideally we would like to have a community based translations for the most common languages but still allow server administrators to customize it if they believe they can improve it.
Click to expand...

Yes, then do this please, but don't ditch the ability to use translations which are not >80% community translated.

I recommend that you incentivise the community effort a bit. E.g offering some free licensing for maintainers of translation files as long as the community agrees with the quality of that translations. Other companys do that as well. On hetzner forums one can earn 50€ bucks for posting a helpful tutorial. If a maintainer stops supporting the translation files or quality is bad you stop the free licensing. Of course that will generate you a bit of administrative expenses but after all I assume its still a pretty cheap way for you to add valuable features to your product.

We have seen requests for de (German), de_CH (German Switzerland), it (Italian) so far.
Click to expand...

Yes, de (German) for me please..
 
We have done all translations with po-edit, if something changes this is displayed and within seconds it is adjusted. What bothers me is that the backend dictionary in PO format has been broken for 7 months or longer, we have told DA several times but it has never been fixed.

We play updates first on our dev system, test everything, fix languages and after a few days it goes on the first few productive boxes, after few days without problems the rest get the updates. Just put updates without any control on productive systems is unprofessional from my point of view. Nevertheless, it comes to funny bugs which occur only under certain constellations (eg the one with xapian).

I think the idea of goodies is a good one, your competitor also does this, but personally, I'm not interested in giving up a unique selling proposition for few bucks.
 
apogee said:
What bothers me is that the backend dictionary in PO format has been broken for 7 months or longer, we have told DA several times but it has never been fixed.
Click to expand...
Thanks for reporting @apogee, backend translations were not updated for quite some time. This should change with the next release :). Latest backend translations are already updated in the translate.directadmin.com system. And all translations will be pulled in nightly alpha releases.
 
fln said:
Thanks for reporting @apogee, backend translations were not updated for quite some time. This should change with the next release :). Latest backend translations are already updated in the translate.directadmin.com system. And all translations will be pulled in nightly alpha releases.
Click to expand...
Yes, also the dictionary not! DA has ignored all tickets about that... so, as i told you (DA) a few times, i find it illogical that there is a frontend translation and a backend translation, just do it like the evil panel.... see tickets...
 
Last edited:
To share your translation or not with the community is something personal.
I am one of the maintainers and have totally no problem with sharing it with others, despite there are some potential competitors.

However, I do agree that there can be some extra's for the translators /maintainers for their effort and keep them happy. :)
 
Active8 said:
To share your translation or not with the community is something personal.
Click to expand...
yep

Active8 said:
I am one of the maintainers and have totally no problem with sharing it with others, despite there are some potential competitors.

However, I do agree that there can be some extra's for the translators /maintainers for their effort and keep them happy. :)
Click to expand...
a few celtic languages are quite rare, customers who like them love our company (if 1% of it is our customer we are big (in our dimension)), so absolute unique selling proposition, yes i know no one else is interested but we also have competitors.
 
You must log in or register to reply here.
Back
Top