that's why my perceived solution was to install and run from some linux-OS-of-the-90s. I chose RH6.2, which was very popular in those days. But after D/l-ing <RH6.2.iso> failed to get a RH6.2 installation running on my laptop/s. -What didi do wrong ?
On Mon, Nov 16, 2020 at 9:16 AM <[email protected]> wrote: > On Mon, Nov 09, 2020 at 11:49:46AM +0000, Aaron Sloman wrote: > > I had been running an old kernel (5.6.6) in order to be able to use ved > as > > my main editor. It works in both 32bit and 64bit poplog. > > > > I wondered what would happen if I tried to run the old 32bit poplog in > the > > latest (5.8) kernel. So I have just rebooted into fedora32 with kernel > > > > 5.8.11-200.fc32.x86_64 > > > > and tried running both 32 bit and 64 bit poplog. > > > > The result seems to confirm Waldek's hypothesis about what's going on: > > Neither new nor old poplog will run: I just get a stream of error > messages. > > > > ;;; MISHAP - ste: STACK EMPTY (missing argument? missing result?) > > > > (the first error message goes off the screen too fast, so I don't know > > how it starts). > > This was expected but thanks for confirmation. > > > I wonder if this is fixable, or whether the new kernel changes make > poplog > > unusable. > > > > If a new test version of poplog becomes available I would be willing to > try > > it, but I don't think I can do anything to help identify the details of > > the problem. > > > > I presume Linus Torvalds, or whoever has made this change would > > not be willing to provide a mechanism to enable self-modifying code, like > > Poplog's to be run. > > > > I wonder if there are any other systems that have been made unusable. > > There is good chance that there is some configuration parameter to > enable old behaviour (to run programs like Poplog). Simply, ATM > we lack info. We do not know exact reason for fault. We do not > know if this is general 5.8 thing or (more likely) Fedora thing. > We do not know if this is really kernel change or say configuration > change that is somewhat tied to the kernel (say buch of configuration > changes with some dependent of kernel features). > > To put it differently, most guesses about software problems are > wrong. Here there are several factors involved, so chance > of resolving problem without digging deeper is virtually 0. > > -- > Waldek Hebisch > >
