Re: [PLUG] trying to satisfy everyone's critiques on missing man pages for executables
Try this:
for i in $(echo $PATH | awk 'BEGIN { RS=":" } { print $0 }') ; do find $i
-type f -executable -print0 | xargs -0 file ; done | grep ELF | sort | uniq
| less
I got about 2000 lines.
On Sat, Mar 23, 2024 at 10:16 PM American Citizen
wrote:
> I am attempting to provide enough information on the missing man pages,
> so I spent about 3 hours this evening on this.
>
> I have a linux OpenSuse Leap 15.5 linux system. Running the zipper list
> shows 7,443 installed programs for the software respositories
>
> Here's the results of my investigations tonight
>
> > Bash script files:
> >
> > 1. find . -name * -type executable -print > exefiles
> >(resulted in a file with 653,455 lines) (done at root location
> > using root permission)
> >
> > 2. executing this bash script
> >file {"name"} > exefiles.1
> >
> > NOTE: It took about 2 hours of work to get the bash script to
> > successfully complete due to unusual characters in the file name such
> > as pipe quotes tilde, etc. which kept blowing up the script file.
> >
> > 3. Selecting only ELF files from the file run creating exefiles.1
> created:
> >
> > 37604 633501 8644870 exefiles.2
> >
> > 4. Carefully trimming the file narrowed to 18,068 executables (ELF-64)
> >
> >18068 36157 420729 exefiles.3
> >
> > 5. There were actually only 14,383 unique file names, so obviously the
> > same executables are sprinkled on the whole hard disk in various folders.
> >
> >localhost:/ # sort -u exefiles.3 | wc
> > 14383 28775 328072
> >
> > 6. Run "man filename" on the exefiles.3 file results in
> >
> >localhost:/ # wc exefiles.4
> > 668085 5045286 39216490 exefiles.4
> >
> >which consists of quite some script lines for certain man pages.
> >
> > However checking "No manul entry for {executable}" results in
> >
> >15,120 lines
> >
> > This is 15120/18068 or 83.686% missing
> >
> > I hope that this satisfies everyone's criteria
> >
> We are missing lots of man information at least on my machine. (and I
> strongly suspect this is true of yours too)
>
> Randall
>
>
>
[PLUG] Brave Browser Video Issue
I've just run the latest updates from Ubuntu for my Xubuntu machines, which included Brave browser. In each case, video does no longer display. Audio works, and is the audio for the video I'm trying to watch. I can successfully watch the same URL with Firefox, so I'm assuming something went wrong with the Brave update. And it appears that they've heard from other folks, because I just had another update notice that included Brave. After running that, video works again. If it happened to you, wait a bit and try again. It will probably fix itself. -- Regards, Dick Steffens
[PLUG] trying to satisfy everyone's critiques on missing man pages for executables
I am attempting to provide enough information on the missing man pages,
so I spent about 3 hours this evening on this.
I have a linux OpenSuse Leap 15.5 linux system. Running the zipper list
shows 7,443 installed programs for the software respositories
Here's the results of my investigations tonight
Bash script files:
1. find . -name * -type executable -print > exefiles
(resulted in a file with 653,455 lines) (done at root location
using root permission)
2. executing this bash script
file {"name"} > exefiles.1
NOTE: It took about 2 hours of work to get the bash script to
successfully complete due to unusual characters in the file name such
as pipe quotes tilde, etc. which kept blowing up the script file.
3. Selecting only ELF files from the file run creating exefiles.1 created:
37604 633501 8644870 exefiles.2
4. Carefully trimming the file narrowed to 18,068 executables (ELF-64)
18068 36157 420729 exefiles.3
5. There were actually only 14,383 unique file names, so obviously the
same executables are sprinkled on the whole hard disk in various folders.
localhost:/ # sort -u exefiles.3 | wc
14383 28775 328072
6. Run "man filename" on the exefiles.3 file results in
localhost:/ # wc exefiles.4
668085 5045286 39216490 exefiles.4
which consists of quite some script lines for certain man pages.
However checking "No manul entry for {executable}" results in
15,120 lines
This is 15120/18068 or 83.686% missing
I hope that this satisfies everyone's criteria
We are missing lots of man information at least on my machine. (and I
strongly suspect this is true of yours too)
Randall
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] SWAP size based on host's installed memory
On Sat, 23 Mar 2024, Johnathan Mantey wrote: Did I miss the definition of SAR? System Activity Report. On my Slackware desktop it's in /user/bin/sar. man page available, too. HTH, Rich
[PLUG] Death Notice / Unsubscribe
First: My brother, John Jeddeloh, was found deceased in his home January 14. He was known on this list as "John Jason Jordan." From his computer files it looks like he has been active here for many years. I have even found boxes with meeting posters dating back to 2013. Second: I need to unsubscribe 'joh...@gmx.com' from this list. Somebody please help. Third: Frankly, I was quite surprised to find he was running Linux on all his computers. I was last able to contact him 27 years ago, and he was running early word-processing systems at that time. Personally, I first started using Unix at Tektronix back ca. 1980 and the Usenet days, and continued through my retirement, lastly working on DSL, Cable, Ethernet, and Fiber-to-the-Hut home gateways. However, as to how I am on this account: Pro Tip: a) Use a password manager. Share the master password with a trusted family member or close friend, or leave it in a safe deposit box, or with you lawyer and a copy of you will. b) Have a will while we're at it. c) Encrypt your hard drives, and d) Don't leave a Debian live thumb drive on you desk next to your laptop. It can be trivially easy for someone to break into the BIOS to boot the thumb drive, clear the password on an account, then reboot the system and log into the account without a password. This not only works for the guy administering your estate, but also the guy you steals your laptop from the coffee shop. -Alan Jeddeloh Personal Representative, Estate of John Jeddeloh arjedde...@gmail.com
Re: [PLUG] Making a bootable thumb drive [FIXED]
On Sat, 23 Mar 2024, Rich Shepard wrote: Why sdg has two partitions I don't know. My question is to which device name I point dd's of=? /dev/sdg or /dev/sdg1. Or should I use cfdisk to re-partition the drive? Never mind. I ran `dd if=usbboot.img of=/dev/sdg and I now again have a bootable drive. Rich
[PLUG] Making a bootable thumb drive
For some reason the bootable thumb drive I made (for Slackware64-15.0) now asks to load PXE to install over the network rather than from the flash drive itself. I have the usbboot.img file and the flash drive is seen by the kernel: Mar 23 11:04:35 salmo kernel: [246888.820945] sdg: sdg1 sdg2 Mar 23 11:04:35 salmo kernel: [246888.827498] sd 10:0:0:0: [sdg] Attached SCSI removable disk Mar 23 11:04:55 salmo kernel: [246909.135961] FAT-fs (sdg1): Can't find a valid FAT filesystem Mar 23 11:04:59 salmo kernel: [246913.165744] FAT-fs (sdg): Can't find a valid FAT filesystem Why sdg has two partitions I don't know. My question is to which device name I point dd's of=? /dev/sdg or /dev/sdg1. Or should I use cfdisk to re-partition the drive? TIA, Rich
Re: [PLUG] SWAP size based on host's installed memory
On Sat, 23 Mar 2024, Michael Ewan wrote: Some swap is necessary but not the RAM+2GB or other calculations, those kinds of recommendations are based on very old memory management routines. You can start with a swap file for safety and then measure actual memory use under actual work loads over a period of time, you can add/remove swap files as necessary rather than creating a swap partition (look at the swapon man page). Using SAR you can get all the information you need. Ages ago when we were sizing some big iron we ran SAR over a period of time and sized the RAM (very expensive at the time) so the machine NEVER paged out. Paging stats are far more important than swap stats, a machine pages all the time but should never swap, swapping is very expensive and indicates a machine that has pathetically small RAM. You will probably see some page outs (page in is fine since starting a process is a page in), so you can size your swap space based on the paging needs of the current configuration. Michael, Thanks for makeing me aware of SAR. Germene to all swap partition size justifications might the solution be relative to use and memory size alone? If a host can support 16GiB (e.g., on a laptop) or 64GiB (on a desktop) but there's only one or a few concurrent users I wonder whether any swap partition would be necessary. Perhaps running a spatio-temporal statistical or multi-dimentional hydraulic model might require a lot of memory (unless it supports threads, which most do nowadays) might benefit from a swap partition. And then, most storage devices (hdds and ssds) are large enough that a swap partition of installed RAM plus 2 GiB would not hinder application and data storage space. Regards, Rich
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
>
>
>
>
>
>
>
>
[PLUG] Off Topic:TV Station (in Eugene, OR!) Launches Multiple 4K Broadcasts OTA on ATSC 1.0
TV Station (in Eugene, OR!) Launches Multiple 4K Broadcasts OTA on ATSC 1.0 "https://iv.datura.network/watch?v=e_94q9TCCDY;
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.
