I have found the "availability" after startup on a modern machine is much better than it used to be. There was a time when a freshly booted machine probably needed another couple of mins to get its act together before it actually became useable, with SSDs enough RAM and a reasonable processor that no longer seems to be the case.
F: still has 30% space, and even a lame defragmenter could run there.
I've seen worse patterns.
That looke like a "migration" pattern. The OP isn't likely to have sat down at the table and created four partitions randomly with those sizes. Some of those partitions had humble beginnings on a lower capacity drive.
You could earn a Boy Scout badge, for cleaning that up :-) But otherwise, nobody is harmed by moribund partitions.
Paul
There are a few older apps about with 16bit installers for 32bit code. ISTR it was a gotcha for Photoshop in the early days of 64bit Doze.
Which is almost certainly the way to go for really awkward 32 bit only applications. Although I have found that even on 64bit Home Win7 most things *can* be persuaded to run in one of the off the shelf settings. It may take a bit of trial and error binary chopping the options until you find the most recent one where it will still run OK.
Right click on the executable file then Properties Compatibility Run as if under <choose OS back to Win95>
As a last resort "run program as administrator" sometimes works. Older programs were cavalier about wanting to write to bad places.
+1 +1I can see a point in splitting mostly static data onto a separate partition to avoid having to back it up. My 6 men chess tablebases never change but occupy 7G on their own. Some of the work files for puzzle solving and extended proofs run to 100's of GB. I would never want to back them up though since they are irrelevant work in progress.
There may be some merit in having a partition near the start of the disk that is there to allow a legacy operating system to dual boot (although the advent of powerful VMs has largely supplanted that method).
I was given a CD of papers from an adademic journal. It would have cost me a fortune to 'buy' each paper elsewhere.
The CD had a 16 bit installer, and I have to set up an XP VM to access it. And then print to files I could then export (minor complication: I had to fettle the PostScript files as they came out very small in one corner of the page!)
VMs aren't nirvana.
You'll find out what I mean, when you get there.
This is how long it's been around, VMs. They weren't invented last week.
Yup, sorry it was not supposed to be a specific comment about those particular partitions, just a general caution that lots of small nearly full partitions will not perform as well as fewer less full ones.
Yup, quite possibly!
These aren't the first VMs, either.
But they were click and run. Maybe the word run should be in air-quotes. The x86-on-sparc did not help matters.
We're spoiled today with x86-on-x86.
But I've been stuck with heterogenous setups a few times. which range from
0.1x speed or as bad as 0.01x speed.The x86-on-x86 can be 0.9x.
Paul
I raise you:
That's not quite the same thing though.
It's not a window within a window, a nesting on your own computer. That's a nesting shared with five hundred other people, on a single machine. And when the status field shows "505" (and what looks like a "barber chair" icon), everyone is off for a coffee break, because it's crashed. When the load gets over 55, coffee break can't be far behind.
Good times.
Paul
I had an Acorn 5000 30 years ago, one of the first machines that used the Acorn Risk Machine chip (later to become ARM) and there was an official DOS emulator that actually worked.
I ran a copy of TurboC V2 to develop a fire-alarm system and test harness using this DOS emulator. It worked fine in emulator mode on the A5000 but when I tried to build an image for the target system using Hitech C Cross- compiler (Australian company), it took about 12 hours to compile all the modules and link them. On a 386sx PC with 1 meg ram it took 10 minutes to do the same job !.
Well quite. Sometimes one feels that there is limited awareness that quite a lot of computing history predates the x86. By some decades.
Pascal P code might be said to be a virtual machine
The LOndon Hospital was one of the 6 hospitals where the Dept of Health set up proper computer centres in the 1960's to see how computers of that era could help the NHS. They had an Elliot 803 in the early days and I was told by the Ops manager that it used magetic tape that had sprocket holes !. Wiki says this was based on Kodak film base.
Later on they bought a Univac 418-III complete with Fastrand drums, the main store rotating horizontally with read/write heads on long battens that were shuffled from side to side by electromagnets. Not very reliable and was replaced by conventional multi-platter disk drives, but the four fixed-head 'spin dryer' drums were kept and used for 'fast' paging and swapping of the London Hosp runtime system all written in Assembler, which ran as a continuous batch job under RTOS the Univac operating system. They wrote an entire Transaction Processing system themselves complete with pre+post image journalling to tape allowing continuous usage by the 96 VDU terminals around the hospital. It even had it's own in-house database management system all part of the journalling where dozens of applications 'files' were mapped into one or two of the files that Univacs RTOS supported (it only allowed for 15 open files per job AFAIK).
No vdus in development !, the whole lot was developed in assembler using punched cards, as were all the applications that were layered on top. Went live in the early 1970's and was used until 1984 when they rewrote the whole system in Fortran 77 and SYSTEL running on VAX 11/780's with just 4 Mega bytes of RAM !. You needed very deep pockets to have an
8 or 16 Megabyte VAX/780 in the 1980's. The Univac 418-III had 96K words of 18-bit core memory !. Unusually it was a ones-complement machine, where octal 777777 was negative zero !!.The laboratories had a CTL MOD1 mini working as a data concentrator connected to the Univac.
Yes, 35mm movie film but coated with iron oxide instead of emulsion. I used an
803B (no tape drives though) while I was at Uni, wrote my first bit of software in 1965 on it - calculate square root using Newton's method. That was when I learnt about not comparing floats for equality.
I only ever ran one operating system under IBM VM.
And it wasn't an IBM operaying system! Years before Linux etc...
Home users & business users will have different needs. Whatever strategy you chose, someone will tell you how it will fail.
Hard Drive Data & Stats -
So far apart from one early failure, my SSDS are showing SMART data that indicates they will last longer than convenmtional drives.
A friend managed to destroy spinning rust drives in less than the one year guarantee by 24x7 reading and writing of large arrays of numerical data.
I've found rust lasts a reliable 5 years and usually never more than 10.
My oldest SSD is a reliable 5 years old and shows no signs of having used up any of its RAM blocks
If it want for cost, id go all SSD
The manufacturers keep advancing the number of bits stored per cell, so ones you purchase today may not last as well (though the drive sizes keep going up, so the product of writes per cell and number of cells may increase anyway)
Yes and no. There is also something else to be understood, and that is usage patterns. For example my large capacity drives are archived material - data that seldom changes. Or 'WORM' - write once, read many.
That works extremely well with SSDs. Especially with today's wear levelling algorithms.
Where I would be leas sanguine is massive online databases with constant updates, but these you normally RAID anyway. And hot swapping a duff SSD now and again would be a reasonable price to pay for the massive speed increase
The consensus amongst the people who have data to report in the compouter groups matches my experience - todays SSDs are simply better for most purposes than spinning rust. And massive seeks and writes are also destructive of spinning rust drives.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.