Re: [PLUG] something I am considering doing...
Paul: I tried to keep it simple on my end with just the ELF-64 file description. When I first saw all the scripts and other items pop-up under the category "executable" I was dismayed for awhile, but decided to keep it to that known file type which definitely IS an executable. This trimmed the files down from the 600K to the 14K or so (on my system) Randall On 3/25/24 07:19, Paul Heinlein wrote: On Sun, 24 Mar 2024, American Citizen wrote: Paul: Thanks for your post. Exactly what would you consider a valid statement for locating the executables? Finding executable files is not, to my mind, the same as find executable files for which I'd expect a man page. I'd suppose expect a man page for most occupants of * /bin * /usr/bin * /usr/sbin * /sbin Some denizens of /usr/libexec might warrant man pages too. One problem is that a lot of files in /usr/bin are symlinks or wrapper scripts; I'm not sure there's any "right" way to deal with them. Another problem is utilities that are often superceded by shell builtin commands. Most people don't run /usr/bin/test; they use the shell builtin 'test' or '['. So a man page for /usr/bin/test might be deceptive if its operations are not identical with those of your shell. Yet another problem is with schemes like /etc/alternatives that map a common utility name to a specific release. Different distributions handle alternatives differently; I don't have a suse system, so you'd need to look at your own setup to see what alternatives can be set there. I guess this is my long-winded way of saying that I'm not sure I know how I'd go about identifying "executables I should reasonably expect to have a man page" on my systems.
Re: [PLUG] something I am considering doing...
On Sun, 24 Mar 2024, American Citizen wrote: Paul: Thanks for your post. Exactly what would you consider a valid statement for locating the executables? Finding executable files is not, to my mind, the same as find executable files for which I'd expect a man page. I'd suppose expect a man page for most occupants of * /bin * /usr/bin * /usr/sbin * /sbin Some denizens of /usr/libexec might warrant man pages too. One problem is that a lot of files in /usr/bin are symlinks or wrapper scripts; I'm not sure there's any "right" way to deal with them. Another problem is utilities that are often superceded by shell builtin commands. Most people don't run /usr/bin/test; they use the shell builtin 'test' or '['. So a man page for /usr/bin/test might be deceptive if its operations are not identical with those of your shell. Yet another problem is with schemes like /etc/alternatives that map a common utility name to a specific release. Different distributions handle alternatives differently; I don't have a suse system, so you'd need to look at your own setup to see what alternatives can be set there. I guess this is my long-winded way of saying that I'm not sure I know how I'd go about identifying "executables I should reasonably expect to have a man page" on my systems. -- Paul Heinlein heinl...@madboa.com 45°22'48" N, 122°35'36" W
Re: [PLUG] something I am considering doing...
Paul: Thanks for your post. Exactly what would you consider a valid statement for locating the executables? Randall On 3/24/24 10:01, Paul Heinlein wrote: On Sat, 23 Mar 2024, American Citizen wrote: Paul: Good question from you. for executables I used $ find . -executable -print This is not a query I would expect to return accurate results because it will include files I would not consider candidates for man pages, including: * basic shared libraries ex: /usr/lib64/libsqlite3.so.0.8.6 * support scripts and libraries for interpreted languages ex: /usr/lib64/python3.11/smtpd.py * modules or subprograms for larger application suites ex: /usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/jpeg.so * example scripts ex: /usr/share/git-core/templates/hooks/pre-push.sample * files given +x bits probably by mistake ex (CentOS 8): /usr/share/licenses/gd/COPYING Even the most conscientious developer wouldn't write man pages for files in those categories.
Re: [PLUG] something I am considering doing...
On Sat, 23 Mar 2024, American Citizen wrote: Paul: Good question from you. for executables I used $ find . -executable -print This is not a query I would expect to return accurate results because it will include files I would not consider candidates for man pages, including: * basic shared libraries ex: /usr/lib64/libsqlite3.so.0.8.6 * support scripts and libraries for interpreted languages ex: /usr/lib64/python3.11/smtpd.py * modules or subprograms for larger application suites ex: /usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/jpeg.so * example scripts ex: /usr/share/git-core/templates/hooks/pre-push.sample * files given +x bits probably by mistake ex (CentOS 8): /usr/share/licenses/gd/COPYING Even the most conscientious developer wouldn't write man pages for files in those categories. -- Paul Heinlein heinl...@madboa.com 45°22'48" N, 122°35'36" W
Re: [PLUG] something I am considering doing...
To all readers: Maybe on determining missing man pages we should first define exactly what executables we mean? All ELF files? (not scripts?) etc? My initial determination was using strictly ELF files to look for the man pages from them Randall On 3/23/24 10:03, MC_Sequoia wrote: "I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%." I don't run Suze, but color me very suspicious. I did a quick Google search and found this thread about missing man pages. You might want to read through it. In summary, the user did a non-default install which was the cause of missing man pages. https://forums.opensuse.org/t/why-are-some-man-pages-missing/144164/8 -- Before relying on artificial intelligence to solve our problems, let's trying using intelligence first...
Re: [PLUG] something I am considering doing...
MC Sequoia I appreciate all the feedback I can get. Thank you for alerting me to this. Randall On 3/23/24 10:03, MC_Sequoia wrote: "I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%." I don't run Suze, but color me very suspicious. I did a quick Google search and found this thread about missing man pages. You might want to read through it. In summary, the user did a non-default install which was the cause of missing man pages. https://forums.opensuse.org/t/why-are-some-man-pages-missing/144164/8 -- Before relying on artificial intelligence to solve our problems, let's trying using intelligence first...
Re: [PLUG] something I am considering doing...
Robert:
As I am reading the replies back to the forum, now I come on your 2nd email
Thank you for this post.
I am going try to implement your script at the root level and see what
comes up
Randall
On 3/23/24 09:21, Robert Citek wrote:
I ask because I get very different results.
<<< ${PATH} tr : '\n' |
while read folder ; do
echo == ${folder}
find ${folder}/ -type f -executable |
rev |
cut -d / -f1 |
rev |
xargs -t -n1 man -w 2>&1 |
cat -n
done |
tee /tmp/file.list.man.txt
$ wc -l /tmp/file.list.man.txt
2863 /tmp/file.list.man.txt
$ grep -c 'No manual' /tmp/file.list.man.txt
114
$ echo $(( 114*1000/( 2863 / 2 ) ))
79
Using the above method, fewer than 8% do NOT have manual pages, i.e. 92% do
have man pages, which exceeds your original estimate of 50-75%. If nothing
else, it's a much smaller problem space for your AI project.
Regards,
- Robert
On Sat, Mar 23, 2024 at 9:48 AM Robert Citek wrote:
On Fri, Mar 22, 2024 at 6:04 PM American Citizen <
website.read...@gmail.com> wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so
and ran a check on the documentation such as the man1 through man9 pages
(run the %man man command to pull all this up) versus the actual
executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
Can you provide data to back up that assertion? For example, a script.
Regards,
- Robert
Re: [PLUG] something I am considering doing...
Robert
wow, asking me to start from scratch again
1. file . -executable -print (at root level with root permissions)
2. type {file names found} and save only the ELF executables
3. man executable name
This in short is what I did
Please be aware that 10,000's of executables will come up.
Randall
On 3/23/24 08:48, Robert Citek wrote:
On Fri, Mar 22, 2024 at 6:04 PM American Citizen
wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so
and ran a check on the documentation such as the man1 through man9 pages
(run the %man man command to pull all this up) versus the actual
executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
Can you provide data to back up that assertion? For example, a script.
Regards,
- Robert
Re: [PLUG] something I am considering doing...
Paul:
Good question from you.
for executables I used
$ find . -executable -print
at the root level "/" on my hard drive hosting the linux OS (using root
permissions)
Then I had to filter these by doing a
file {found name} to actually narrow to the executable
Example:
localhost:/home/owner/math/Diophantine/m-tuples # file nex
nex: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=a51414fed84b7f7c3229756342b3ae0b30abc182, for GNU/Linux
3.2.0, with debug_info, not stripped
I only consider the ELF executable as the actual file which needed
documentation.
Hope this answers your question?
Randall
On 3/23/24 08:24, Paul Heinlein wrote:
On Fri, 22 Mar 2024, American Citizen wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or
so and ran a check on the documentation such as the man1 through man9
pages (run the %man man command to pull all this up) versus the
actual executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
If I am going to talk to an AI program, such as ChatBot or one of the
newer popular AI program and ask it to generate the documentation for
the complete OS, what AI chatbot would you choose?
My idea is to clue the AI program into the actual OS, then ask it to
finish documenting 100% of all the executables, or report to me all
executables which have no available documentation at all, period.
I'd be interested to know your definition of "command executables." Is
it everything in /bin, /usr/bin, /sbin, and /usr/sbin, with perhaps
/usr/libexec thrown in for good measure? If not, can you provide your
criteria for inclusion?
Presumably, you ruled out all hard and symbolic links, and you
accounted for documentation in Texinfo format, not just man pages.
I have no hands-on AI experience, but I do offer couple alternative
strategies that might assist:
First, try invoking each executable with common help options: -h,
--help, -?, or even 'help' itself. If there's good output, I suspect
you could pipe it into txt2man or a similar utility to generate a
basic man page.
Second, on rpm-based systems, the package might catalog other
documentation (likely, but not necessarily, in /usr/share/doc). The
shell-ish logic to unwrap this might be something like
for PROG in /usr/bin/* /usr/sbin/*; do
# rule out symlinks, though this is debatable
if test -L $PROG; then continue; fi
# see if rpm thinks a package owns $PROG
PKG=$(rpm -qf $PROG 2>/dev/null)
# if so, do a cursory look for documentation
if test -n "$PKG"; then
rpm -qd $PKG | grep -i $PROG
fi
done
The "grep" in there might be a bit limiting, but "rpm -qd" can be
quite verbose for some packages. Season to taste.
Re: [PLUG] something I am considering doing...
On Saturday, March 23rd, 2024 at 9:57 AM, Galen Seitz wrote: > On 3/23/24 00:55, Ben Koenig wrote: > > > Ideally, the whole point of an LLM is to create a problem that can > > interpret human language so that we can interact with software in a > > "human" way. It shouldn't matter if the data is garbage, as long as > > the result is a program that understands english. > > > > Once you have that, you can point it to a random pile (list of > > websites, source code repository) of information that you know is > > mostly decent, and it will go through the long and painful process of > > dissecting it for you. This only works if the LLM is capable of doing > > this without mixing in all of its childhood memories. You know, like > > we do - we all spent a lot of time engaging in really stupid > > conversations that were only intended to practice listening and > > speaking. As adults we throw the subject matter from that phase away, > > retaining the grammar and sentence structure. We don't really care > > about that time a fox jumped over a lazy dog. > > > I'm missing JJJ already. He would definitely have something to say > about this, but I have no idea what it would be. And that's not meant > as a criticism Ben, just that JJJ always provided an interesting > perspective when it came to matters of language. > > galen > -- > Galen Seitz > gal...@seitzassoc.com Yeah, linguistics was his thing. Right now "AI" is really just about the interpretation and manipulation of human language. It's an aread of computer science people have already been working on for decades and I'm sure JJJ would have seeen some really fun edge cases when it comes to the stuff chatGPT is saying. -Ben
Re: [PLUG] something I am considering doing...
"I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%." I don't run Suze, but color me very suspicious. I did a quick Google search and found this thread about missing man pages. You might want to read through it. In summary, the user did a non-default install which was the cause of missing man pages. https://forums.opensuse.org/t/why-are-some-man-pages-missing/144164/8 -- Before relying on artificial intelligence to solve our problems, let's trying using intelligence first...
Re: [PLUG] something I am considering doing...
On 3/23/24 00:55, Ben Koenig wrote: Ideally, the whole point of an LLM is to create a problem that can interpret human language so that we can interact with software in a "human" way. It shouldn't matter if the data is garbage, as long as the result is a program that understands english. Once you have that, you can point it to a random pile (list of websites, source code repository) of information that you know is mostly decent, and it will go through the long and painful process of dissecting it for you. This only works if the LLM is capable of doing this without mixing in all of its childhood memories. You know, like we do - we all spent a lot of time engaging in really stupid conversations that were only intended to practice listening and speaking. As adults we throw the subject matter from that phase away, retaining the grammar and sentence structure. We don't really care about that time a fox jumped over a lazy dog. I'm missing JJJ already. He would definitely have something to say about this, but I have no idea what it would be. And that's not meant as a criticism Ben, just that JJJ always provided an interesting perspective when it came to matters of language. galen -- Galen Seitz gal...@seitzassoc.com
Re: [PLUG] something I am considering doing...
I ask because I get very different results.
<<< ${PATH} tr : '\n' |
while read folder ; do
echo == ${folder}
find ${folder}/ -type f -executable |
rev |
cut -d / -f1 |
rev |
xargs -t -n1 man -w 2>&1 |
cat -n
done |
tee /tmp/file.list.man.txt
$ wc -l /tmp/file.list.man.txt
2863 /tmp/file.list.man.txt
$ grep -c 'No manual' /tmp/file.list.man.txt
114
$ echo $(( 114*1000/( 2863 / 2 ) ))
79
Using the above method, fewer than 8% do NOT have manual pages, i.e. 92% do
have man pages, which exceeds your original estimate of 50-75%. If nothing
else, it's a much smaller problem space for your AI project.
Regards,
- Robert
On Sat, Mar 23, 2024 at 9:48 AM Robert Citek wrote:
>
> On Fri, Mar 22, 2024 at 6:04 PM American Citizen <
> website.read...@gmail.com> wrote:
>
>> A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so
>> and ran a check on the documentation such as the man1 through man9 pages
>> (run the %man man command to pull all this up) versus the actual
>> executables on the system.
>>
>> I was surprised to find < 15% of the command executables were
>> documented. Naturally I was hoping for something like 50% to 75%.
>
>
> Can you provide data to back up that assertion? For example, a script.
>
> Regards,
> - Robert
>
>
>
>
>
>
>
>
Re: [PLUG] something I am considering doing...
On Fri, Mar 22, 2024 at 6:04 PM American Citizen wrote: > A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so > and ran a check on the documentation such as the man1 through man9 pages > (run the %man man command to pull all this up) versus the actual > executables on the system. > > I was surprised to find < 15% of the command executables were > documented. Naturally I was hoping for something like 50% to 75%. Can you provide data to back up that assertion? For example, a script. Regards, - Robert
Re: [PLUG] something I am considering doing...
On Fri, 22 Mar 2024, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. I'd be interested to know your definition of "command executables." Is it everything in /bin, /usr/bin, /sbin, and /usr/sbin, with perhaps /usr/libexec thrown in for good measure? If not, can you provide your criteria for inclusion? Presumably, you ruled out all hard and symbolic links, and you accounted for documentation in Texinfo format, not just man pages. I have no hands-on AI experience, but I do offer couple alternative strategies that might assist: First, try invoking each executable with common help options: -h, --help, -?, or even 'help' itself. If there's good output, I suspect you could pipe it into txt2man or a similar utility to generate a basic man page. Second, on rpm-based systems, the package might catalog other documentation (likely, but not necessarily, in /usr/share/doc). The shell-ish logic to unwrap this might be something like for PROG in /usr/bin/* /usr/sbin/*; do # rule out symlinks, though this is debatable if test -L $PROG; then continue; fi # see if rpm thinks a package owns $PROG PKG=$(rpm -qf $PROG 2>/dev/null) # if so, do a cursory look for documentation if test -n "$PKG"; then rpm -qd $PKG | grep -i $PROG fi done The "grep" in there might be a bit limiting, but "rpm -qd" can be quite verbose for some packages. Season to taste. -- Paul Heinlein heinl...@madboa.com 45°22'48" N, 122°35'36" W
Re: [PLUG] something I am considering doing...
On Fri, 22 Mar 2024, Russell Senior wrote: To me, the only open question is whether humans get stupider faster than the machines. Isn't that why the search for extraterrestrial intelligence has been going on for so many decades? Rich
Re: [PLUG] something I am considering doing...
Ideally, the whole point of an LLM is to create a problem that can interpret human language so that we can interact with software in a "human" way. It shouldn't matter if the data is garbage, as long as the result is a program that understands english. Once you have that, you can point it to a random pile (list of websites, source code repository) of information that you know is mostly decent, and it will go through the long and painful process of dissecting it for you. This only works if the LLM is capable of doing this without mixing in all of its childhood memories. You know, like we do - we all spent a lot of time engaging in really stupid conversations that were only intended to practice listening and speaking. As adults we throw the subject matter from that phase away, retaining the grammar and sentence structure. We don't really care about that time a fox jumped over a lazy dog. I've actually been fiddling with package management for ROCm in Slackware so at some point I'm going to try and fire up some sort of ML or LLM app to verify that it all works. At that point I'll be taking a look at the various options for building your own model since I'm working on a project that would be an interesting use case for LLMs. -Ben On Friday, March 22nd, 2024 at 5:57 PM, American Citizen wrote: > Okay, I get it, that AI is as only good as the input and if it is fed > garbage, it can only spout garbage > > (wish that there was someway to clue the investors into this fact) > > > On 3/22/24 17:51, Russell Senior wrote: > > > On 3/22/24 17:39, Ben Koenig wrote: > > > > > On Friday, March 22nd, 2024 at 5:04 PM, American Citizen > > > website.read...@gmail.com wrote: > > > > > > > A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so > > > > and ran a check on the documentation such as the man1 through man9 > > > > pages > > > > (run the %man man command to pull all this up) versus the actual > > > > executables on the system. > > > > > > > > I was surprised to find < 15% of the command executables were > > > > documented. Naturally I was hoping for something like 50% to 75%. > > > > > > > > If I am going to talk to an AI program, such as ChatBot or one of the > > > > newer popular AI program and ask it to generate the documentation for > > > > the complete OS, what AI chatbot would you choose? > > > > > > > > My idea is to clue the AI program into the actual OS, then ask it to > > > > finish documenting 100% of all the executables, or report to me all > > > > executables which have no available documentation at all, period. > > > > > > > > This means the AI program would scour the internet for any and all > > > > documentation for each command, and there are 10,000's of > > > > executables to > > > > examine. (which is why I believe this is an AI task) > > > > > > > > Your thoughts? > > > > > > > > - Randall > > > > That would be an interesting experiment to see what it comes up with. > > > > I would question the results simply due to the quality of current LLM > > > > implementations. > > > > > > From recent anecdotal experience, I recently bought an expensive > > > Logitech keyboard and it was behaving strangely so I tried to look up > > > how to perform a "factory reset" for this model. The search results I > > > found via DDG were interesting, there were multiple duplicate hits > > > for what appeared to be a tech blog with generic instruction pages > > > for my device. However there were multiple iterations of this page, > > > for this keyboard model, each of which had instructions referencing > > > physical features that do not exist on this actual keyboard. These > > > appeared to be AI generated help pages that were clogging up actual > > > search results. They were very well written, If I hadn't had the > > > actual device in front of my I might have actually believed that > > > there was a pinhole reset button next to the USB port. > > > > > > If you do this, you may need to find a way to define a "web of trust" > > > that allows the AI to differentiate between human written articles, > > > and AI written summaries. As it is right now, you might find yourself > > > telling an AI to summarize help pages that are AI written summaries of > > > AI written summaries of ( > > > AI written summaries of ( > > > AI written summaries of ( > > > AI written summaries of (actual manuals) > > > ) > > > ) > > > ) > > > > > > Recursion FTW! :) > > > > It seems inevitable that the AI serpent will stupidly eat its tail and > > devolve into even more of a stochastic septic tank than it is now. If > > I was an investor, I would be shorting hard into the AI bubble. To me, > > the only open question is whether humans get stupider faster than the > > machines.
Re: [PLUG] something I am considering doing...
Okay, I get it, that AI is as only good as the input and if it is fed garbage, it can only spout garbage (wish that there was someway to clue the investors into this fact) On 3/22/24 17:51, Russell Senior wrote: On 3/22/24 17:39, Ben Koenig wrote: On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. From recent anecdotal experience, I recently bought an expensive Logitech keyboard and it was behaving strangely so I tried to look up how to perform a "factory reset" for this model. The search results I found via DDG were interesting, there were multiple duplicate hits for what appeared to be a tech blog with generic instruction pages for my device. However there were multiple iterations of this page, for this keyboard model, each of which had instructions referencing physical features that do not exist on this actual keyboard. These appeared to be AI generated help pages that were clogging up actual search results. They were very well written, If I hadn't had the actual device in front of my I might have actually believed that there was a pinhole reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) It seems inevitable that the AI serpent will stupidly eat its tail and devolve into even more of a stochastic septic tank than it is now. If I was an investor, I would be shorting hard into the AI bubble. To me, the only open question is whether humans get stupider faster than the machines.
Re: [PLUG] something I am considering doing...
Ben: You have touched on something very important here. For example I bought a brand new Logitech headphone, but suddenly found that my openSuse linux system could not support the acoustic dB volume that I was accustomed to in the past. An arduous search showed that the OS was not in sync with the newer Logitech firmware code for that headset. I had to play around sometime before I found a setting which restored the original volume levels. Please understand that Logitech was a bit on the defensive when I originally contacted them explaining my difficulties. I am not sure that the average person would have been able to satisfactorily resolve this. The key idea here is "web of trust". Randall On 3/22/24 17:39, Ben Koenig wrote: On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. From recent anecdotal experience, I recently bought an expensive Logitech keyboard and it was behaving strangely so I tried to look up how to perform a "factory reset" for this model. The search results I found via DDG were interesting, there were multiple duplicate hits for what appeared to be a tech blog with generic instruction pages for my device. However there were multiple iterations of this page, for this keyboard model, each of which had instructions referencing physical features that do not exist on this actual keyboard. These appeared to be AI generated help pages that were clogging up actual search results. They were very well written, If I hadn't had the actual device in front of my I might have actually believed that there was a pinhole reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) -Ben
Re: [PLUG] something I am considering doing...
On 3/22/24 17:39, Ben Koenig wrote: On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. From recent anecdotal experience, I recently bought an expensive Logitech keyboard and it was behaving strangely so I tried to look up how to perform a "factory reset" for this model. The search results I found via DDG were interesting, there were multiple duplicate hits for what appeared to be a tech blog with generic instruction pages for my device. However there were multiple iterations of this page, for this keyboard model, each of which had instructions referencing physical features that do not exist on this actual keyboard. These appeared to be AI generated help pages that were clogging up actual search results. They were very well written, If I hadn't had the actual device in front of my I might have actually believed that there was a pinhole reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) It seems inevitable that the AI serpent will stupidly eat its tail and devolve into even more of a stochastic septic tank than it is now. If I was an investor, I would be shorting hard into the AI bubble. To me, the only open question is whether humans get stupider faster than the machines. -- Russell
Re: [PLUG] something I am considering doing...
On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: > A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so > and ran a check on the documentation such as the man1 through man9 pages > (run the %man man command to pull all this up) versus the actual > executables on the system. > > I was surprised to find < 15% of the command executables were > documented. Naturally I was hoping for something like 50% to 75%. > > If I am going to talk to an AI program, such as ChatBot or one of the > newer popular AI program and ask it to generate the documentation for > the complete OS, what AI chatbot would you choose? > > My idea is to clue the AI program into the actual OS, then ask it to > finish documenting 100% of all the executables, or report to me all > executables which have no available documentation at all, period. > > This means the AI program would scour the internet for any and all > documentation for each command, and there are 10,000's of executables to > examine. (which is why I believe this is an AI task) > > Your thoughts? > > - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. >From recent anecdotal experience, I recently bought an expensive Logitech >keyboard and it was behaving strangely so I tried to look up how to perform a >"factory reset" for this model. The search results I found via DDG were >interesting, there were multiple duplicate hits for what appeared to be a tech >blog with generic instruction pages for my device. However there were multiple >iterations of this page, for this keyboard model, each of which had >instructions referencing physical features that do not exist on this actual >keyboard. These appeared to be AI generated help pages that were clogging up >actual search results. They were very well written, If I hadn't had the actual >device in front of my I might have actually believed that there was a pinhole >reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) -Ben
[PLUG] something I am considering doing...
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall
