[opensuse] Help with system architecture documentation, please
I have been searching trying to discover why so many of my 42.3 applications fail in leap 15. As a test I rebooted my system so things would be fresh, and then executed: pstree -p -n With Thunderbird, Firefox, Rhythmbox, fvwm2, a terminal an a few others, there were 438 different processes spawned. Just Firefox was responsible for 238 processes. Rhythmbox, one of my problem apps, had 10 processes. I would like to find documentation describing how one would write an application and all of the synchronization requirements linked by gdbus and the other protocols. I am currently rereading the systemd documentation which gives some of the desired information at startup. What I would like is a document that ended with a cookbook giving a full example of an application. For example a simple window with a push button in it. I am sure people do write code for opensuse, or else we wouldn't need such a software development environment. The only documentation I can find relates to setting up the environment and system management. Thanks, and it doesn't have to be free. I will buy a book if available. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/6/2018 12:29 AM, don fisher wrote:
I have been searching trying to discover why so many of my 42.3 applications fail in leap 15. As a test I rebooted my system so things would be fresh, and then executed:
pstree -p -n
With Thunderbird, Firefox, Rhythmbox, fvwm2, a terminal an a few others, there were 438 different processes spawned. Just Firefox was responsible for 238 processes. Rhythmbox, one of my problem apps, had 10 processes.
I would like to find documentation describing how one would write an application and all of the synchronization requirements linked by gdbus and the other protocols. I am currently rereading the systemd documentation which gives some of the desired information at startup. What I would like is a document that ended with a cookbook giving a full example of an application. For example a simple window with a push button in it.
I am sure people do write code for opensuse, or else we wouldn't need such a software development environment. The only documentation I can find relates to setting up the environment and system management.
Thanks, and it doesn't have to be free. I will buy a book if available. Don
Wow! You definitely have the "Go Big or Go Home!" attitude. That's admirable. Either I don't understand the scope of what you are asking or you are asking for a whole lot more than you think you are?? For starters, which language would you like to write it it? That will make a whole lot of difference in the tools you have to talk to all the various associated processes in. What toolkit? Gtk+, Qt, X11, wxwidgets? What is the app supposed to do? An app with just a push button is fairly simple, but how you go about doing it is wildly different between Gtk+2.0, Gtk+3.0, Qt4, Qt5, or just good old Xwindows. There are a number of good tutorials for each. For example a Gtk+2 window with a button in it that just quits the app could be as short as: #include <gtk/gtk.h> int main(int argc, char *argv[]) { GtkWidget *window; /* pointer for main window */ GtkWidget *halign; /* pointer for alignment object */ GtkWidget *btn; /* pointer for button */ gtk_init(&argc, &argv); /* the normal gtk initialization */ window = gtk_window_new(GTK_WINDOW_TOPLEVEL); /* create main window */ gtk_window_set_title(GTK_WINDOW(window), "GtkButton"); /* set title */ gtk_window_set_default_size(GTK_WINDOW(window), 230, 150); /* size */ gtk_container_set_border_width(GTK_CONTAINER(window), 15);/* border */ /* window position on screen */ gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); halign = gtk_alignment_new(0, 0, 0, 0); /* alignment top left */ gtk_container_add(GTK_CONTAINER(window), halign); /* add to window */ btn = gtk_button_new_with_label("Quit"); /* new button "Quit" */ gtk_widget_set_size_request(btn, 70, 30);/* button size */ gtk_container_add(GTK_CONTAINER(halign), btn); /* add to alignment */ g_signal_connect(G_OBJECT(btn), "clicked", /* respond to clicked */ G_CALLBACK(gtk_main_quit), G_OBJECT(window)); g_signal_connect(G_OBJECT(window), "destroy", /* handle titlebar X */ G_CALLBACK(gtk_main_quit), NULL); gtk_widget_show_all(window); /* make it all visible */ gtk_main(); /* run the loop to respond to events (like click) */ return 0; } (save as mygtkapp.c) Which you could compile with $ gcc -Wall -Wextra -o mygtkapp mygtkapp.c `pkg-config --cflags --libs gtk+-2.0` (with gtk2-devel, libgtk-2_0-0 and pkg-config installed) Kdevelop used to come with a built-in tutorial that showed you how to do the same thing with KDE/Qt. I haven't checked whether the current works. But you can basically pick your toolkit you want to work with, and then search "tookit tutorial examples" in your favorite search engine and get a good smattering of pages. (and don't forget to search "tookit manual" to get a link to the manual and API for whatever you are using) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-07-06 08:48, David C. Rankin wrote:
An app with just a push button is fairly simple, but how you go about doing it is wildly different between Gtk+2.0, Gtk+3.0, Qt4, Qt5, or just good old Xwindows. There are a number of good tutorials for each.
I wrote an app with 24 buttons ;-) I used Lazarus. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
don fisher wrote:
I would like to find documentation describing how one would write an application and all of the synchronization requirements linked by gdbus and the other protocols. I am currently rereading the systemd documentation which gives some of the desired information at startup. What I would like is a document that ended with a cookbook giving a full example of an application. For example a simple window with a push button in it.
You will almost certainly find such demo apps for Qt "out there". Everyone has to start somewhere.
I am sure people do write code for opensuse,
Personally speaking, since around 2006.
or else we wouldn't need such a software development environment. The only documentation I can find relates to setting up the environment and system management.
A lot depends on whether you're writing a GUI app or for the command line (utilities, daemons). -- Per Jessen, Zürich (17.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/05/2018 10:29 PM, don fisher wrote:
I have been searching trying to discover why so many of my 42.3 applications fail in leap 15. As a test I rebooted my system so things would be fresh, and then executed:
pstree -p -n
With Thunderbird, Firefox, Rhythmbox, fvwm2, a terminal an a few others, there were 438 different processes spawned. Just Firefox was responsible for 238 processes. Rhythmbox, one of my problem apps, had 10 processes.
I would like to find documentation describing how one would write an application and all of the synchronization requirements linked by gdbus and the other protocols. I am currently rereading the systemd documentation which gives some of the desired information at startup. What I would like is a document that ended with a cookbook giving a full example of an application. For example a simple window with a push button in it.
I am sure people do write code for opensuse, or else we wouldn't need such a software development environment. The only documentation I can find relates to setting up the environment and system management.
Thanks, and it doesn't have to be free. I will buy a book if available. Don
I was looking for an overview that would show how process communicate etc. Also what is current. I assume from another email on this thread that Gtk+3.0 and Qt5 are current. Does that show up anywhere, except by searching Yast2? In rhythmbox there are numerous calls for services from gdbus. Then there is the /run directory which does a lot I am unaware of, and the /run/user. I would like to know what is supposed to be there and how does it gets there. Again, ldd on rhythmbox shows links to 105 libraries. Many I recognize, but most I do not. I was looking for something like the systemd documentation that explains the different components and how they fit together. It may be hopeless. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2018-07-06 a las 12:29 -0700, don fisher escribió:
I was looking for an overview that would show how process communicate etc. Also what is current. I assume from another email on this thread that Gtk+3.0 and Qt5 are current. Does that show up anywhere, except by searching Yast2? In rhythmbox there are numerous calls for services from gdbus. Then there is the /run directory which does a lot I am unaware of, and the /run/user. I would like to know what is supposed to be there and how does it gets there. Again, ldd on rhythmbox shows links to 105 libraries. Many I recognize, but most I do not. I was looking for something like the systemd documentation that explains the different components and how they fit together. It may be hopeless.
Most of what systemd does has no direct relation to your program. - -- Cheers Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAls/5bgACgkQja8UbcUWM1zc8wD9EYYrFxFhYXcFy2Zz2dmlyUW/ 8NNMGsCRREnGZ2G6rdgA/jnUbXKDVKpd3Z23v0EL7A6Ja/SMcg3XXyW26rHDU3kf =K1Va -----END PGP SIGNATURE-----
On 07/06/2018 02:29 PM, don fisher wrote:
I was looking for an overview that would show how process communicate etc. Also what is current. I assume from another email on this thread that Gtk+3.0 and Qt5 are current.
They are the current upstream toolkits and are recommended for new development. Why you will continue to see Gtk+2 and Qt4 (and others) is there are many, many applications that have not yet been fully ported to the new versions (and the packages are important enough to keep). Since most GUI applications are tens of thousands of lines of code (if not hundreds of thousands of lines for medium sized apps), there is a lot of effort involved in porting applications from say Qt4 to 5 or Gtk+2 to 3. I have done a good deal with Gtk, and I don't know of any single source manual that lays the entire process out in a concise summary form. Primarily because there are many libraries involved with Gtk (gtk, gdk, glib, gio, pango, etc.), e.g. A good starting point for the Gtk side is: https://developer.gnome.org/ Where you then get the individual pieces https://developer.gnome.org/gtk2/2.24/ https://developer.gnome.org/gtk3/stable/ https://developer.gnome.org/glib/stable/index.html https://developer.gnome.org/pango/stable/index.html For Qt http://doc.qt.io/qt-5/qtdesigner-manual.html http://doc.qt.io/qt-5/qtexamplesandtutorials.html and https://qmlbook.github.io/assets/qt5_cadaques.pdf http://www.bogotobogo.com/Qt/Qt5_TutorialHelloWorld.php http://zetcode.com/gui/qt5/ (note: zetcode.com has nice tutorials for both Gtk and Qt - and a lot more) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
don fisher wrote:
Then there is the /run directory which does a lot I am unaware of, and the /run/user. I would like to know what is supposed to be there and how does it gets there.
If you google "linux /run", there is quite a bit of material out there. E.g.: https://unix.stackexchange.com/questions/13972/what-is-this-new-run-filesyst... https://www.quora.com/What-is-the-significance-of-the-run-directory-in-Linux
Again, ldd on rhythmbox shows links to 105 libraries. Many I recognize, but most I do not. I was looking for something like the systemd documentation that explains the different components and how they fit together. It may be hopeless.
That might be asking a lot. This is from a postfix policy daemon I've been working on this week: per@test99:~/pfpd.smtpquota> ldd pfpd.smtpquota linux-vdso.so.1 libmariadb.so.3 => /usr/lib64/libmariadb.so.3 libc.so.6 => /lib64/libc.so.6 libz.so.1 => /lib64/libz.so.1 libdl.so.2 => /lib64/libdl.so.2 libpthread.so.0 => /lib64/libpthread.so.0 libssl.so.1.1 => /usr/lib64/libssl.so.1.1 libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 /lib64/ld-linux-x86-64.so.2 When I link, I only include libmysqlclient, which then drags in the rest (except for libc). -- Per Jessen, Zürich (17.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle. There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV. So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have. All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking. But let me give one BIG HUNT. Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in the low levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown. Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk packages for most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more. Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl. See also the Tk for Ruby and Perl. In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer. Getting away from the swamp of detail will let you focus on what structures and communication paths are about.. -- Good plans shape good decisions. That's why good planning helps to make elusive dreams come true. - Lester R. Bittel The Nine Master Keys of Management -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/08/2018 09:52 AM, Anton Aylward wrote:
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in the low levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk packages for most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any projects that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must admit that when I first met linux it was before kernel version 1.x, and the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane. Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run directory, or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was trying to do was get a picture of the system so I would have a chance with my debugging task. I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series. When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets. So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-) Thanks again, Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 8, 2018 5:24:53 PM PDT, don fisher <hdf3@comcast.net> wrote:
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in
levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk
On 07/08/2018 09:52 AM, Anton Aylward wrote: the low packages for
most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any projects that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must
admit that when I first met linux it was before kernel version 1.x, and
the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane.
Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run directory, or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was
trying to do was get a picture of the system so I would have a chance with my debugging task.
I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series.
When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets.
So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-)
Thanks again, Don
Sorry to inform you that John died on Friday. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/08/2018 05:26 PM, John Andersen wrote:
On July 8, 2018 5:24:53 PM PDT, don fisher <hdf3@comcast.net> wrote:
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in
levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk
On 07/08/2018 09:52 AM, Anton Aylward wrote: the low packages for
most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any projects that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must
admit that when I first met linux it was before kernel version 1.x, and
the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane.
Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run directory, or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was
trying to do was get a picture of the system so I would have a chance with my debugging task.
I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series.
When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets.
So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-)
Thanks again, Don
Sorry to inform you that John died on Friday.
Please clarify. Except for yourself, I do not see a John in the thread. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.21.1807090252330.22540@minas-tirith.valinor> El 2018-07-08 a las 17:26 -0700, John Andersen escribió:
Date: Sun, 08 Jul 2018 17:26:58 -0700 From: John Andersen <jsamyth@gmail.com> To: opensuse@opensuse.org Subject: Re: [opensuse] Help with system architecture documentation, please
On July 8, 2018 5:24:53 PM PDT, don fisher <hdf3@comcast.net> wrote:
On 07/08/2018 09:52 AM, Anton Aylward wrote:
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in the low levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk packages for most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any projects that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must
admit that when I first met linux it was before kernel version 1.x, and
the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane.
Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run directory, or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was
trying to do was get a picture of the system so I would have a chance with my debugging task.
I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series.
When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets.
So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-)
Thanks again, Don
Sorry to inform you that John died on Friday.
Please clarify. You, John Andersen <jsamyth@gmail.com>, say that John Andersen <jsamyth@gmail.com> died? And the quoted material above was not written by John, but by Anton and don. I don't understand at all. - -- Cheers Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAltCsikACgkQja8UbcUWM1xa9AD9G9CGn5lAoR7THyZZe1WTWkDH lZyUtmorfZmcKcswIkUA/3Dm1KzC9L3Il60s1f6TwxPSepYr//CXHLhrBSNBFjL0 =wdOh -----END PGP SIGNATURE-----
On July 8, 2018 5:54:01 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: <alpine.LSU.2.21.1807090252330.22540@minas-tirith.valinor>
El 2018-07-08 a las 17:26 -0700, John Andersen escribió:
Date: Sun, 08 Jul 2018 17:26:58 -0700 From: John Andersen <jsamyth@gmail.com> To: opensuse@opensuse.org Subject: Re: [opensuse] Help with system architecture documentation, please
On 07/08/2018 09:52 AM, Anton Aylward wrote:
On 06/07/18 03:29 PM, don fisher wrote:
I was looking for an
If the rest of this thread is anything to go by you are looking for multiple things and trying to take it in all in one bite, and that 'all in one bite' is presenting the main hurdle.
There has been a lot written over the decades on HOW processes communicate, from pipes, sockets, message queues and the back-porting of 'mainframe' techniques such as "MQ" to do thing that you can do anyway and always could with UNIX. In days of yore UUCICO was a method for processes to communicate when we didn't have sockets or any 'network' better than the public switched telephone system between computers. YMMV.
So take this all in parts. Try to master parts. As you do so you will be faced with 'alternatives' and you will learn what the various options and components are for. You will be faced with the same decisions that other developers have faced and that is the BEST way to learn the reasons why we have the structures and methods that we do have.
All that being said, a lot of your answers ARE out there. The thing with, for example, google, is to ask the right questions and the only way you can get to that point is to go though the doing so you learn what you should be asking.
But let me give one BIG HUNT.
Stop programming in C or C++. It makes you drown in the details and the you will get so tied up in the low levels of coding that you are going to be missing the larger context, which relate to the question you are asking and the questions you need to asks. Not that C or C++ is inherently 'evil' or anything, just that you'll drown.
Others have mentioned development environments and tools. Carlos mentioned Lazarus. In my time I've used the database backed appl tools such as PROGRESS (commericial) and more recently for Web applications, RubyOnRails. If you don't want to get too far removed then there are the /Tk
most scripting languages, Ruby, Python, Perl, as well as the pipes and sockets and networking
Information for package tk: --------------------------- Repository : openSUSE-Leap-42.3-Update Name : tk Version : 8.6.7-8.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.5 MiB Installed : Yes Status : up-to-date Source package : tk-8.6.7-8.1.src Summary : Graphical User Interface Toolkit for Tcl Description : Tk is a graphical user interface toolkit that takes developing desktop applications to a higher level than conventional approaches. Tk is the standard GUI not only for Tcl, but for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.
Information for package python-tk: ---------------------------------- Repository : openSUSE-Leap-42.3-Update Name : python-tk Version : 2.7.13-27.3.1 Arch : x86_64 Vendor : openSUSE Installed Size : 1.6 MiB Installed : No Status : not installed Source package : python-2.7.13-27.3.1.src Summary : TkInter - Python Tk Interface Description : Python interface to Tk. Tk is the GUI toolkit that comes with Tcl.
See also the Tk for Ruby and Perl.
In particular, the use of these HLL simplifies all the socket workings that you touch on. That /Tk makes the GUI side a good bit simpler that the raw C is also nicer.
Getting away from the swamp of detail will let you focus on what structures and communication paths are about..
Thanks for the info. To clarify things a bit, I do not have any
that need to be built in a specific language. I did use Tk way back, probably in the last century:-) Recently I have made some progress reading documentation from opensuse and Redhat. I used to write a lot of image processing and graphics software, mostly in C and C++. But I must
admit that when I first met linux it was before kernel version 1.x, and
the distribution arrived as a box of floppies. My mission required a lot of pseudo real time programming where I mapped shared memory segments, spawned processes that could work in parallel, communicate between threads, etc. gdb kept me sane.
Recently, when I was trying to upgrade to Leap 15 I experienced many problems. It was often suggested to that I use other code etc. But if there was a simple bug that I could fix I felt that was the most desirable route. All these codes executed under 42.3. Back when I was writing device drivers there was no such thing as the /run
On July 8, 2018 5:24:53 PM PDT, don fisher <hdf3@comcast.net> wrote: packages for projects directory,
or even udev. Modern apps such as rhythmbox are quite complex and make many calls to parts of the system I did bot even know existed. So what I was
trying to do was get a picture of the system so I would have a chance with my debugging task.
I am getting a grip on systemd, the boot process, D-Bus, udev, and gdbus. Once these concepts are clear I will try again. I guess I was hoping for some clarity like that in the 8 volume 'X Window Development' series.
When I was doing real time programming I often was forced to code in assembler, for example, to access the speed advantages present with the sse3 instructions present in both the Intel and Amd processor chipsets.
So I do not think I ever felt drowned by the lower level languages. Again, gdb was my life preserver:-)
Thanks again, Don
Sorry to inform you that John died on Friday.
Please clarify. You, John Andersen <jsamyth@gmail.com>, say that John Andersen <jsamyth@gmail.com> died?
And the quoted material above was not written by John, but by Anton and don.
I don't understand at all.
- -- Cheers Carlos E. R.
(from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iF4EAREIAAYFAltCsikACgkQja8UbcUWM1xa9AD9G9CGn5lAoR7THyZZe1WTWkDH lZyUtmorfZmcKcswIkUA/3Dm1KzC9L3Il60s1f6TwxPSepYr//CXHLhrBSNBFjL0 =wdOh -----END PGP SIGNATURE-----
This message is from John's wife - John died early Friday morning. J -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2018-07-08 a las 18:03 -0700, John Andersen escribió:
On July 8, 2018 5:54:01 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Sorry to inform you that John died on Friday.
Please clarify. You, John Andersen <jsamyth@gmail.com>, say that John Andersen <jsamyth@gmail.com> died?
And the quoted material above was not written by John, but by Anton and don.
I don't understand at all.
This message is from John's wife - John died early Friday morning. J
Oh! Sorry, now I understand. You are using his email to tell us. Thank you, we appreciate that. My condolences. I'm sorry. - -- Cheers Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAltCvVAACgkQja8UbcUWM1xKdwD6AxT++ZcKl0gd/Qy5U8Y0sXL3 G5BrnnW0FNT4LhrNGUcA/2dqiqHTp86lafaXic9j4GH3tbPlRijWBpRuUiQsxLKP =Wwqh -----END PGP SIGNATURE-----
participants (6)
-
Anton Aylward -
Carlos E. R. -
David C. Rankin -
don fisher -
John Andersen -
Per Jessen