Roman Savochenko via tde-users wrote:
Thanks for the tip. :)
Yes, that will work also without using udisks, but I have struck to the problem through udisks, so resolved it through udisks, and read also many such manuals before.
But TDE is supporting udisks and udisks2. This issue must be solvable somewhere else.
Any way, that is strange of using direct mounting at udisks presence, who is correctly processed /etc/fstab for proper user with a record in /etc/fstab: /dev/fd0 /media/floppy auto noauto,users,owner,iocharset=utf8,codepage=866 0 0
This is the Debians recommendation - it doesn't know anything about TDE.
Ponedilok 18 Lystopad 7532 23:34:16 deloptes via tde-users написав:
Roman Savochenko via tde-users wrote:
Thanks for the tip. :)
Yes, that will work also without using udisks, but I have struck to the problem through udisks, so resolved it through udisks, and read also many such manuals before.
But TDE is supporting udisks and udisks2. This issue must be solvable somewhere else.
I know about TDE support udisks even from the source code, but udisks or TDE in arguments is broken about FD support. Due to the both default and custom mounting options are not acceptable and it mounts FD only from root:root and 755, when there is no record about FD in /etc/fstab.
Any way, that is strange of using direct mounting at udisks presence, who is correctly processed /etc/fstab for proper user with a record in /etc/fstab: /dev/fd0 /media/floppy auto noauto,users,owner,iocharset=utf8,codepage=866 0 0
This is the Debians recommendation - it doesn't know anything about TDE.
I know that.
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also not use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So it looks to me TDE has the correct precedence and this must be right.
In any case as you now use TDE with this part of the code removed, we can not just try removing the fstab entry and see if this would work. But honestly I also doubt you would try it anyway.
BR
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also not use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly, there is a problem with missing options to control user of the mounted disk folder. And that missing is not the problem also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't allow neither user, owner, uid or mask options.
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So it looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution for FD without fixing udisks itself. And most solutions in Internet about treating that behaviour of udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting use mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
Regards, Roman
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via tde-users < users@trinitydesktop.org>:
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also
not
use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly, there is a problem with missing options to control user of the mounted disk folder. And that missing is not the problem also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't allow neither user, owner, uid or mask options.
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So
it
looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution for FD without fixing udisks itself. And most solutions in Internet about treating that behaviour of udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting use mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over fstab" will cover this use case?
Regards, Roman ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
On 2024/11/20 04:26 PM, Andrew Randrianasulu via tde-users wrote:
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!In this case, I hope just one additional checkbox "prefer udisk(2) over fstab" will cover this use case?
Sorry, I don't get it.
/etc/fstab is there to allow a sys admin to setup information on how to mount disks. For example you could mount specific partitions to specific folders and allow access to specific users *ONLY*. If any non-root user could simply click a checkbox and bypass the rules in fstab and mount disks at its own pleasure, where would security go?
On a server or share computer, the above can't not be allowed and using fstab info is the correct way, when present. systemd does that and you can mount a disk with udisks and dbus without even having any DE installed, as long as fstab and policies allow you to do that.
On a personal computer with a single user, you can login as root, edit fstab and set up mounting as you prefer or remove the entry from there all together.
Maybe I am missing something, if so please point it out for my own knowledge :-)
Cheers Michele
On Sereda 20 Lystopad 7532 09:26:14 Andrew Randrianasulu wrote:
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via tde-users <
users@trinitydesktop.org>:
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also
not
use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly, there is a problem with missing options to control user of the mounted disk folder. And that missing is not the problem also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't allow neither user, owner, uid or mask options.
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So
it
looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution for FD without fixing udisks itself. And most solutions in Internet about treating that behaviour of udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting use mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over fstab" will cover this use case?
Regards, Roman ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydes ktop.org
I think for that just can be used the present CheckBox "Use default mount option", which means as force using udisks at TRUE, with this default parameters in /etc/fstab at presence, and use custom parameters from that dialogue at FALSE. Also with overriding by direct mount at an entry presence, with hidding the dialogue parameters as nonsenses and/or writing here about taking from /etc/fstab by mount.
Anno domini 2024 Wed, 20 Nov 12:40:33 +0200 Roman Savochenko via tde-users scripsit:
On Sereda 20 Lystopad 7532 09:26:14 Andrew Randrianasulu wrote:
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via tde-users <
users@trinitydesktop.org>:
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also
not
use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly, there is a problem with missing options to control user of the mounted disk folder. And that missing is not the problem also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't allow neither user, owner, uid or mask options.
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So
it
looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution for FD without fixing udisks itself. And most solutions in Internet about treating that behaviour of udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting use mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over fstab" will cover this use case?
Regards, Roman ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydes ktop.org
I think for that just can be used the present CheckBox "Use default mount option", which means as force using udisks at TRUE, with this default parameters in /etc/fstab at presence, and use custom parameters from that dialogue at FALSE. Also with overriding by direct mount at an entry presence, with hidding the dialogue parameters as nonsenses and/or writing here about taking from /etc/fstab by mount.
Investing manpower into a problem that may for some users exist on ancient hardware is not a sane way to do when manpower is limited. If said users think it's worth their time then they should just make the changes and submit a patch. That said, I just found a single 3.5" floppy disk in the stack of archived software - needless to say that the last floppy drive left over 20 jears ago. So if anybody needs it for the ancient floppy drives just drop me note.
Nik
On Sereda 20 Lystopad 7532 13:42:20 Dr. Nikolaus Klepp via tde-users wrote:
Anno domini 2024 Wed, 20 Nov 12:40:33 +0200
Roman Savochenko via tde-users scripsit:
On Sereda 20 Lystopad 7532 09:26:14 Andrew Randrianasulu wrote:
ср, 20 нояб. 2024 г., 09:21 Roman Savochenko via tde-users <
users@trinitydesktop.org>:
On Sereda 20 Lystopad 7532 01:43:47 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
I know that.
Well, I don't know. I would just use the default options. I would also
not
use /media, because media is used by the system to automatically mount devices (I guess it is true for udisks2).
There is no problem with options here, since they are accepted correctly, there is a problem with missing options to control user of the mounted disk folder. And that missing is not the problem also of tdestoragedevice.cpp in processing the mounting options, due to udisks doesn't allow neither user, owner, uid or mask options.
My understanding of your problem is that you create an entry in fstab and use udisks in the same time. The entry in fstab causes TDE to read this entry and omit udisks. Udisks does not need an entry in fstab anyway. So
it
looks to me TDE has the correct precedence and this must be right.
udisks can use /etc/fstab options to customize own behaviour and that is a single solution for FD without fixing udisks itself. And most solutions in Internet about treating that behaviour of udisks mean same appending an entry for FD to /etc/fstab, and TDE here tricks you starting use mount directly!
udisks2 also can use /etc/fstab, and mediamanager.cpp wrongly overrides this feature!!!
In this case, I hope just one additional checkbox "prefer udisk(2) over fstab" will cover this use case?
I think for that just can be used the present CheckBox "Use default mount option", which means as force using udisks at TRUE, with this default parameters in /etc/fstab at presence, and use custom parameters from that dialogue at FALSE. Also with overriding by direct mount at an entry presence, with hidding the dialogue parameters as nonsenses and/or writing here about taking from /etc/fstab by mount.
Investing manpower into a problem that may for some users exist on ancient hardware is not a sane way to do when manpower is limited. If said users think it's worth their time then they should just make the changes and submit a patch. That said, I just found a single 3.5" floppy disk in the stack of archived software - needless to say that the last floppy drive left over 20 jears ago. So if anybody needs it for the ancient floppy drives just drop me note.
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
The second, that is about positioning TDE as "with a primary goal of retaining the function and form of traditional desktop computers.", which means of the software working on "traditional" HW where this software appeared, but of course the "two standards way" brought KDE3 to breaking such possibility by cmake, tqtinterface and including new code with anchoring it to new interfaces without saving the old compatibility, so for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9 is 14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
And the third, the FDC controllers were still appeared on MB 2010 year old! :)
Roman Savochenko via tde-users wrote:
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct. May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
The second, that is about positioning TDE as "with a primary goal of retaining the function and form of traditional desktop computers.", which means of the software working on "traditional" HW where this software appeared, but of course the "two standards way" brought KDE3 to breaking such possibility by cmake, tqtinterface and including new code with anchoring it to new interfaces without saving the old compatibility, so for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9 is 14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The compatibility to the Debian system is driven by Debian. TDE supports the Debian version as long as Debian supports this version. As for the rest Kaffeine for example caused problems from the start to present. I am not aware that some "local authority" did something on purpose to break something, but honestly this is the reason I never liked or used it and I stick to kplayer.
As far as I understood tqtinterface was merged into the main code ... what old compatibility do you mean? You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
ср, 20 нояб. 2024 г., 16:35 deloptes via tde-users <users@trinitydesktop.org
:
Roman Savochenko via tde-users wrote:
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct. May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
I guess "formalizing" this as feature request will be more productive than growing this thread :)
Sorry, I installed NetBSD on new hard drive and I do not have access to my Linux hdd currently (there were only two sata power cables .. one goes into bluray writer/reader, other into hdd)
The second, that is about positioning TDE as "with a primary goal of retaining the function and form of traditional desktop computers.", which means of the software working on "traditional" HW where this software appeared, but of course the "two standards way" brought KDE3 to breaking such possibility by cmake, tqtinterface and including new code with anchoring it to new interfaces without saving the old compatibility, so for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9
is
14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The compatibility to the Debian system is driven by Debian. TDE supports the Debian version as long as Debian supports this version.
And Debian versions come and go with its own set of restrictions .....
As for the rest Kaffeine for
example caused problems from the start to present. I am not aware that some "local authority" did something on purpose to break something, but honestly this is the reason I never liked or used it and I stick to kplayer.
As far as I understood tqtinterface was merged into the main code ... what old compatibility do you mean? You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
Well, I think this is about infamous user/developer divide that failed to fail even with libre software. Software may be libre, but understanding it and rebuilding it locally often not really simple. Pushing changes upstream also not always work. You end up either doing A LOT of work, or swim with your distro's choices. I prefer Slackware exactly because it doesn't try to limit me from shooting myself into head with packaging/installing on my local machine. But even Slackware has limits of flexibility .....
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
On Sereda 20 Lystopad 7532 15:51:18 Andrew Randrianasulu via tde-users wrote:
ср, 20 нояб. 2024 г., 16:35 deloptes via tde-users <users@trinitydesktop.org
Roman Savochenko via tde-users wrote:
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct. May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
I guess "formalizing" this as feature request will be more productive than growing this thread :)
Just improving my patch will be maximum productive, that proved. :)
14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The compatibility to the Debian system is driven by Debian. TDE supports the Debian version as long as Debian supports this version.
And Debian versions come and go with its own set of restrictions .....
Yes, and the restrictions exactly presented and will be floated away just you try to build.
Well, I think this is about infamous user/developer divide that failed to fail even with libre software. Software may be libre, but understanding it and rebuilding it locally often not really simple.
And that is about trusting at least to whom, who participated in that project from its begin and knows-tests more in aspects of the program deep using by him.
Pushing changes upstream also not always work.
But when you can re-push with own changes-fixes that is work for you always. :)
You end up either doing A LOT of work, or swim with your distro's choices. I prefer Slackware exactly because it doesn't try to limit me from shooting myself into head with packaging/installing on my local machine. But even Slackware has limits of flexibility .....
:)
On 2024/11/20 10:35 PM, deloptes via tde-users wrote:
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
Is that even possible? systemd reads fstab entry on boots and when manually instructed to do so and use fstab information when a disk needs to be mounted, regardless of whether you use mount, udisks, udisks2 or other mounting methods. As I also mentioned in my previous email, if a standard users could bypass fstab permissions so easily, it would be a security issue.
Again, if I said something wrong or I am missing some info, happy to hear about it. Cheers Michele
ср, 20 нояб. 2024 г., 17:46 Michele Calgaro via tde-users < users@trinitydesktop.org>:
On 2024/11/20 10:35 PM, deloptes via tde-users wrote:
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
Is that even possible? systemd reads fstab entry on boots and when manually instructed to do so and use fstab information when a disk needs to be mounted, regardless of whether you use mount, udisks, udisks2 or other mounting methods. As I also mentioned in my previous email, if a standard users could bypass fstab permissions so easily, it would be a security issue.
KDE3 and TDE does have "administrator mode" in Kcontrol, so user expected to configure system this way too .....
Again, if I said something wrong or I am missing some info, happy to hear about it. Cheers Michele ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
Michele Calgaro via tde-users wrote:
Is that even possible? systemd reads fstab entry on boots and when manually instructed to do so and use fstab information when a disk needs to be mounted, regardless of whether you use mount, udisks, udisks2 or other mounting methods. As I also mentioned in my previous email, if a standard users could bypass fstab permissions so easily, it would be a security issue.
Again, if I said something wrong or I am missing some info, happy to hear about it.
May be I was mistaken, but when reading udisks docs, I saw an option for the mount command. Now looking again, I think it was the mount options for udisks in the configuration file. https://storaged.org/doc/udisks2-api/latest/mount_options.html
I do not have much time ATM to look into it in details though.
As far as I understand the problem Roman addressed, it is that TDE bypasses udisks if there is fstab entry for the device, while the correct behavior would be to see if udisks is allowed to handle the device, because udisks itself honours fstab. But this is just my understanding and hypothesis for now. In the docs of udisks it says it uses fstab and its config file. Both are managed by root only, so it is for the root user to decide what the user can do.
On 2024/11/23 01:10 AM, deloptes via tde-users wrote:
As far as I understand the problem Roman addressed, it is that TDE bypasses udisks if there is fstab entry for the device, while the correct behavior would be to see if udisks is allowed to handle the device, because udisks itself honours fstab. But this is just my understanding and hypothesis for now. In the docs of udisks it says it uses fstab and its config file. Both are managed by root only, so it is for the root user to decide what the user can do.
Hi Emanoil, thanks for the info and for expressing the problem in understandable terms :+1: I read further into the link you posted and the udisks docs and this cleared a few things out. Basically udisks will obey /etc/fstab for those devices which are listed there, as indicated here:
" Also note that block devices having corresponding records in /etc/fstab are excluded from the overrides as the mount options are fully taken from such records just like before."
So whether we follow fstab or let udisks handle the device, in the end the results should be the same, unless I miss something.
Cheers Michele
Michele Calgaro via tde-users wrote:
So whether we follow fstab or let udisks handle the device, in the end the results should be the same, unless I miss something.
So we are again at square 1 :) I did not have to read all of the documentation - very busy week. I read at one place that it merges the fstab and the udsisks config and handles the mounting. But if this is so as you describe it, then there is something missing in the whole picture.
I go back one step to the first post by Roman
Access is controlled by udisks or from /etc/fstab! :)
And udisks directly mounts floppy only in RO.
Here obviously he did not take time to do proper udisks config for floppy devices, which would obviously overwrite the default fstab ... or if it is correct that the issue was in Debian7 it could be that this was older version of udisks or something back then
And when you write a record about floppy in /etc/fstab, TDE uses direct mounting by call mount for it, and that is wrong work also for userspace.
It seems to me he is unhappy that floppy was mounting RO (I assume the issue is here, because default entry in fstab created by debian or so or default mount options for floppy somewhere in the linux distro). So he disables the code in TDE, so that udisks can pick up and mount the floppy RW.
Then I just disabled the direct mounting at a record in /etc/fstab, so TDE is using udisks for that and udisks reads /etc/fstab and mounts RW in userspace correctly in this way.
I can just conclude that the problem was/is in the fstab mount options for floppy for whatever reason. Thus TDE code is just fine and the claims made by Roman incl. the hack-patch is invalid.
If my understanding is wrong, we have to organize a debugging session with vanilla TDE to reproduce the problem. Meanwhile Roman can build or install vanilla TDE without his patch and check if the issue is still there. Roman, you can also provide some log information if you play the cooperative game.
BR
On Nedila 24 Lystopad 7532 00:59:30 deloptes via tde-users wrote:
If my understanding is wrong, we have to organize a debugging session with vanilla TDE to reproduce the problem. Meanwhile Roman can build or install vanilla TDE without his patch and check if the issue is still there. Roman, you can also provide some log information if you play the cooperative game.
I have say already: That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
So, I have done this for myself and closed the question!!!
On Sereda 20 Lystopad 7532 15:35:11 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
And do that more unobvious?
The second, that is about positioning TDE as "with a primary goal of retaining the function and form of traditional desktop computers.", which means of the software working on "traditional" HW where this software appeared, but of course the "two standards way" brought KDE3 to breaking such possibility by cmake, tqtinterface and including new code with anchoring it to new interfaces without saving the old compatibility, so for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9 is 14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The compatibility to the Debian system is driven by Debian. TDE supports the Debian version as long as Debian supports this version.
There is no problem in building for archived Debian for such support, and I do that for my project, so proving the developing to environments of starting the program and some early. :)
As for the rest Kaffeine for example caused problems from the start to present.
Not for me. :)
I am not aware that some "local authority" did something on purpose to break something, but honestly this is the reason I never liked or used it and I stick to kplayer.
When the "local authority" acknowledges all merging request through own knowledge, it take on self all responsibility from developers for applied or rejected code, so freezing the changes, which could be reworkered whether the Author or someone else after testing in the end environment. Relating to Kaffeine and other, the "local authority" waits that I very want to place my code to their repository, so I must listen their instruction and obey without a word even know their are wrong. :)
As far as I understood tqtinterface was merged into the main code ... what old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and cmake, and how many there are leaved hidden issues after potential building sensitive code with other optimisation options and without some specific in Autotool?
So, you can see that here — http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_A...
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)
ср, 20 нояб. 2024 г., 20:48 Roman Savochenko via tde-users < users@trinitydesktop.org>:
On Sereda 20 Lystopad 7532 15:35:11 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
That is not about "manpower", the first, but about limiting udisks features and without proper informing in dialogues about used mounting parameters and mechanisms. And to add that, I need up to one hour, but prove that is a problem, it seems there will be one day and more.
If you have entry in fstab, you limit udisks - also TDE chooses fstab
entry
first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
And do that more unobvious?
The second, that is about positioning TDE as "with a primary goal of retaining the function and form of traditional desktop computers.",
which
means of the software working on "traditional" HW where this software appeared, but of course the "two standards way" brought KDE3 to
breaking
such possibility by cmake, tqtinterface and including new code with anchoring it to new interfaces without saving the old compatibility, so for Debian 7 the last is 14.0.10, for Debian 8 is 14.0.13, for Debian 9 is 14.1.0. That is, for new versions we must start to throw out the old HW also as for MancurtoScoft (MS)! The authoritarian development conception-process causes to I am patching this only for myself (and my users), also as CD-RW icons, playing DVD in Kaffeine and so on, after breaking those by the "local authority".
I am not aware of any TDE dependency on specific hardware. The compatibility to the Debian system is driven by Debian. TDE supports the Debian version as long as Debian supports this version.
There is no problem in building for archived Debian for such support, and I do that for my project, so proving the developing to environments of starting the program and some early. :)
As for the rest Kaffeine for example caused problems from the start to
present.
Not for me. :)
I am not aware that some "local authority" did something on purpose to
break
something, but honestly this is the reason I never liked or used it and I stick to kplayer.
When the "local authority" acknowledges all merging request through own knowledge, it take on self all responsibility from developers for applied or rejected code, so freezing the changes, which could be reworkered whether the Author or someone else after testing in the end environment. Relating to Kaffeine and other, the "local authority" waits that I very want to place my code to their repository, so I must listen their instruction and obey without a word even know their are wrong. :)
As far as I understood tqtinterface was merged into the main code ...
what
old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and cmake, and how many there are leaved hidden issues after potential building sensitive code with other optimisation options and without some specific in Autotool?
So, you can see that here —
http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_A...
impressive list! :)
thank you for all those years of work ....
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :) ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
Roman Savochenko via tde-users wrote:
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
And do that more unobvious?
Raise a ticket in TGW, so that we do not forget it and much better provide a patch that addresses the issue (not commenting out in the code)
There is no problem in building for archived Debian for such support, and I do that for my project, so proving the developing to environments of starting the program and some early. :)
Of course there is no problem ... it just makes no sense.
As for the rest Kaffeine for example caused problems from the start to present.
Not for me. :)
Obviously
I am not aware that some "local authority" did something on purpose to break something, but honestly this is the reason I never liked or used it and I stick to kplayer.
When the "local authority" acknowledges all merging request through own knowledge, it take on self all responsibility from developers for applied or rejected code, so freezing the changes, which could be reworkered whether the Author or someone else after testing in the end environment. Relating to Kaffeine and other, the "local authority" waits that I very want to place my code to their repository, so I must listen their instruction and obey without a word even know their are wrong. :)
This is normal ... when you are not the "local authority". I actually like it. It is usually called team work.
As far as I understood tqtinterface was merged into the main code ... what old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and cmake, and how many there are leaved hidden issues after potential building sensitive code with other optimisation options and without some specific in Autotool?
No idea, but this is the result, when you kind of fork and continue on your own. IMO it would be better for all parties that you try doing only temporary changes and try get them into the main repo, because other wise the work increases over time. At the end it is your own choice what you do. You are the "local authority for your work". If you wish you can write to me in private what issues you have, or post them here one by one, so that we could discuss. It would be great if you could contribute, but this includes obeying the local authority. I am pretty happy with the cooperation with this local authority. Few things/bugs that were bothering me and I fixed were accepted without big problems and I learned a lot. I also ported one or two applications and it also worked quite well. It is just a normal work flow that you have in every company or open source project. I really do not understand your frustration, but it is sad to hear disappointment. You probably never dealt with Gnome/KDE or other projects and their "local authorities"
So, you can see that here —
http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_A...
not bad, not bad ... I wish I had the time to go through them and move them (if possible) into the main repo, but unfortunately, I do have very limitted time. Whenever I find time I will try to pick up one or two and try to create a patch. Let's see if it works. I do not promise anything.
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)
This is waste of time, disk space (and electricity) I do not have such systems - in fact it is actually not recommended (it would be forbidden) to use them for security reasons.
the "local authority" waits that I very want to place my code to their repository, so I must listen their instruction and obey without a word even know their are wrong. :)
This is normal ... when you are not the "local authority". I actually like it. It is usually called team work.
+1000! very well said Emanoil :clap: :clap: The first rule of contributing to any project (open source or not) is to understand how the project operates, how it is managed and what the rules are. Second rule is to adhere to those rules and cooperate with good etiquette with the project team and community.
Do you know how many bugs I have fixed... http://oscada.org/wiki/Special:MyLanguage/User:RomanSavochenko/Open_Source_A...
Preparing a "fix" means: 1. investigating the issue and understanding the root cause of the problem 2. modifying the code to fix such root issue
Preparing a "hack" means: 1. not understanding the root cause of a problem 2. modifying the code to hide the problem
In TDE we have no problems to accept "fixes", as many of our contributors have experienced. But we do have a problem with "hacks": we would rather have a program to keep crashing to show that there is a problem than hiding the problem away. Because once you start hiding things, the code will grow more and more like the "Leaning Tower of Pisa" and sooner or later it will become unstable and you don't even know why.
When the "local authority" acknowledges all merging request through own knowledge, it take on self all responsibility from developers for applied or rejected code
We (the dev team - or apparently the so called "local authority") try our best to keep the project in good health and running. We all do this in our spare time, out of passion and totally for free. Are we perfect? No. Do we make mistakes? Absolutely. We can't please all, we do our best effort. We try to listen to all people and when we have to make a choice, we try to do it in the interest of the project and its community. Because a project without a community is a dead project. We don't mind hearing constructive criticism, but gratuitous attacks when a patch is not accepted is not going to achieve anything.
Cheers Michele
On Pjatnyca 22 Lystopad 7532 18:01:32 deloptes via tde-users wrote:
Roman Savochenko via tde-users wrote:
If you have entry in fstab, you limit udisks - also TDE chooses fstab entry first. This is correct.
And in fstab you can point any udisks option, where are limits here? :)
May be TDE could be updated so that when you have udisks in the mount options, that it would prefer using udisks over fstab.
And do that more unobvious?
Raise a ticket in TGW, so that we do not forget it and much better provide a patch that addresses the issue (not commenting out in the code)
I write nothing to TGW right now since there lie tens my previous patches!
There is no problem in building for archived Debian for such support, and I do that for my project, so proving the developing to environments of starting the program and some early. :)
Of course there is no problem ... it just makes no sense.
OK, how many sense in holding all previous binary and source packages? :)
I am not aware that some "local authority" did something on purpose to break something, but honestly this is the reason I never liked or used it and I stick to kplayer.
When the "local authority" acknowledges all merging request through own knowledge, it take on self all responsibility from developers for applied or rejected code, so freezing the changes, which could be reworkered whether the Author or someone else after testing in the end environment. Relating to Kaffeine and other, the "local authority" waits that I very want to place my code to their repository, so I must listen their instruction and obey without a word even know their are wrong. :)
This is normal ... when you are not the "local authority". I actually like it. It is usually called team work.
I know how teams work, and this one just authoritarian cast tree, when someones on the top think they "know roots" and other do not, and for decades they can't fix problems fixed by experienced users "without the root knowledges". That is they let for users "eat the cactus" or drop down this mess, how do many inexperienced users for that broken KDE3.
And for the "local authority", ALL difficult problems are fixed through hacks! :)
As far as I understood tqtinterface was merged into the main code ... what old compatibility do you mean?
Do you know how many bugs I have fixed during moving to tqtinterface and cmake, and how many there are leaved hidden issues after potential building sensitive code with other optimisation options and without some specific in Autotool?
No idea, but this is the result, when you kind of fork and continue on your own.
Not fork but stupid re-branding, with constant symbols renaming forward and back, with changing the well tested and debugged building system and loss support of old systems, so caused many hidden and even visible broken code instead the using stabilisation of the mature code. Also as changing habits of the code development and debugging especially for partial fast building, by implementation cmake, ninja and so on.
IMO it would be better for all parties that you try doing only temporary changes and try get them into the main repo, because other wise the work increases over time. At the end it is your own choice what you do. You are the "local authority for your work".
I NEVER overpress others, leaving for them the responsibility for their code, which they can improve after exploiting the applied code, especially when I don't know deep of the problem specific, that is when I don't use this function!
And I was forced to create the my partial fork after my critical for me patches became ignored, that I did not choose that!
If you wish you can write to me in private what issues you have, or post them here one by one, so that we could discuss.
I have no problem with my "hacks", also as I have no time and wishes to prove something for the "local authority"! :)
It would be great if you could contribute, but this includes obeying the local authority. I am pretty happy with the cooperation with this local authority. Few things/bugs that were bothering me and I fixed were accepted without big problems and I learned a lot. I also ported one or two applications and it also worked quite well. It is just a normal work flow that you have in every company or open source project.
That is not normal in my open source project!
I really do not understand your frustration, but it is sad to hear disappointment. You probably never dealt with Gnome/KDE or other projects and their "local authorities"
I dealt with the official builds of some Linux distributions, and saw there horde of the patches to KDE3, so I can imagine about that "tradition". :)
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)
This is waste of time, disk space (and electricity) I do not have such systems - in fact it is actually not recommended (it would be forbidden) to use them for security reasons.
If that waste of time, then you can forget this problem, due to it mostly for Debian 7 and the old build 14.0.10. When you want to save disk space, remove old builds, which are not needed anybody exactly.
And last versions for old distributions and HW I need, due to work with such hardware, where you cannot to install fresh distributions whether in reasons of kernels, or specific modules to them, also as through the productivity and do not generating HW garbage.
Roman Savochenko via tde-users wrote:
Raise a ticket in TGW, so that we do not forget it and much better provide a patch that addresses the issue (not commenting out in the code)
I write nothing to TGW right now since there lie tens my previous patches!
There are a lot of patches (PRs) in the queue there. No one complains, except you. It is your free choice. I personally see it as symbiosis. And at some point of time someone picks up the patch works it out and it either accepted or rejected.
There is no problem in building for archived Debian for such support, and I do that for my project, so proving the developing to environments of starting the program and some early. :)
Of course there is no problem ... it just makes no sense.
OK, how many sense in holding all previous binary and source packages? :)
Zero sense, because it is not a library/archive. It is working distro. Space costs and it makes not sense to keep olds stuff for distros that are out of support. Feel free to create a library/archive and pay for it. No one will object. I see now in EU storage costs for 5TB are 12,97/month ... so about 78€/y. If it is important for you, you can provide for it.
This is normal ... when you are not the "local authority". I actually like it. It is usually called team work.
I know how teams work, and this one just authoritarian cast tree, when someones on the top think they "know roots" and other do not, and for decades they can't fix problems fixed by experienced users "without the root knowledges". That is they let for users "eat the cactus" or drop down this mess, how do many inexperienced users for that broken KDE3.
AFAIK TDE is improving in the years and I know because I follow TGW, contribute and read the many changes (when time allows). There are some really good developers that joint in the past few years ... that contribute constantly ... and have very high quality contributions ... not like me :)
And for the "local authority", ALL difficult problems are fixed through hacks! :)
Well ... everybody has the right of it's own opinion, even if it is wrong.
No idea, but this is the result, when you kind of fork and continue on your own.
Not fork but stupid re-branding, with constant symbols renaming forward and back, with changing the well tested and debugged building system and loss support of old systems, so caused many hidden and even visible broken code instead the using stabilisation of the mature code. Also as changing habits of the code development and debugging especially for partial fast building, by implementation cmake, ninja and so on.
I guess you describe here evolution. Sometimes evolution also makes mistakes, but it tends to correct them over time. I personally had conversations (chats and mails) with the "local authority" and understood how they think and operate. I have very positive view of them ... they are indeed acting as authority, because they are indeed the authority over TDE, but they are cooperative and as far as you are also cooperative, it works just fine. I am writing you this, to encourage you and the rest to cooperate, because so it benefits the whole community.
IMO it would be better for all parties that you try doing only temporary changes and try get them into the main repo, because other wise the work increases over time. At the end it is your own choice what you do. You are the "local authority for your work".
I NEVER overpress others, leaving for them the responsibility for their code, which they can improve after exploiting the applied code, especially when I don't know deep of the problem specific, that is when I don't use this function!
And I was forced to create the my partial fork after my critical for me patches became ignored, that I did not choose that!
And I choose to cooperate and saw my patches go into TDE (one of the first patches is benefitting you too, because it solved UTF-8 in kalendar and kontact and may be other applications)
If you wish you can write to me in private what issues you have, or post them here one by one, so that we could discuss.
I have no problem with my "hacks", also as I have no time and wishes to prove something for the "local authority"! :)
I and I guess the rest have also no problems with your fork and patches. The problem is with the attitude published in the news group, where everybody can read it and in fact is factually not true. This is why I am writing to you. Remember - the whole world reads this!
It would be great if you could contribute, but this includes obeying the local authority. I am pretty happy with the cooperation with this local authority. Few things/bugs that were bothering me and I fixed were accepted without big problems and I learned a lot. I also ported one or two applications and it also worked quite well. It is just a normal work flow that you have in every company or open source project.
That is not normal in my open source project!
Well ... so you have a clone/fork of TDE which you commit to maintain yourself. Why bother TDE?
I really do not understand your frustration, but it is sad to hear disappointment. You probably never dealt with Gnome/KDE or other projects and their "local authorities"
I dealt with the official builds of some Linux distributions, and saw there horde of the patches to KDE3, so I can imagine about that "tradition". :)
KDE3 is not TDE ... the KDE3 team had it's own issues. I do not think you can compare both. I mean you can compare if you wish of course, but it is not right as these are two different things.
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)
This is waste of time, disk space (and electricity) I do not have such systems - in fact it is actually not recommended (it would be forbidden) to use them for security reasons.
If that waste of time, then you can forget this problem, due to it mostly for Debian 7 and the old build 14.0.10. When you want to save disk space, remove old builds, which are not needed anybody exactly.
And last versions for old distributions and HW I need, due to work with such hardware, where you cannot to install fresh distributions whether in reasons of kernels, or specific modules to them, also as through the productivity and do not generating HW garbage.
I have done some calculations and it does not pay off to keep old hardware. The productivity of CPUs is so low for the power consumption that it obsoletes itself immediately. I had two Acrosser (i386) devices from 2007 with 256MB (yes MB) memory and 300MHz CPU. I had to compile the kernel myself, because of a combination of available but not active drivers. It was a pain. After one of them got broken (I guess the electronics for the CF-IDE controller gave up) I bought a replacement (x86_64) with 4GB memory a decent CPU and the almost same power consumption. Now I do not have to compile the kernel anymore. It works like a charm. This is called evolution. At some point of time things have to be replaced.
If I were you I would keep a repository of those old distros (also a repository of the distro itself). I have local repositories, but I tend to update to latest whenever possible.
Again, I write this as invitation to cooperate. It benefits everybody.
BR
On Sunday 24 of November 2024 00:33:52 deloptes via tde-users wrote:
I write nothing to TGW right now since there lie tens my previous patches!
There are a lot of patches (PRs) in the queue there. No one complains, except you. It is your free choice. I personally see it as symbiosis. And at some point of time someone picks up the patch works it out and it either accepted or rejected.
There were situations where thorough research clearly showed that the proposed patch did not solve the cause of the problem, but one specific consequence - only hides the real cause of the problem. While the other potential consequences would remain unresolved and would probably wait for the next hack, which would again solve the individual consequences, not the cause. While the author fundamentally refused any cooperation in finding a real cause. As a result, real repairs of the causes of the problems were merged instead of the proposed hack.
Such an approach has caused that for all other patches from such an author now "local authority" must assume that this is again a hack. And because of the knowledge of the fundamental unwillingness to cooperate, "local authorities", of course, have little motivation to devote time and effort to these patches. So yes, such patches have been waiting for a long time. It is not surprising that "local authorities" prefer to pay attention to the authors who repeatedly give good contributions and cooperate very well. Such cooperation allows the project a good move forward. And we thank all such contributors! Thanks to good contributions and good cooperation, some have already become part of the Core team.
Cheers Slávek --
вс, 24 нояб. 2024 г., 05:54 Slávek Banko via tde-users < users@trinitydesktop.org>:
On Sunday 24 of November 2024 00:33:52 deloptes via tde-users wrote:
I write nothing to TGW right now since there lie tens my previous patches!
There are a lot of patches (PRs) in the queue there. No one complains, except you. It is your free choice. I personally see it as symbiosis. And at some point of time someone picks up the patch works it out and it either accepted or rejected.
There were situations where thorough research clearly showed that the proposed patch did not solve the cause of the problem, but one specific consequence - only hides the real cause of the problem. While the other potential consequences would remain unresolved and would probably wait for the next hack, which would again solve the individual consequences, not the cause. While the author fundamentally refused any cooperation in finding a real cause. As a result, real repairs of the causes of the problems were merged instead of the proposed hack.
To be honest I (as non-developer who somewhat forced to be) tend to see things more from "forever novice" perspective: TDE is big codebase, and assuming someone can jump right in and prepare professional quality solution you simply can merge ... is a bit unrealistic?
yes, people might be uncomfortable to extreme if you ask them to do professional analysis even without telling them *how* it done (assuming here they, like you, know it by heart).
I guess it hurts both ways .....
Also, while we all hope to be able to do new things, learn etc - sad truth is there definitely might be ceiling in how deep you understand something. If you have all the time in the world (like me, being invalid) you of course can try again and again and gain some better insight from different angle (like reading history of objective-c as used by NeXT machines long ago) but many people have much less time ...
I even tend to guess that all this labor division gone a bit too far lately - people assume someone else will do all teaching/training/mentoring etc . Too bad number of those 'someone else' does not grow magically ...
Moreover, I tend to think that exactly fact most developers chasing new, trendy and powerful is not a feature, all things considered. Too much initial (?) "move fast and break things" become unquestioned norm. So, yeah, totally aligned with capitalism's goals of extracting just a bit more of this sweet surplus value from selling slightly repainted thing again and again in faster and faster loop ... leaving "boring" past codebase behind, ever chasing its own tail.
So, on this sense of course TDE is welcomed divergence from mainstream. But we surely all humans and thus have various hidden assumptions and ingrained habits. May be reflecting on them periodically is good idea, even if it cuts time from coding.
Such an approach has caused that for all other patches from such an author now "local authority" must assume that this is again a hack. And because of the knowledge of the fundamental unwillingness to cooperate, "local authorities", of course, have little motivation to devote time and effort to these patches. So yes, such patches have been waiting for a long time. It is not surprising that "local authorities" prefer to pay attention to the authors who repeatedly give good contributions and cooperate very well. Such cooperation allows the project a good move forward. And we thank all such contributors! Thanks to good contributions and good cooperation, some have already become part of the Core team.
Cheers Slávek -- ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
On Sunday 24 of November 2024 07:04:02 Andrew Randrianasulu via tde-users wrote:
вс, 24 нояб. 2024 г., 05:54 Slávek Banko via tde-users <
users@trinitydesktop.org>:
On Sunday 24 of November 2024 00:33:52 deloptes via tde-users wrote:
I write nothing to TGW right now since there lie tens my previous patches!
There are a lot of patches (PRs) in the queue there. No one complains, except you. It is your free choice. I personally see it as symbiosis. And at some point of time someone picks up the patch works it out and it either accepted or rejected.
There were situations where thorough research clearly showed that the proposed patch did not solve the cause of the problem, but one specific consequence - only hides the real cause of the problem. While the other potential consequences would remain unresolved and would probably wait for the next hack, which would again solve the individual consequences, not the cause. While the author fundamentally refused any cooperation in finding a real cause. As a result, real repairs of the causes of the problems were merged instead of the proposed hack.
To be honest I (as non-developer who somewhat forced to be) tend to see things more from "forever novice" perspective: TDE is big codebase, and assuming someone can jump right in and prepare professional quality solution you simply can merge ... is a bit unrealistic?
yes, people might be uncomfortable to extreme if you ask them to do professional analysis even without telling them *how* it done (assuming here they, like you, know it by heart).
I guess it hurts both ways .....
Yes, it is a large volume of code and it can be difficult to get a thorough overview. But yes, even without obtaining a thorough overview, someone can do a good finding of a specific bug and prepare a good fix. For example, thanks to backtrace from the grash. And there is no problem to accept and merge a good patch from anyone.
Likewise, there is no problem, if someone suggests a patch, we give him comments that there is a need for some modifications and thanks to the mutual cooperation between the author and the revising after a while we move to a good patch, which we then like to merge. This is then beneficial for both sides - the author gets feedback and will gain better overview and experience, the project will gain repair and improvements.
However, when someone gives a patch that, for example, removes a line with a call to release memory, at first glance it looks like an incorrect solution. When the author on the comment: "This looks like this will require a more thorough examination to solve the real cause of the problem," he responds by calling: "No, it works for me, I will not do anything else! You have to merge it as I did it!”, that's a problem. When, after some time and thorough examination, it confirms that the problem was elsewhere and the solution was different, but the author still shouts: "My fix was correct! You should have merge it as I did it!", this is indeed a problem to try to cooperate with such an author.
Cheers Slávek --
On Nedila 24 Lystopad 7532 11:07:31 Slávek Banko via tde-users wrote:
However, when someone gives a patch that, for example, removes a line with a call to release memory,
And when "the root knowledger" is known nothing about zombie processes-threads which are the ones, who hold the memory, and when they are missing, that is about the memory releasing by the thread at such thread options, so waiting is spare here? :)
And this I was seen obviously, since I am using that constantly, and I see that constantly on hundred threads and I'll fix that when I see such here in next merge request — theoretischer! :)
And what are you freezing in whole when even at the memory leaks here, most users will not see that at even ten sessions, when constant crashing must you restarting the system constantly? :)
Tell us also about bad using "goto" from other "local authority"! :)
@TDE team, contributors, users, whoever: let this be the last email on the subject, it doesn't do any good to continue arguing on this ML.
@Roman: you decided to go your own way with your own TDE fork/maintenance. Fine, no one is telling you how and what you should do. But please stop harassing the project, the devs, the users, the ML, TGW, anything. You are not helping the project nor the community and you are basically making a fool of yourself. For someone who develops and maintains an opensource project like openscada, you should really know better. This has nothing to do with TDE, it's about human behavior and etiquette.
I invite everyone not to reply any more on the subject. Roman, if you keep harassing this ML, we will consider putting you under moderation from now on.
Cheers Michele
On Nedila 24 Lystopad 7532 12:20:00 Michele Calgaro via tde-users wrote:
@Roman: you decided to go your own way with your own TDE fork/maintenance.
Again! I was forced to create the my partial fork after my critical for me patches became ignored by YOUR, that I did not choose that!
You are not helping the project nor the community and you are basically making a fool of yourself.
And after that you even want to shut up me, making your fool?
For someone who develops and maintains an opensource project like openscada, you should really know better.
I know and you not. :)
This has nothing to do with TDE, it's about human behavior and etiquette.
So that is you, who started spoiling the behavior!
Roman, if you keep harassing this ML, we will consider putting you under moderation from now on.
You are moderating me far ago, so continue! :)
@Roman: As perfectly expected (see [1]) you have just made yourself a moderated member of this ML. All your future emails will be filtered and only approved if they are of any benefit to the project or community. Go, be proud of yourself and your behavior, celebrate! :-)
Cheers Michele
[1] https://qz.com/967554/the-five-universal-laws-of-human-stupidity or just google for Carlo Cipolla's Laws of Stupididy
On Nedila 24 Lystopad 7532 01:33:52 deloptes via tde-users wrote:
There are a lot of patches (PRs) in the queue there. No one complains, except you. It is your free choice. I personally see it as symbiosis. And at some point of time someone picks up the patch works it out and it either accepted or rejected.
And I was forced to create the my partial fork after my critical for me patches became ignored, that I did not choose that!
No idea, but this is the result, when you kind of fork and continue on your own.
Not fork but stupid re-branding, with constant symbols renaming forward and back, with changing the well tested and debugged building system and loss support of old systems, so caused many hidden and even visible broken code instead the using stabilisation of the mature code. Also as changing habits of the code development and debugging especially for partial fast building, by implementation cmake, ninja and so on.
I guess you describe here evolution. Sometimes evolution also makes mistakes, but it tends to correct them over time.
REvolution, due to many code were just changed in renaming the symbols, and Evolution is about "the using stabilisation of the mature code".
I personally had conversations (chats and mails) with the "local authority" and understood how they think and operate. I have very positive view of them ... they are indeed acting as authority, because they are indeed the authority over TDE, but they are cooperative and as far as you are also cooperative, it works just fine. I am writing you this, to encourage you and the rest to cooperate, because so it benefits the whole community.
There is no benefits in symbols renaming also as no benefits in cmake in comparing Autotools!
IMO it would be better for all parties that you try doing only temporary changes and try get them into the main repo, because other wise the work increases over time. At the end it is your own choice what you do. You are the "local authority for your work".
I NEVER overpress others, leaving for them the responsibility for their code, which they can improve after exploiting the applied code, especially when I don't know deep of the problem specific, that is when I don't use this function!
And I was forced to create the my partial fork after my critical for me patches became ignored, that I did not choose that!
And I choose to cooperate and saw my patches go into TDE (one of the first patches is benefitting you too, because it solved UTF-8 in kalendar and kontact and may be other applications)
I have cooperated also before "the local authority" "climbs on heavens" and start to think they "know roots" and me is just stupid with fixing their saint breakages. :)
If you wish you can write to me in private what issues you have, or post them here one by one, so that we could discuss.
I have no problem with my "hacks", also as I have no time and wishes to prove something for the "local authority"! :)
I and I guess the rest have also no problems with your fork and patches. The problem is with the attitude published in the news group, where everybody can read it and in fact is factually not true. This is why I am writing to you. Remember - the whole world reads this!
And that is VERY GOOD, as I said you also!
It would be great if you could contribute, but this includes obeying the local authority. I am pretty happy with the cooperation with this local authority. Few things/bugs that were bothering me and I fixed were accepted without big problems and I learned a lot. I also ported one or two applications and it also worked quite well. It is just a normal work flow that you have in every company or open source project.
That is not normal in my open source project!
Well ... so you have a clone/fork of TDE which you commit to maintain yourself. Why bother TDE?
And that is not me say about to write in TGW! :)
I really do not understand your frustration, but it is sad to hear disappointment. You probably never dealt with Gnome/KDE or other projects and their "local authorities"
I dealt with the official builds of some Linux distributions, and saw there horde of the patches to KDE3, so I can imagine about that "tradition". :)
KDE3 is not TDE ... the KDE3 team had it's own issues. I do not think you can compare both. I mean you can compare if you wish of course, but it is not right as these are two different things.
Ooo I can already compare, since the patchset achieves the original KDE3 in ALTLinux. :)
You have to adjust the headers a bit and recompile, which the devs are doing anyway for us.
So, where are you already compiled 14.1.3 for Debian 7,8,9? :)
This is waste of time, disk space (and electricity) I do not have such systems - in fact it is actually not recommended (it would be forbidden) to use them for security reasons.
If that waste of time, then you can forget this problem, due to it mostly for Debian 7 and the old build 14.0.10. When you want to save disk space, remove old builds, which are not needed anybody exactly.
And last versions for old distributions and HW I need, due to work with such hardware, where you cannot to install fresh distributions whether in reasons of kernels, or specific modules to them, also as through the productivity and do not generating HW garbage.
I have done some calculations and it does not pay off to keep old hardware. The productivity of CPUs is so low for the power consumption that it obsoletes itself immediately. I had two Acrosser (i386) devices from 2007 with 256MB (yes MB) memory and 300MHz CPU.
256MB is enough for many old HW and KDE3 here, and I have two such ones: K6-2/600 and P3/700 from 2000 years and which fine works right now.
I had to compile the kernel myself, because of a combination of available but not active drivers. It was a pain. After one of them got broken (I guess the electronics for the CF-IDE controller gave up) I bought a replacement (x86_64) with 4GB memory a decent CPU and the almost same power consumption. Now I do not have to compile the kernel anymore. It works like a charm. This is called evolution. At some point of time things have to be replaced.
And I just use Debian 7 with 486 kernel and TDE 14.0.10 with all my actual patchset, and don't say about "evolution fouling", when we soon will be completely in the trash, who'll survive of course after the jeviary (jewish-aries) action in utilization the population and replacing us by AI-robots. :)
If I were you I would keep a repository of those old distros (also a repository of the distro itself). I have local repositories, but I tend to update to latest whenever possible.
Again, I write this as invitation to cooperate. It benefits everybody.
Maybe, due to I am already patching in fact all used packages by me, and in fact 14.0.10 is that repository. :)
-
Andrew Randrianasulu -
deloptes -
Dr. Nikolaus Klepp -
Michele Calgaro -
Roman Savochenko -
Slávek Banko