20 May
2024
20 May
'24
3:42 p.m.
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. :)
20 May
20 May
3:58 p.m.
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.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
4:34 p.m.
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?
21 May
21 May
4:56 p.m.
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.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
5:20 p.m.
On 5/21/24 6:56 PM, deloptes via tde-devels wrote:
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.
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 :) 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.
7:54 p.m.
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:
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. :-)
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 :)
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.
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
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.
22 May
22 May
2:29 a.m.
J Leslie Turriff via tde-devels wrote:
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
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
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.
10:50 p.m.
On 2024-05-22 04:29:29 deloptes via tde-devels wrote:
J Leslie Turriff via tde-devels wrote:
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
--
Platform: Linux
Distribution: openSUSE Leap 15.5 - x86_64
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.2
tde-config: 1.0
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.
23 May
23 May
11:32 a.m.
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
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
4:18 p.m.
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/zVMV7R2sc246…
--
Platform: Linux
Distribution: openSUSE Leap 15.5 - x86_64
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.2
tde-config: 1.0
5:04 p.m.
J Leslie Turriff via tde-devels wrote:
This is not for scripting but for developing applications that use dcop
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
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/zVMV7R2sc246…
Mixed feelings about IBM.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
22 May
22 May
10:51 p.m.
On 2024-05-22 04:29:29 deloptes via tde-devels wrote:
J Leslie Turriff via tde-devels wrote:
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
--
Platform: Linux
Distribution: openSUSE Leap 15.5 - x86_64
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.1.2
tde-config: 1.0
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.
107
days inactive
111
days old
11 comments
3 participants
participants (3)
-
Darrell Anderson -
deloptes -
J Leslie Turriff