Subj : Remmina RDP To : Ky Moffet From : Barry Martin Date : Thu May 23 2024 11:03:00 Hi Ky! > KM> Tho my clients were all Windows... > Though your magic was plugging in the USB thumbdrive with your favourite > Linux flavour and fixing the Windows problem that way! KM> That's my magic for recovering data off drives with busted KM> passwords... Apparently he encryptio isn't where I expected. > > > KM> Whine whine whine! > > > It's 1700 somewhere! > > KM> > > (Hmm: did Ky slide over to the year or did he miss the 24-hour version > > of 5 o'clock somewhere?) > KM> You need to be specific, otherwise I take the one that's a better > KM> fashion statement. > So now tip your tricorn at 5 o'clock! KM> I shall eagerly await this turn of the clock! Bad news: the batteries in the analog clock died! > > KM> Generally if I'm using linux I'm using linux, and I expect things > > KM> to behave like linux. > > The problem I'm finding is some utilties only use Windows, and some > KM> And there's my problem... > I have a bit of a suspicion there's some sort of under-the-table > agreements for the 'Windows exclusively', otherwise why would companies > manufacture for only part of the market? KM> Linux desktops are something like 4% of the desktop market, and KM> most of that is adjunct to the used-hardware market, and the KM> stats probably includes Android tablets (Android is essentially KM> linux). I would guess part of the raeson for the only 4% is Linux wasn't really marketed until recently, and if one can save money by using the old equipment then let's use the old equipment. KM> No one in their right financial mind would spend KM> resources on a linux desktop version that requires more than KM> setting a target flag in the compiler. This is much easier with KM> modern compilers targeting modern OSs, hence a lot of major apps KM> (eg. LibreOffice, Softmaker Office, the KDE stable of desktop KM> apps) are often available across platforms. Makes sense. KM> However, hardware-level utilities are generally coded in Assembly KM> Language, which does not port easily to another OS, precisely KM> because it does its own hardware access. Same reason drivers KM> aren't portable as such. So might have several 'barriers'. First is the compiled for the original OS. The human creating the code is trained and familiar with that OS, so to create code for a second OS needs to learn that also. ....A lot more details in there, of course. > KM> And given it's a flash drive... unless it's purely a filesystem > KM> error, AFAIK it's not recoverable. > Highly limited personal experience here so probably yes. Most of the KM> It becomes like recovering data off a regular memory chip: it KM> just ain't there. Solid state drives (of whatever format) have numerous good points but also some major bad points. Backups are even better now! > problem cases are off-brands, though I had a quirk with all of the black > and yellow ADATA thumbdrives eventually failed yet all of the black and > blues ones are fine. Same seller, same capacity, purchased about the > same time. KM> I remember that. Likely different supplier for the chips and/or KM> logic boards. Plus ADATA had a longstanding repute as crap, so I KM> was not surprised. The good news was I didn't loose anything other than time. KM> Otherwise, I wouldn't pay money for a flash drive of any KM> description. I've mainly used them for SneakerNet and Live Boot. > > KM> Frex, there is NO dedicated RTF editor for linux. I've looked. > > KM> No, LibreOffice is not satisfactory (insert rant about clean > > KM> formatting code vs printer-defined formatting and how the latter > > KM> needs to be stripped out for publication, and also to avoid > > KM> random screwups). So... XP in a VM, and my dedicated RTF editor > > KM> to the rescue. > > Haven't fiddle but thinking gedit and mousepad. ... I haven't used a > > dot-matrix printer in years so zero experience. Only thing I do with > > plain text is fiddle with a little coding. > KM> Nope. Gedit and the like are plaintext editors. In that realm I > KM> like KATE (KDE Another Text Editor, I assume) and it can do all > KM> sorts of programmer formatting.... but the one set of tags it > KM> DOES NOT DO is RTF. > I scanned though some articles and didn't find a reason; was > half-expecting when I saw 'Microsoft' and 'proprietary' to also see a > reference to a copyright or whatever legal "this is mine alone" > document. Half-figured something along those lines would be a suitable > reason. KM> As I said below.... > KM> I expect in the Early Daze this was rejection of a standard from > KM> Microsoft (there was a lot of that -- if MSFT does it, we won't, > KM> or will do the opposite, even if it's the only sane method) but > KM> now it's just... not sexy programming, so no one does it. > Usually pretty much if there is a need then we will do it, otherwise not > worth it. KM> Sometimes we won't do it even if there's a need, to thumb our KM> noses at the Man. Or why for a long time linux had the crap audio KM> format off OGG, but Would Not Do MP3, because it was Encumbered KM> by Patents. In the early days, forget if it was GIF or JPG but KM> one was still under patent so we won't touch it, you will use PNG KM> and like it. The underlying explanation to the why's. KM> There's a point where Principle becomes Cutting Off Your Own KM> Nose. Debian did a lot of that; until recently you couldn't run KM> "non-free" drivers, so if you had X Y or Z hardware that hadn't KM> given their driver source code to linux for free, you were SOL. KM> I remember when that nixed all of NVidia as vidcards, despite KM> being the most common in linux's largest target market (PC KM> builder enthusiasts). Right, and that probably explained in my old notes there are flip-flops: "Nvidia won't work, use AMD" "Nvidia is better but check compatability". > > KM> It's a nuisance, but... better than fighting with WINE. And XP > > KM> will always speak to the whole network, which linux never will. > > KM> (Does not like random other linux boxen, never mind random > > KM> Windows. And cannot be trusted to write files without fragmenting > > KM> them all over the place.) > > Could be. (Not disagreeing with you, just insufficient mackground on my > > end.) I do agree it does seem odd Linux doesn't have a defregment > > option -- hey: good reason to do a fresh install as that puts the files > > back together! > KM> The claim is that linux doesn't fragment, because it just keeps > KM> moving on out to the largest available single block (which of > KM> course wastes a LOT of drive space). > KM> I beg to differ. The red blocks are a single file, written by > KM> linux; the blue blocks are files of similar (rather large) size > KM> written by Windows. > KM> http://doomgold.com/images/linux/fragmented.jpg > To my thinking the only way to keep a file from fragmenting is to have a > rule it needs to be laid down in one contiguous section -- and that > might a bit of added difficulty with those bad segments. KM> That is in fact how DOS does it, if there's room. That's KM> supposedly how linux does it. Except the evidence is that linux KM> does anything but. One suspects if there is ONE fragment, it just KM> blows the rule away entirely and writes segments any damn place. So may as well say it writes in segments; just appears like it doesn't at the beginning because there is so much available room and 'easier' not to figure out where to fragment. KM> This is why I do not trust linux to write archival files, and now KM> always either have Windows-via-the-network or a sacrificial KM> external drive (that I don't mind periodically reformatting) act KM> as the middleman. Here it seems better/easier to use a combination of backup to two devices if important, one device if not so important. ...And every so often check the backups are actually being done! KM> And my observation is that the linux filesystem is much more KM> fragile in the event of an insult such as an ungraceful shutdown KM> (and in the event, fsck will often just delete affected files, KM> sucks to be you.) I don't recall having that problem -- ungraceful shutdowns, yes; loss of files, no. Have lost some work because I wasn't able to save/update a file before the system freeze, but that's not what we're talking about. KM> I have also had linux delete whole swaths of the sacrificial KM> drive because ONE file failed to copy TO that drive. Linux senses your dislike and retaliates!! KM> Cloud enterprise gets away with it because they have honkin' big KM> tape backups, not because the linux filesystems are so reliable. Backups are good!! > The fragmentation discussion almost points to a very good reason to > start with a fresh system rather than upgrade. I don't recall reading > about it specifically as they always seem to say 'files' which sort of > gets thought of as the data -- stuff added by humans. Seems to me the > Operating System files could just as easily get fragmented and > eventually have problems. KM> Really, it means only use SSDs and assume that periodically the KM> system will still need a copy-and-back defragging. And never, KM> ever write user data (especially cache or swap) to the same KM> partition as the OS files. Here the "big systems" have a SSD for the OS and hard drive for the data. Off-hand not sure where the swap goes (which storage device). > KM> The file was damaged beyond use (fortunately not the only copy). > Backups are good! Multiple backups are better! Multiple backups in > different formats are even better! KM> Ya think??! Yup! > KM> But yes, for ages the only way to defragment linux was the same > KM> way we did it in the DOS 5 era and before -- copy everything off, > KM> format the drive, copy everything back. And that's still really > KM> the typical method, if you're using a HDD. (Not so relevant with > KM> SSDs.) Or use huge drives and expect to waste about a third of > KM> the space. > Which is essentially creating a new system. ...Over the years I've sort > of learned to buy/use a lot larger computer hardware than I think I'll > need because something will come along to use all of what I have now. > First XT had a 20 MB hard drive -- I'll never run out of space! Nine > months later space is running low, the sister XT becomes available with > a 40 MB hard drive (and EGA card -- woo-hoo!! [Original was CGA.] > Network the two, so 60 MB available. I'LL NEVER RUN OUT OF SPACE!!! KM> Along come 12TB drives, and..... Right now it appears I won't need anything that large, though a couple of systems here are using 4 TB drives. > KM> Well, there's this, but apparently it's not very good and there's > KM> debate over whether the drive should be mounted or not. And by > KM> default it only does one file. > KM> https://www.howtoforge.com/tutorial/linux-filesystem-defrag/ > KM> Read also the comments. > KM> btrfs filesystem reportedly has its own stability issues.... > I'm not so sure there is any one great (or even good) file defragger. It > would seem each formatting style has it's own rules which would need to > be specifically addressed by the defragger. Would also seem each hard KM> That is true -- it has to know the filesystem and be thoroughly KM> aware of any inbuilt defects. Same as you can't use a FAT file KM> utility on an NTFS file system; it doesn't know how to handle it KM> and will just mark it as Bad! Makes sense: "if I don't know what to do with it then it doesn't meet my parameters so must be bad". KM> Had a client manage to do this. Used a FAT16 disk maintenance KM> utility on a FAT32 drive... ooops. Fortunately, I still had their KM> old drive (just replaced) as backup... That was fortunate! > drive manufacturer and version/family would also need to be address as > well -- why would Western Digital create Black series for regular use > and Red for a NAS? Data is data, but one group has faster writes while > another faster reads. ...Just seems to be too many variables. KM> NAS is expected to be more archival, doesn't need the speed, but KM> needs max data reliability (which may mean more platters per TB). KM> Black is a much faster drive, intended for desktop and gaming KM> use. I have long thought Blue and Green were QC grades rather KM> than different drives. The lower grades make sense: why discard a good unit just because it doens't meet the upper standard? Lots of people out there who would be happy to pay a little less for a slightly slower drive. KM> And some of it is just marketing. Ooo! Pretty lights and flashy colours!! ...Some time back I bought some (to me) off colour RAM. The specs wre identical, just (say) $100 for black and $90 for red. The computer didn't care, I'd only see the RAM when I go inside. ...Eventually spent the $10 on something else. > And I'll bring up another tangent to file placement: I've noticed after > a reboot if I ask for a GUI list of files in a subdirectory the first > time it takes a while -- the more files the longer I'm waiting. But > generally any time after the first inquiry it is an instantaneous > response. Seems there's something working to counteract any slow > response due to fragmentation. KM> Has to rebuild the file cache, and apparently in Ubuntu that KM> cache is not persistent. Appears so. ...Maybe written to RAM for speedy access? KM> Also if you have spinning rust drives set to sleep after X-long, KM> it takes about 30 seconds for the drive to wake back up. Right. I think this one is one all the time; would seem if sleeping then I'd have the wait issue daily. > > I'll admit to having problems 'seeing' other computers around here but > > the correction usually was to fix the ssh connection and then Remmina or > > TigerVNC would run correctly. Both of those do have some sort of a > KM> I think it must be a more general linux thing. Someone I know > KM> sent me a tutorial on how to get Mint to behave on a network and > KM> it was a lot of bother, so I haven't tried it yet. Need to look > KM> on old system for the email.... > You need a larger hard drive to conveniently store the trivia! KM> Why is the trivia the size of the universe??! That's a piece of trivia unto itself! > Some of the issues on my side are caused by the way I do things: I'll > use the same physical Raspberry Pi but with a different (base ^*) SD card > the certificates won't match and the easiest and quickest way, plus the > way I usually find the problem, is to SSH into the remote unit: > "certificates don't match" error pops up, contains the fix command line > -- copy and paste, done! KM> That's using a server function (do I know each piece of hardware KM> by serial number?) on a desktop, aka that's just dumb. But linux KM> sometimes does that. Once killed a Debian install by cloning it KM> to a larger drive. I've done a couple of moves of a Raspberry Pi OS (Buster, I don't think as recent as Bullseye but possibly) successfully, but probably 16 GB to 32 GB, and isn't that in the same 'section' for FAT? KM> And the current Debian install (which hadn't been up in a year or KM> so) is going "servers? what servers??" meaning it's gonna be a KM> full reinstall instead of an upgrade. Good thing for it that it's KM> just experimental and not an everyday-use setup. May be a sneaky way to get around the upgrade problem! > "Base" card up there because I can't think of a better word. I can make > a duplicate of the card and swap it in -- everything will work properly. > Format the card or put a different card in, even with the same OS, and > the unit will now be 'different' to the network: someone else is > impersonanting that IP! The certificate doesn't match! KM> Yeah, it's written what amounts to a serial number to the disk, KM> and YOU CHANGED IT!!! Windows servers do the same thing and then KM> some. You can't just swap a drive, it's assumed you murdered the KM> first one and replaced it with a golem. On the Giant Server (now KM> being gradually dysmangled for parts) I heard about it when I put KM> RAM sticks back in a different order!! Wasn't the same sequence therefore different! ¯ ® ¯ BarryMartin3@MyMetronet.NET ® ¯ ® .... Little known facts: cow farts come from the dairy air. --- 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) .