Subj : Too many? :) To : Ky Moffet From : Barry Martin Date : Fri Sep 25 2020 09:13:00 Hi Ky! > Yes, didn't know there were so many variations out there! KM> Since I've been paying attention it's mushroomed, tho most fade KM> away unremarked and unlamented. Yes, I suppose rather easy as modify to my preferences, I think it's the latest and greatest so publish. A few people, mostly relatives and friends trying to be supportive try it but otherwise doesn't take off, KM> There used to be a catalog of all the Puppy variants... over KM> 2000!! That number seems like more than the number of actual dog breeds! > As for the listing, I was thinking a separate file, not a tree output. KM> Oh, but the Tree output tells me where it is on disk... occurs to KM> me, tho (this is your fault) that I could print out the Big KM> Family Tree (how much paper, again?) and mark the branches I've KM> tried... nah, sounds like work. If you use a teen-tiny you should get it to fit on a single sheet! As for marking, maybe could still do it on computer: create a file with a name forcing it to the top/beginning of the tree branch list. I've used "aa_" if I want a force a file's location. Thinking of the Recipes subdir I have (and honestly intended to use!): /home/barry/File Cabinet/Recipes/ |-- aa_Cooking Tips |-- aa_Food Timeline | |-- Food Timeline: food history research service_files | |-- aa_Substitutions - Ingredient |-- aa_Unit Conversions |-- Appetizers |-- BBQ | |--Sauce Prefacing the 'aa_' forces the Cooking Tips subdir towards the top. You'll have to test how it works with numbers, if any listing has numbers, or even non alphanumeric characters > KM> circuit. Then I want to FIND it! Or in one case, when one of our > KM> number on the PCLOS forum wanted to see an obscure spin, I proved > KM> to have the last remaining copy (now on archive.org). > Horray! Would have thought someone else to have had a copy, but suppose > easy enough to be lost when a computer dies, the person dies..... KM> Or in this case, vanished from the various FTPs, probably cuz Tex KM> (or whoever does this for him) did one of his periodic trawls to KM> get rid of outdated editions. Which I disagree with, see above. In the old days storage space was at a premium so the culling sort of made sense. Now, not so much, so just move to that Old Stuff directory. KM> In this case ... someone had done a nice implementation of KM> Cinnamon on PCLOS, and seemed like it would make a good regular KM> spin... recommended it to our Spin Doctor for updating, but then KM> no one could find a copy online. Darn misspellings! (Y'mean it's not 'Sinahmum'?) > KM> I have dozens, perhaps hundreds of directories named Stuff... or > KM> sometimes !Stuff... sometimes both.... > I try to be a little more descriptive but doesn't always work. I do > have a few variations on 'temporary'! KM> That too!! Let's see: Temporary |-- A lot of Stuff |-- More stuff |-- Other stuff Oo! Linux is case-sensitive!! Temporary |-- a lot of stuff |-- a lot of Stuff |-- more stuff |-- More stuff |-- More Stuff > KM> I actually tried doing something like that when I did the first > KM> big trawl looking for a distro to love... printed out a Wikipedia > KM> list with ancestors and last-update and whatever else was on the > KM> chart. Not sure it accomplished anything but it did waste about > KM> 10 sheets of paper. :) > The backs of which can be used for scratch paper! KM> Too late, I printed it on scratch paper (Wound up wishing I KM> had more scribble space!) Scotch tape pieces of smaller scratch paper to the original large sheet of scratch paper! (Back in my college days, way before home computers were common, I did a term paper, editing with the literal cut and paste: the draft was very lumpy.) > KM> Yeah, did a lot of columns and tables in WordPerfect for that > KM> kind of thing... nowadays I mostly don't care. > I sometimes create a sort-of spreadsheet to compare items for purchase: > helps determine which one is better (for my needs) as the listings don't > always have everything together much less in the same order. KM> Good idea, tho I rarely buy anything that needs such close KM> comparison. My usage isn't so much comparison as it is to figure out. I guess more to organize notes. This one comes with <_A_>, this other one comes with <_B_> which is like <_A_> but with <_c_> added. > KM> Yes! this is where I rebooted my brain!! > Things really got equalized! KM> BEEP BEEP You're either backing up or if you're AMI havign a memory parity check error! > > KM> So there's finally a KDE-on-Debian that at least looks decent > > KM> live. Let's try that... if we can figure out the damn > > KM> partitioner. Not sure what took it so long but it didn't actually > > KM> do anything; here's Mageia's /home still intact (well, at least I > > KM> didn't have to redo my KDE settings), in part because it wouldn't > > KM> let me change it. Two hours later it's finally installed.... at > > KM> first it was really sluggish; seems to have gotten better. > > Doing an automatic backup of some sort? Creating a journal? > KM> Dunno... didn't see anything happening... > Happened to think of that option as my laptop will seem sluggish and > it's doing a backup. No real way to tell until it's done. Suppose > could look in System Monitor; otherwise just note the HDD LED is > flashing like mad. KM> In this case, no blinkenlights. No nothing. No idea what it was KM> doing, since I couldn't really see anything happening in the file KM> manager, and htop wasn't part of the default install. (Dunno what KM> else might tell me what's running and being a hog. But that's an KM> awful lot of hardware to be hogging.) Maybe it's being sneaky and you're catching it only when it's thinking, so no read-write activity. > > The problem might be your slow data line. I have done a > KM> Actually, no. Even not counting that, it still took just over an > KM> hour. > So much for that excuse! ...No other guesses coming to mind. ...Noisy > line and have to resend data? KM> Nope. Line is now clean, after CLink guy was here and messed with KM> it. No more stalls and back to previous speed. Well that's good. > KM> Today's experiment is OpenSuSE/Gecko (Rolling) with KDE. It > KM> sensibly does all the config stuff up front, so no halts in > KM> mid-stream that need attention, but so far it's taken two hours > KM> and is only to 91%, and far as I can tell it's not downloading KM> Also was not impinging on bandwidth on the other PC. Easy check. > KM> anything (even if it is, it should have long since been done, > KM> with very little to do as this is a current ISO, with no huge > KM> recent updates that I know of). "Removing one package" -- what's > KM> that about?? > I remember having couple hour long update sessions but seems those were > with the older Raspberry Pi's, plus going from NOOBS to current, so tons > of little files to be updated. Using a current ISO can still have lots KM> Well, Rasbian IS based on Debian.... True... > of updates, even adding new (ISO provides a generic to get things going, > checks for, downloads and installs a specific file set).... As for > 'removing one package', something old, something new, something borrowed > -- oh wait, that's not the right one! KM> I dunno, we're confused! Back a couple years ago I noticed it seemed when LibreOffice and Mozilla stuff was being updated they actually downloaded the entire version rathet than just the new files. Possibly everything as changed, though more likely to ensure no old files to screw up the works. > KM> Oh goodie, it's finally done! now let's see if it'll boot (live > KM> SuSE fails about 2 times out of 3).... Well, it > KM> finally got past the splash screen, but now we have a blank > KM> monitor.... eventually I lost patience and did C-A-D... now I > KM> have a mouse cursor... if it's cooking an Nvidia driver in the > KM> background, it needs to show me that (normally you can hit ESC > KM> and see what's going on)... shouldn't take this long anyway... > Let's see: semi-random stuff coming to mind. I did have problems with > installation when I had that bad RAM stick, so run the extended MEM86 > test (it passed the quick/default option. There were times I actually > got into the Install steps (never would do direct install, always want > to the trial). KM> Nothing wrong with this hardware; it runs a dozen other OSs just KM> fine. Windows is a pretty good canary in the coal mine for bad KM> hardware, and it loves that PC. Also moved the install to an KM> older and more generic PC... no change. Some sort of sneaky incompatibility. ...You got "ARM" instead of "AMD". It's 64-bit instead of 32-bit (should have a warning message). > Is 'nomodeset' in the install options? Read somewhere that's now causing > problems. May have been with a tiny resolution; do recall one of the > suggested fixes I read about when I could get Ubuntu to install because > (of the faulty RAM) was to use nomodeset. KM> No idea... resolution looked normal. If an installer sets KM> something dopey, tho... probably breaks other stuff. Out with KM> you! nomodeset came to mind because when I was having troubles with the installation due to the faulty RAM it came up numerous times as a potential work-around; a few days ago in the MythTV Forum with nVidia drivers. > KM> And about the time I got done typing that, it decided to actually > KM> do a shutdown and power-off. > Some sort of 'saving last state'? KM> Shouldn't be, wasn't live, and when live I never use persistence. I'm thinking "returning stuff to the original state" but it seems like nothing should be modified other than possibly a small workspace. > functions do take along time: there's a comment in an older MythTV > Installation Guide at a certain step to go away and get a cup of coffee > as the step took a very long time (and appears as if nothing is > occurring). ...When I was trying to use a 64 GB card with MotionEye it > took around ten minutes to complete the 'expanding partition' step (on > an RPi 3B+). That's the one that only like up to 32 GB -- same step > takes about a minute. KM> Only thing I can think might be similar -- having trouble with KM> 64GB RAM. However... the Red Hat family (broadly including the KM> Mandrake cousins) has no problem with it, and that should be a KM> kernel function anyway, and it's not like the kernel is that KM> different from one version to the next ... and a given kernel is KM> the same across distros. And if Debian with its 3 year old kernel KM> has no trouble with 64GB, then no distro using a newer kernel KM> (everyone else) should either. Vague stuff coming up. With MotionEye there are two main versions: MotionEyeOS and MotionEye -- the first is more or less a self-entity and what I'm using here. The second is a utility, added on to an OS like Raspbian. I tried the utility a year or two back and didn't have any luck so went back to the OS version. So by using the MotionEyeOS version there could be some old code not working properly past 32GB. OTOH it seems to work fine for some people - maybe I'm missing a command switch? > KM> Lordy, do these people ever test their products outside of a VM? > "Oh, this utility is missing from the installer. I have it here, but > guess you need it there - sorry!" KM> Seen that! Easy enough to do: install some option for another project, it's still installed for the new project so "not needed to be downloaded". > KM> When I made the mistake of doing a netinstall with Debian (the > KM> real thing, not a descendant), it took over four hours, I had to > KM> babysit it the whole way, and when it was done it wouldn't boot. > KM> Not how you make fans... > Really. One thing to be a guinea pig and know there may be problems. > Quite another to be using a finished and supposedly tested product. KM> Exactly... I was more or less a guinea pig two Springs ago when I needed to move my MythTV recordings from the old Backend to the new. Did come across a couple "oh yeah, you need to d/l this utility" and missing "end command" characters -- the semicolon comes to mind. > ..Just thought: at the store the computers sometimes needed to have a > new install. Don't know what happened to cause but a desktop terminal > would fail and need the OS, etc., reinstalled. For whatever reason > would take sometimes _days_. We're not talking the computers running > the store, we're talking those standard units with maybe a 250 GB hard > drive. Sure the data is probably encoded and that takes a whole extra > five seconds to decode. Why it took so long, no idea. Just trying to KM> This woulda been imaging Windows? If so... if it hits a bad spot KM> in the disk, it probably tests the whole disk as it writes. Very KM> slow. In the Really Olden Days, almost all HDs had some bad spots KM> out of the box. (In fact I remember when MFM disks came with a KM> Bad Blocks Map.) Possibly. Admittedly I was curious to learn but usually the person doing the process didn't know more than reading the instructions. KM> But on the same hardware, install of PCLOS under 5 minutes, KM> Fedora under 6 minutes. Completely different installers... but KM> both Red Hat descendants (PCLOS by way of Mandrake/Mandriva) KM> which is probably the significant point. KM> I suppose I should try Kubuntu and see what it does, given Ubuntu KM> is based on Debian. (At least that lets me land on my preferred KM> desktop, tho their implementation of KDE is not great.) Mint hies KM> from Ubuntu, but dumps about 3/4ths of Ubuntu and in previous KM> tests installed fairly fast. FWIW Ubuntu has a bare-bones option. I think the ISO is the same, just select a 'minimal' option instead of 'full'. I've not tried it even though on some computers which are essentially dedicated Frontends (to MythTV) it could make sense. Invariably I'd eventually need whatever was missing. > KM> It's occurred to me that this might be a side effect of PCLOS > KM> being a one-man-band and wholly volunteer, so it only has one > KM> person's time to waste, and Tex isn't real patient. Most distros > KM> are a bunch of people; Debian is hundreds of people. Combine all > KM> that wasted time, and the end user gets it all at once... > I must say I admire those people creating the OSs, as well as various > utilities, etc., etc. Lots of variables, even on 'minor' stuff like AMD > vs. Intel vs. ARM - and then put the various versions and options for > each of those into the mix. Then start adding various video cards, > various audio cards, .... KM> Yeah, to deal with all that you need a stable of programmers... KM> at the distro level, tho, it's really just putting it all KM> together with a script; all the real programming has already been KM> done, especially at the hardware level (drivers etc.) KM> In fact OpenSuSE used to have an automated online "factory" where KM> you could specify whatever you wanted (built on OpenSuSE, but KM> with a wide choice of desktops and features) and it would spit KM> out a custom distro ISO for your personal entertainment. I had it KM> build a version with Trinity desktop, tho it didn't turn out as KM> well as Trinity on PCLOS. But still, shows at that level it's KM> just scripts. My guess is it's similar to a OEM installation: created specifically for (say) HP and they only use certain AMD or Intel CPUs, so don't have to include (nor test for) all the others. Same for the video card and probably a bunch of other motherboard variables. (Remember my level of understanding isn't nearly as in-depth as yours on this stuff! My 'Black Boxes' are giant!) > .. Picked up book called "Glue in Many Lands"; can't put it down. KM> Sticky situation! I am rather attached! ¯ BarryMartin3@ ® ¯ @MyMetronet.NET ® .... Famous Last Words: Everything seems to be working fine now. --- MultiMail/Win32 v0.47 þ wcECHO 4.2 ÷ ILink: The Safe BBS þ Bettendorf, IA --- QScan/PCB v1.20a / 01-0462 * Origin: ILink: CFBBS | cfbbs.no-ip.com | 856-933-7096 (454:1/1) .