I would like to offer that with my efforts to build TDE on vintage systems, I built TDE R14.1.2 on Slackware 14.2 64-bit (gcc 5.5.0) and Slackware 14.1 32-bit (gcc 4.8.2). Both systems are EOL as of Dec. 2023. I did not build every package but core dependencies and packages built and run.
I had to find some patches to back port. For example, some patches related to hotpluggable hwlib and ensuring '-std=c++11' is declared with tqt3.
These days my brain is entrenched in old fart elderly territory and I have my days exhibiting grumpy old man traits. I have been out of the loop for many years with this kind of development and tend to lose patience easily. That said, that I have built the latest TDE on vintage systems is remarkable.
Dare I say that the 14.1 builds are running on Pentium I/II single core systems with less than 512 MB of RAM and a 3.10.107 kernel? A tad slow? Yes, but everything functions and the slowness is mostly caused by PATA drives.
I am impressed with the developers far more than a grumpy old man being able to build TDE on vintage systems. Good job devs. :)
Darrell Anderson via tde-devels wrote:
These days my brain is entrenched in old fart elderly territory and I have my days exhibiting grumpy old man traits. I have been out of the loop for many years with this kind of development and tend to lose patience easily. That said, that I have built the latest TDE on vintage systems is remarkable.
Dare I say that the 14.1 builds are running on Pentium I/II single core systems with less than 512 MB of RAM and a 3.10.107 kernel? A tad slow? Yes, but everything functions and the slowness is mostly caused by PATA drives.
What is the benefit of all this? It consumes much more electricity for nothing. Wouldn't it be better to build for example in i386 chroot on amd64 or VM? You can install then in the older system.
On 5/20/24 5:58 PM, deloptes via tde-devels wrote:
What is the benefit of all this? It consumes much more electricity for nothing. Wouldn't it be better to build for example in i386 chroot on amd64 or VM? You can install then in the older system.
Seems somebody always raises this question. What's the benefit of maintaining anything, such automobiles or furniture? I still have the first hand tool I purchased -- a hammer in 1977. Still works.
Many people waste more electricity with their huge power hogging refrigerators and swimming pool pumps than I will ever use with vintage computers that get powered on a few times a month. Total house electricity usage here usually is less 200 kw-hrs/month. I doubt many people can make a similar claim.
The real benefit is because I want to. Tinkering with older computers brings me pleasure. Like keeping KDE3 on life support?
Darrell Anderson via tde-devels wrote:
Many people waste more electricity with their huge power hogging refrigerators and swimming pool pumps than I will ever use with vintage computers that get powered on a few times a month. Total house electricity usage here usually is less 200 kw-hrs/month. I doubt many people can make a similar claim.
we are 3 of us in the household and we use 2800kWh/year which give 233/month (and cooking is electric :) ) or 319W/h. All the PCs use about 150W/h. I think it is fair, given that I work now from home most of the time.
The real benefit is because I want to. Tinkering with older computers brings me pleasure. Like keeping KDE3 on life support?
Of course you have the right to do it and it is respected. My question was why would you try building on that old hardware not why you would use TDE on the old hardware. I find it boring ... it is like slooooow mooootiooon :) It is just unnecessary power consumption. Same with old card, but they at least cost something (asset). On the PC I use as server I put SSDs few years ago and moved the TDE repo there. With addition of ninja (thanks Slavek) it now builds whole TDE in couple of hours. I build few times in qemu for armel/armhf and arm64 ... it took almost 2 days.
On 5/21/24 6:56 PM, deloptes via tde-devels wrote:
we are 3 of us in the household and we use 2800kWh/year which give 233/month (and cooking is electric :) ) or 319W/h. All the PCs use about 150W/h. I think it is fair, given that I work now from home most of the time.
Sounds as though we both focus on energy conservation. :) Last summer I replaced most light bulbs in the house with equivalent LEDs. I ran a rough estimate on the return with the electric bill and decided I would break even in less than two years not using incandescent bulbs.
I replaced HDs in some computers with SSDs as well as updating some monitors to further reduce energy usage.
The real benefit is because I want to. Tinkering with older computers brings me pleasure. Like keeping KDE3 on life support?
Of course you have the right to do it and it is respected. My question was why would you try building on that old hardware not why you would use TDE on the old hardware. I find it boring ... it is like slooooow mooootiooon :)
Yes, slow compared to modern computers, including 10/100 Mbps NICs (my 486 has a 10 Mbps NIC!). But I have been using computers for more than 40 years and at one time these systems were state of the art. The 486 saw extensive action in the 1990s as my main work horse making a living as a tech writer.
Desktop environments are a tad slow, which is why I try to compile TDE for these older systems. Running KDE or GNOME is impossible. Many functions from the console are acceptably responsive -- not fast but acceptable. I don't run these systems 24/7 or even daily. Often they sit for a few weeks until I get the urge to tinker with something specific.
Important though is I like tinkering with them much like people tinker with old cars. There is a strong nostalgic effect playing with them. I wish I still had my C-64 and Amiga 1000 and 3000.
Another benefit of tinkering is I receive feedback with my daily "admin" efforts because the systems are slower. I might tweak a system wide shell script only to find the slower system does not respond like the other systems.
I run older Slackware releases on the older hardware. This helps me tune my "admin" skills in that a lot tends to change from one release to the next -- in any distro. Every time there is a new release I always find some of my shell scripts failing on previous releases or the new release. That helps me keep learning.
At one time I worked as a Linux admin and I always have been the computer go-to person in the office. Being retired I like being able to play admin at home without some numb nut supervisor or owner looking over my shoulder.
The tinkering helps me keep my mind ticking. I don't want to start drooling in my arm chair. I can't stop aging, none of us can, but I can impede the effects by keeping my mind and body active.
It is just unnecessary power consumption. Same with old card, but they at least cost something (asset).
Unnecessary to whom? One person's garbage is another person's treasure and all that. I also have vintage virtual machines. They get used more often than the vintage hardware, but nothing simulates real hardware like real hardware.
On the PC I use as server I put SSDs few years ago and moved the TDE repo there. With addition of ninja (thanks Slavek) it now builds whole TDE in couple of hours. I build few times in qemu for armel/armhf and arm64 ... it took almost 2 days.
Well, a day or two ago I mentioned the wiki listing build times. I wrote that section long ago after I had just purchased my first dual core. Build times today make those old wiki times look strange.
On 2024-05-21 19:20:45 Darrell Anderson via tde-devels wrote:
On 5/21/24 6:56 PM, deloptes via tde-devels wrote:
we are 3 of us in the household and we use 2800kWh/year which give 233/month (and cooking is electric :) ) or 319W/h. All the PCs use about 150W/h. I think it is fair, given that I work now from home most of the time.
Sounds as though we both focus on energy conservation. :) Last summer I replaced most light bulbs in the house with equivalent LEDs. I ran a rough estimate on the return with the electric bill and decided I would break even in less than two years not using incandescent bulbs.
I replaced HDs in some computers with SSDs as well as updating some monitors to further reduce energy usage.
The real benefit is because I want to. Tinkering with older computers brings me pleasure. Like keeping KDE3 on life support?
Of course you have the right to do it and it is respected. My question was why would you try building on that old hardware not why you would use TDE on the old hardware. I find it boring ... it is like slooooow mooootiooon :)
Yes, slow compared to modern computers, including 10/100 Mbps NICs (my 486 has a 10 Mbps NIC!). But I have been using computers for more than 40 years and at one time these systems were state of the art. The 486 saw extensive action in the 1990s as my main work horse making a living as a tech writer.
A benefit of this is recognizing how far PCs have come since the IBM PC was released. Most people don't understand how lucky they are these days. :-)
Desktop environments are a tad slow, which is why I try to compile TDE for these older systems. Running KDE or GNOME is impossible. Many functions from the console are acceptably responsive -- not fast but acceptable. I don't run these systems 24/7 or even daily. Often they sit for a few weeks until I get the urge to tinker with something specific.
Important though is I like tinkering with them much like people tinker with old cars. There is a strong nostalgic effect playing with them. I wish I still had my C-64 and Amiga 1000 and 3000.
I wish I could do with DCOP what I could with the Amiga's inter-application ports. (It's not that DCOP doesn't provide such an interface, but that TDE applications don't provide much in the way of user-level commands; e.g. YAM allows one to easily navigate mail folders, switch mail items, etc.; there are no similar commands in Kmail's DCOP interface, mostly they are involved with manipulating windows, not their contents; and in KDE and TDE there is no information about DCOP capabilities in applications' handbooks, so it's very hard to figure out how to do much with DCOP.
Another benefit of tinkering is I receive feedback with my daily "admin" efforts because the systems are slower. I might tweak a system wide shell script only to find the slower system does not respond like the other systems.
I run older Slackware releases on the older hardware. This helps me tune my "admin" skills in that a lot tends to change from one release to the next -- in any distro. Every time there is a new release I always find some of my shell scripts failing on previous releases or the new release. That helps me keep learning.
At one time I worked as a Linux admin and I always have been the computer go-to person in the office. Being retired I like being able to play admin at home without some numb nut supervisor or owner looking over my shoulder.
The tinkering helps me keep my mind ticking. I don't want to start drooling in my arm chair. I can't stop aging, none of us can, but I can impede the effects by keeping my mind and body active.
It is just unnecessary power consumption. Same with old card, but they at least cost something (asset).
Unnecessary to whom? One person's garbage is another person's treasure and all that. I also have vintage virtual machines. They get used more often than the vintage hardware, but nothing simulates real hardware like real hardware.
On the PC I use as server I put SSDs few years ago and moved the TDE repo there. With addition of ninja (thanks Slavek) it now builds whole TDE in couple of hours. I build few times in qemu for armel/armhf and arm64 ... it took almost 2 days.
Well, a day or two ago I mentioned the wiki listing build times. I wrote that section long ago after I had just purchased my first dual core. Build times today make those old wiki times look strange.
Leslie -- Platform: Linux Distribution: openSUSE Leap 15.5 - x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.1.2 tde-config: 1.0
J Leslie Turriff via tde-devels wrote:
Important though is I like tinkering with them much like people tinker with old cars. There is a strong nostalgic effect playing with them. I wish I still had my C-64 and Amiga 1000 and 3000.
I wish I could do with DCOP what I could with the Amiga's inter-application ports. (It's not that DCOP doesn't provide such an interface, but that TDE applications don't provide much in the way of user-level commands; e.g. YAM allows one to easily navigate mail folders, switch mail items, etc.; there are no similar commands in Kmail's DCOP interface, mostly they are involved with manipulating windows, not their contents; and in KDE and TDE there is no information about DCOP capabilities in applications' handbooks, so it's very hard to figure out how to do much with DCOP.
I disagree here, in kdcop you should see the applications and there interfaces. It depends on the application what functionality is exposed to dcop.
BR
On 2024-05-22 04:29:29 deloptes via tde-devels wrote:
J Leslie Turriff via tde-devels wrote:
Important though is I like tinkering with them much like people tinker with old cars. There is a strong nostalgic effect playing with them. I wish I still had my C-64 and Amiga 1000 and 3000.
I wish I could do with DCOP what I could with the Amiga's inter-application ports. (It's not that DCOP doesn't provide such an interface, but that TDE applications don't provide much in the way of user-level commands; e.g. YAM allows one to easily navigate mail folders, switch mail items, etc.; there are no similar commands in Kmail's DCOP interface, mostly they are involved with manipulating windows, not their contents; and in KDE and TDE there is no information about DCOP capabilities in applications' handbooks, so it's very hard to figure out how to do much with DCOP.
I disagree here, in kdcop you should see the applications and there interfaces. It depends on the application what functionality is exposed to dcop.
BR
Of course; and I'm not criticizing here, just describing the difference in approach between DCOP and other systems' support for application extension. What I'm saying is that the DCOP functions are more concerned with manipulating the windows and dialogs of an application rather than providing ways to extend the functionality of the applications. For example, I see no way to extend the capabilities of a message view window; the only methods listed (if I am looking at the right DCOP method subset; hard to tell) are slotApplicationDisconnected(), slotFolderListUpdated(), slotFolderUpdated(), slotWalletClosed(), walletOpenResult() and interfaces(). There are no methods for retrieving the list of messages in a folder, for instance, so one cannot use DCOP to move the message view window from one message to the next. Similarly, there are apparently only a handful of text manipulation methods in Kate's DCOP repertoire: insertLine(), insertText(), removeLine(), removeText() and a few others; hardly helpful for editing text, which is the purpose of the application. Perhaps the worst deficiency of the DCOP facility is the lack of documentation, especially in the applications that provide DCOP methods; none of the application handbooks I've looked at make reference to their DCOP capabilities, so the end-user is pretty much kept ignorant of even the existence of the interface.
Leslie
J Leslie Turriff via tde-devels wrote:
Of course; and I'm not criticizing here, just describing the difference in approach between DCOP and other systems' support for application extension. What I'm saying is that the DCOP functions are more concerned with manipulating the windows and dialogs of an application rather than providing ways to extend the functionality of the applications. For
This is added automatically via the libraries - I'm not sure, but it might be via declaring as unique application.
example, I see no way to extend the capabilities of a message view window; the only methods listed (if I am looking at the right DCOP method subset; hard to tell) are slotApplicationDisconnected(), slotFolderListUpdated(), slotFolderUpdated(), slotWalletClosed(), walletOpenResult() and interfaces(). There are no methods for retrieving the list of messages in a folder, for instance, so one cannot use DCOP to move the message view window from one message to the next. Similarly, there are apparently only a handful of text manipulation methods in Kate's DCOP repertoire: insertLine(), insertText(), removeLine(), removeText() and a few others; hardly helpful for editing text, which is the purpose of the application. Perhaps the worst deficiency of the DCOP facility is the lack of documentation, especially in the applications that provide DCOP methods; none of the application handbooks I've looked at make reference to their DCOP capabilities, so the end-user is pretty much kept ignorant of even the existence of the interface.
But DCOP is not meant to be used directly. It is to provide communication between applications (even running on different computers). This is what was then replaced by DBus and the effort was discussed (Slavek, Michele other devs) what needs to be done to move TDE to DBus. I do not recall exactly if we agreed to work on that after 14.2 or so. IMO it would be great to move to DBus.
As for the functionality exposed to DCOP, it must be coded in the application, which is not done without a meaningful requirement. So what you see in DCOP is there, because something needs it to communicate with the application for a specific reason. The same holds for DBus. No one would code functionality because someone might need it. It is coded only if it is needed.
I know only this page https://www.trinitydesktop.org/docs/trinity/tdelibs/dcop/html/index.html
Regarding Kate it could be that dcop is needed for the Kate Part - I don't know for sure.
IMO DCOP is not intended for command line use
On 2024-05-23 13:32:15 deloptes via tde-devels wrote:
But DCOP is not meant to be used directly. It is to provide communication between applications (even running on different computers). This is what was then replaced by DBus and the effort was discussed (Slavek, Michele other devs) what needs to be done to move TDE to DBus. I do not recall exactly if we agreed to work on that after 14.2 or so. IMO it would be great to move to DBus.
As for the functionality exposed to DCOP, it must be coded in the application, which is not done without a meaningful requirement. So what you see in DCOP is there, because something needs it to communicate with the application for a specific reason. The same holds for DBus. No one would code functionality because someone might need it. It is coded only if it is needed.
I know only this page https://www.trinitydesktop.org/docs/trinity/tdelibs/dcop/html/index.html
Regarding Kate it could be that dcop is needed for the Kate Part - I don't know for sure.
IMO DCOP is not intended for command line use
Well, no, but for scripting, as shown in the webpage you pointed to. (Thank you for providing that; it's much more detailed than what's in the Administrator Guide handbook.) DCOP /could/ be used for extending UI functionality in applications, but apparently the designers of KDE never thought of that. In fact, the only PCish computer OSes I can think of that provide such user-oriented capability were OS/2 and AmigaOS. (There might be others I have not come across.) I admit I have been thoroughly spoiled by early exposure to IBM's text-only (then) mainframe OSes, which provided such capabilities*, and I want to emphasize that my intention in this thread is not to criticise TDE.
Leslie
*For instance, see Chapter 7 of the z/VM Xedit User's Guide - https://www-40.ibm.com/servers/resourcelink/svc0302a.nsf/pages/zVMV7R2sc2463... -- Platform: Linux Distribution: openSUSE Leap 15.5 - x86_64 Desktop Environment: Trinity Qt: 3.5.0 TDE: R14.1.2 tde-config: 1.0
J Leslie Turriff via tde-devels wrote:
IMO DCOP is not intended for command line use
Well, no, but for scripting, as shown in the webpage you pointed to. (Thank you for providing that; it's much more detailed than what's in the Administrator Guide handbook.)
This is not for scripting but for developing applications that use dcop
DCOP /could/ be used for extending UI functionality in applications, but apparently the designers of KDE never thought of that. In fact, the only
But it is not working the way you obviously think it would work. Again it is there to provide interfaces to be used between applications on the same or on a remote computer.
You can not access the interface via script - it is just like DBus - a sort of the grand mother.
PCish computer OSes I can think of that provide such user-oriented capability were OS/2 and AmigaOS. (There might be others I have not come across.) I admit I have been thoroughly spoiled by early exposure to IBM's text-only (then) mainframe OSes, which provided such capabilities*, and I want to emphasize that my intention in this thread is not to criticise TDE.
Leslie
*For instance, see Chapter 7 of the z/VM Xedit User's Guide -
https://www-40.ibm.com/servers/resourcelink/svc0302a.nsf/pages/zVMV7R2sc2463...
Mixed feelings about IBM.
On 2024-05-22 04:29:29 deloptes via tde-devels wrote:
J Leslie Turriff via tde-devels wrote:
Important though is I like tinkering with them much like people tinker with old cars. There is a strong nostalgic effect playing with them. I wish I still had my C-64 and Amiga 1000 and 3000.
I wish I could do with DCOP what I could with the Amiga's inter-application ports. (It's not that DCOP doesn't provide such an interface, but that TDE applications don't provide much in the way of user-level commands; e.g. YAM allows one to easily navigate mail folders, switch mail items, etc.; there are no similar commands in Kmail's DCOP interface, mostly they are involved with manipulating windows, not their contents; and in KDE and TDE there is no information about DCOP capabilities in applications' handbooks, so it's very hard to figure out how to do much with DCOP.
I disagree here, in kdcop you should see the applications and there interfaces. It depends on the application what functionality is exposed to dcop.
BR
Yes.
Leslie
-
Darrell Anderson -
deloptes -
J Leslie Turriff