BARRY MARTIN wrote:
> 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! <g>
> KM> That's my magic for recovering data off drives with busted
> KM> passwords...
> Apparently he encryptio isn't where I expected.
Encrypted drives would be different, yeah. Then you need the password.
But these are just login passwords, and that's readily bypassed.
> > > > KM> Whine whine whine!
> > > > It's 1700 somewhere! <bseg>
> > > KM> <tips tricorn hat>
> > > (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!
<checking> The battery is nine years old, but the second hand is still
moving....
Wait. Wouldn't that be the third hand?
Or maybe the gripping hand??
> > > 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.
No, it's because the vast majority of the desktop market is enterprise business
(you buy PCs by the each and keep 'em til they die; they buy
'em by the pallet or the truckload and replace them every three years,
when they fall out of warranty support), and enterprise business needs
*legally* supported software. Only RedHat does that, and only for
servers, and even then linux does not run the Adobe and Microsoft and
AutoDesk products that are most of what business uses.
Linux is really only *legally* supported in the narrow server market,
and ONLY for the base server OS, and ONLY for RedHat and possibly Ubuntu Server
and a couple others, none of any interest to the consumer
desktop. And not for ANY desktop hardware.
And there's legal liability. My sister's architecture firm (she's risen
to 2nd in command after the founder and knows of what she speaks) is big enough
to have about a hundred offices worldwide, and its own legal
counsel. Who says you will NOT use unsupported or not-industry-standard
ANYTHING (not even company vehicles can be out of warranty and support) because
if you do and something goes wrong with that building you
designed, YOU ARE LIABLE JUST BECAUSE OF THAT. Doesn't matter if you
screwed up or not, that is how the COURTS and JURIES will see it. So you
will use CURRENT VERSION of MAINSTREAM COMMERCIAL SOFTWARE and LIKE IT.
You can design a building perfectly well using FreeCAD. You also open
yourself up to millions (potentially billions with today's construction
costs) in legal liability that you would NOT be exposed to if you had
instead used industry-standard software, which is the current supported version
of AutoCAD, period. There's the relevant phrase: INDUSTRY STANDARD.
And people use at home what they use at work. It's just easier, because
you don't have to learn a second OS and wholly different way of doing
things. Especially not when the linux way of doing things is often
contrary and difficult.
So there's no incentive to use linux on the personal desktop, outside of
hobbyists and the perverse, who are a tiny market segment. Frankly I'm
surprised it's as high as 4%; at peak Apple with all its fanboys only
had 20%, and now it's a lot less, even tho Apple puts a lot of money and effort
into marketing and support. (Back then Apple had the monopoly on graphical
apps. As of Win95, Windows ate Apple's lunch.)
Which means outside of a tiny slice of those hobbyists and perverse,
there's no market for linux desktops. Dell tried. It didn't go anywhere
(presumably because not only was there no real demand, but also because
after-sale support was a nightmare, hardly worth the $5 to $30 per unit
they saved on licensing Windows; likely the same reason they stopped
selling bare-metal desktop systems too.) What there's no real market for
is doing astonishingly well to have 4% of what is logged by internet
servers (where the stats come from).
> 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.
KDE even runs a "binary factory" that automates cross-platform builds (Windows,
Mac, Android, others), tho that lately migrated to Gitlab and
is no longer the nice handy interface it used to be. *($# if I can
figure it out now. It's just bloody awful.
https://invent.kde.org/explore/groups?sort=name_asc
> 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.
And all that for a market segment that doesn't really exist.
> > 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!
Yeah, that exactly. And some lose data if they sit unpowered for very long.
Which is probably why they also suck a laptop dry just from sitting
there turned off.
> > 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. <shrug>
> 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. <g>
> The good news was I didn't loose anything other than time.
*whew* !!
> 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.
Yeah, that sort of thing where it's disposable, okay. NOT for everyday
or storage.
> 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".
Yep, there ya go.
> > 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.
IOW, it fibs about how it does things, and what you won't admit happens
you can't fix.
> 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!
Backups go on NTFS filesystem here, period. Written by Windows, any Windows.
> 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.
Nope. This is "instead of fixing the file table entry, we'll nuke the
file". There is no predicting when it will do that, either, but if it
decides it needs a long session with fsck, you can count on it. You
think the file is still there, and it's not.... fortunately all it's
eaten are Youtube downloads, but some are no longer available.
> 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!!
This is the linux I love! But it cheats on me anyway!!
> > 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).
SSDs and NVMes here for workspace and OS, HDD for storage.
> > 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.
Famous Last Words. <g>
> > 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.
Same reason we have Celeron and lower-speed CPUs to this day. The ones
in the center of the wafer are better quality. Around the edges, to
varying degrees less so. But still perfectly good working chips, just
can't count on 'em being as good. But that's also why so many cheap CPUs
can be drastically overclocked -- they're actually as good, but can't
count on it for sales purposes.
> 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.
LOL. I don't want all that bling, it's needless heat and power consumption.
So buy server RAM and no bling. <g>
> > 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?
Evidently.
> 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.
Likely so. One of mine silently runs an MP3 all the time because
otherwise it won't stay awake. The downside is it records a spin-up each
time the file plays. It's recorded something like 17,000 spin-ups.
> > You need a larger hard drive to conveniently store the trivia! <g>
> KM> Why is the trivia the size of the universe??!
> That's a piece of trivia unto itself!
It never ends!
> > 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?
Uh, no....FAT is DOS filesystem, Pi probably uses ext4 or some such.
> 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!
LOL. Not so sneaky, and of course it wants to do an update during
install. NO NO NO I don't have six hours to babysit the damn thing....
■ RNET 2.10U: ILink: Techware BBS ■ Hollywood, Ca ■ www.techware2k.com
--- QScan/PCB v1.20a / 01-0462
* Origin: ILink: CFBBS | cfbbs.no-ip.com | 856-933-7096 (454:1/1)
|
