h a l f b a k e r yactual product may differ from illustration
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
While watching my home windows 98 machine boot today on my 1GHz Athlon, i was thinking <deep sigh> "remember the old days, when that c64 or timex sinclair booted right out of ROM in a couple seconds?". Then i thought about the project i'm on where i am working with an embedded processor that boots
the linux kernel out of flash, and how it boots in about three seconds.
Then i thought "hey! we should put the OS back into ROM for desktop computers!" Mass produced, ROM is a stink of a lot cheaper than hard drive space, even at the current HD prices. Sure, you would not be able to replace your kernel and some of the surrounding OS tools without replacing the ROM, but hey, how many people replace their kernel on windows very often? I would be willing to pay to buy a new ROM to plug into my motherboard every couple of years and have it boot in a few seconds rather than wait a few minutes a couple of times per day.
Any system-upgradable stuff could be thrown onto a specific sector of the HD (just as the OS is now), or even configured in a motherboard-resident flash. Remember, memory is dirt cheap - even NAND flash is cheap.
I don't have real numbers on cost of HD/MB or ROM/MB, but i'll use the case where they're equal. (they aren't. ROM is much cheaper) If you assume that you reboot your computer once per day, and that it takes three minutes to boot from the HD (like mine) and three seconds to boot from ROM (like my embedded linux computers at work), you find you will save 17hrs 56.5minutes (~18hrs) per year for living your life. If the storage space was the same cost, you would virtually *save* money because you would have that extra free space on your hard drive which was formerly taken up by 100Megs of your OS. (although likely more if using MS)
All that by distributing the OS on ROM instead of installing to a hard drive. It would also avoid many of microsoft's unhappiness with pirated versions and licensing, as it would be much harder to pirate (from a common tools point of view), and it wouldn't be worth it to most people, anyway.
Distributing an OS on a hard-to-upgrade ROM might also create more pressure on the OS companies to release a **STABLE** product, first time out of the gate. There would _not_ be the idea floating around of "oh, well we should release this by <insert date> to take advantage of the <insert holiday> rush - we'll fix all the bugs with upgrades over the internet".
Same complaint
http://www.halfbake...h_20on_20and_20play
Less specific about the solution, though. [jutta, Oct 29 2001]
thinknic network computer
http://www.thinknic.com
a (cd) ROM only thin desktop / thick client [tenhand, Oct 29 2001, last modified Oct 04 2004]
Archiving Computer
Archiving_20Computer
Copies data on slow MO disks to RAM [Vernon, Mar 25 2009]
Solid State Disk Drives
Solid_20State_20Disk_20Drives
How to get the most out of a lot of RAM [Vernon, Mar 25 2009]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
I've often dreamed about something similar. |
|
| |
<Vernon>
I want a modular computer based on a black box component design. Every component (video card, network card, CPU) is a box (square or rectangular) 3" on a side (or a multiple thereof). 5 of the 6 sides would have multiple socketed connectors like a Nintendo console. The remaining side would be dedicated for drive aperatures (for floppy / Zip / DVD / CD) or feet. |
|
| |
The components would connect to each other through an interconnect cartridge which could also provide compatability, data buffering, switching, QOS and RAM. |
|
| |
Getting back on subject, I anticipated all software (OS included) to be executed via ROM chips in cartridges - just like a Nintendo game. Long term storage would be executed via a hard drive cube (semi-portable), flash RAM in a cartridge or Zip/Jazz type device (both very portable). |
|
| |
Upgrading hardware or software would be a cinch and, execpt for a few key components, could be performed on the fly (hot swapped).
</Vernon> |
|
| |
I have this theory that the number in the name of Windows OS's relates to the time in seconds that it takes to boot. |
|
| |
3.1 would be 31 seconds I supose (or 3.1 seconds on a pentium 4?)
xp would be xseconds times p seconds where microsoft refuse to tell us what the numbers are?
and I don't even want to think about windows 2000 |
|
| |
Actualy my win98 is taking less than a minute now that I've cleard out some of the junk that was loading on startup... |
|
| |
Win3.1, from memory, booted in about 15 seconds on a 486/66. Of course, that's cheating because it doesn't count the time for DOS to boot. |
|
| |
My Win95 machine takes more than 95 seconds to boot, though, and my WinME machine is slower too because it has far more stuff loading at start-up. (Perhaps ME is a twisted form of Roman numerals?) |
|
| |
More recent than the C64 and Spectrum, Acorn machines also had OS in ROM. For some reason, they took quite a while boot (about on par with normal HDD-based machines. |
|
| |
Disk is damn cheap. Let's see some evidence that ROM is cheaper. |
|
| |
ROM can't be upgraded or patched or modified in any way. Ich.
Most of all, this wouldn't help nearly as much as you think. Boot times are not dominated by just transferring the OS from disk into RAM -- you can blit disk into RAM on most modern computers in a few seconds. It's all about crufty old hardware and crufty piles of operating system components. PDAs and embedded systems boot quickly because they have neither. |
|
| |
(And PDAs actually take a while to boot, when you really "boot" them. In normal use, they're just "suspended" when off.) |
|
| |
This is largely off-topic, but the MS bloat is incredible. Cameron mentioned an OS taking 100 megs. Can you believe, WinXP takes a full gig (i'm fairly certain, haven't checked my facts though)??? What's taking so much space? What is this mess MS is putting in our OS's? Ok, that little diatribe's over. |
|
| |
My friend's a computer wizard. He's working on building a PDA that runs from some sort of Flash instead of RAM so it boots instantly and doesn't drain batteries while turned "off." Now whether he'll actually get the project DONE is another matter... |
|
| |
I really rambled... live with it. I'm sleepy. |
|
| |
egnor - ROM is cheap. Ask
any ASIC manufacturer/sales
rep for some quotes on ROM in
million unit volumes. I
haven't been a professional
hardware designer for almost
five years now, but even five
years ago it was cheap cheap
cheap. (comparatively, that
is) |
|
| |
Of *course* the ROM itself is
not patchable. That's what
the "RO" (read-only) part of
ROM is all about. However,
it is upgradable. That idea
was briefly mentioned in my
idea above. I also covered
how to apply patches without
swapping out the ROM. |
|
| |
As far as it "wouldn't help
nearly as much as you think",
you need to cook
up some numbers to try and
convince me rather than
assuming i'll believe it
outright. While
you *are* right that the
hardware configuration
consumes time, my experience
working with hardware
(embedded, custom designs,
and plugin modules) and
software (application and
kernel) says that "Put the OS
in ROM, and you'll be
cooking in seconds". |
|
| |
...and we all know cooking
leads to baking. ;-) |
|
| |
You can get *gigabytes* of rotating media for under $100. Just how much does a gigabyte of ROM cost? Remember, these computers will have a hard disk anyway, so it's just a matter of the price differential from making it a little bigger. I can't find prices online; can you? Otherwise it's just my say-so vs. yours. |
|
| |
Your embedded, custom designs, and plugin modules did not have to deal with unknown PC hardware and (I suspect) they did not have to run Windows. Booting an embedded OS on a fixed hardware configuration is one thing; booting a Windows PC is another. |
|
| |
I have some rough figures.
Maxtor HDD, 5400rpm: AU$5/gig;
WD HDD, 7200rpm: AU$5.50/gig;
PC-133 SDRAM: AU$160/gig;
ROM: not sure, but I doubt it'd be cheaper than SDRAM - it's also significantly slower;
Flash ROM: haven't been able to chase down exact prices, but I believe that it's on the order of $25/meg! |
|
| |
[egnor] I believe that operating systems only spend a few seconds initialising the hardware. More to the point is the amount of rubbish that they're loading into RAM at boot-up. |
|
| |
WinME seems to allocate on the order of 90mb just sitting there doing nothing, and Win95 uses around 50mb. If you are running a recent version of Windows with <128mb, lots of the disc access you see at boot-up may be due to swapping. |
|
| |
Microsoft isn't the only guilty party here ... Currently, the Linux machine I'm sitting at has 112 mb RAM used, although that's with lots of stuff open. |
|
| |
Flash is currently selling for about a US dollar a megabyte. This compares with about USD 1 - 2 for a gigabyte of hard drive at consumer sizes. |
|
| |
Most hardware companies use some form of programmable memory, such as Flash, to store firmware (firmware=the code that makes hardware devices run without having to load any software from disk, etc.) This is used in hardware devices such as PC DVD-ROM drives, portable MP3 players, etc, to allow for upgrades. It is possible to use ROM in conjunction with a disk to allow upgrades, but that would be a little retrograde, somewhat on the level of setting DIP switches. |
|
| |
In practice, I think a lot could be done simply by making better use of a hard drive. If the system would save a memory image containing all the drivers and config data correctly organised, that could be loaded very quickly. On the other hand, a large part of a boot sequence is taken up by testing hardware and seeing if the system has changed. |
|
| |
pottedstu: Windows can already do that save-memory-dump-to-disc thing. It doesn't seem to boot any faster, and it doesn't want to work on all machines. (Not sure why.) |
|
| |
What you really want is a system where the entire RAM is dumped to the swap partition, and then read back as needed (as opposed to what Windows does, where the whole lot is read back at boot time). |
|
| |
Windows' scheme for detecting what hardware has changed doesn't work very well. In an attempt to upgrade a machine by changing motherboards, it somehow gained the idea that it no longer had an IDE controller attached. |
|
| |
Makes you wonder if anyone is paying attention. |
|
| |
The issue is not one of cost, but of speed. Yes, hard drives are cheap. Yes, hard drives have great capacity. But hard drives are (relatively) slow. That's true of any mechanical device and always will be. |
|
| |
If you want to address the issue of cost, look at SDRAM (or RDRAM). Prices are lower than ever. The cost of any new technology must be recovered before prices can drop. If you build it, they will come. |
|
| |
Lastly, EEPROMs exist. Flash memory exists. Both technologies store data in a non-destructive manner, but can be rewritten. The real point is: if I can buy a Nintendo cartridge and expect the software therein to perform without patches, why can't I set the same expectation for my office productivity application? Or my OS for that matter? |
|
| |
I work for Caldera. We put the linux kernel into the BIOS. The operating system is actually online in a few seconds; it takes too long to ring disks online and such, but I work in the embedded market, where disks are optional. Seriously: the OS resides in the flash ROM of the computer. Beat that bootup time :) |
|
| |
I am a regular PC user and would love to know how to beat the boot up time on my PC, also is it possible to install C++, C++Visual and PYTHON on 1 singular PC...Would appreciate any advise fm all the BIG Computer GURU's out there.....my email address is : ibayley@yahoo.com....Thank u |
|
| |
Embedded systems and desktop computers are apples and oranges. Nintendo cartridges can be produced without the need for patches because they are developed for a monolithic architecture (which is not to say bugs don't appear). Your operating system needs to be frequently updated because the hardware on which it runs and the standards it uses are frequently updated. Loading a customized kernel from flash on known hardware is not equivalent to loading a modern desktop OS on generic hardware. |
|
| |
I have an "internet appliance" here which boots its OS and GUI from Flash. It runs on standard PC hardware, with no hard drive. I've installed various operating systems on it. It's always slow to boot. It seems you'll have to do better if you want to improve boot time, eh? |
|
| |
In practice, I don't think that boot-time is a major thing. In my experience, computers tend to be rebooted just once or twice per day, and I just leave my machine alone for a few minutes, come back, and it's ready. (Yes, it would be probably be better from the power-consumption perspective if computers weren't left on all day, but that's another matter again.) |
|
| |
Most modern PCs can supply a fair amount of power when they're powered down (~1 amp, I think). This could probably be used to keep the contents of the SDRAM alive, with everything else shut down, and thus "boot-up" would be almost instantaneous. |
|
| |
phoenix - you are right, we
have gotten sidetracked. The
original point of this idea
was for a FAST boot up at a
reasonable cost, and had
almost nothing to do with the
relative cost of hard drive
space versus ROM...especially
since the OS would be
distributed on ROM with no
install to the HD in the
first place. |
|
| |
Anway, that being said, back
onto the side conversation ;-) |
|
| |
I want to remind everybody
that i'm not talking about
FlashROM (which is about
$1/MB) or even EEPROM. I'm
talking about custom-burnt
ASICS from a factory in
volumes of millions of units. |
|
| |
I contacted a local sales rep
that deals with our company
on the topic of ROM costs.
Unfortunately, the reply was
less than useful. (He reps
many companies for many
different types of hardware
and doesn't get a lot of
custom ASIC requests) His
exact phrasing was "Each ASIC
ROM is usually evaluated on a
case by case basis."
Although we discussed the NRE
costs. Over a million pieces
the NRE would amortise to
about $0.025/unit regardless
of size. (which would work
out to about a fortieth of a
cent per MB for a 100MB
ROM. Of course, this doesn't
help us for the final cost
one whit.) I asked him for
some contact addresses who
could provide more info.
I'll post it here if i ever
get any, even if nobody gives
a tinker's damn anymore. ;-) |
|
| |
Some local pricing for disk
space (non-volume prices)
work out to ~$0.01/MB for HD
space and ~$0.30/MB for DRAM.
(those are canadian dollars)
I really do believe custom
ROM to be cheaper than DRAM
in large volumes, and a poll
of some hardware designers at
work agreed. No word on to
what degree it is cheaper,
but i am willing to concede
it may not be cheaper than HD
space. ROM *used* to be a
stink of a lot cheaper than
HD space. ;-) |
|
| |
cp - the ROM i describe isn't
slower than DRAM, AFAIR.
Flash is much slower, though. |
|
| |
pottedstu - i also like the
idea of more efficiently
using the HD. I remember a
lifetime ago when i had a
c64. There were programs
that would take 10 minutes to
load...but i got a loader app
that allowed me to load those
same programs in under a
minute. I don't know what it
did to make the access so
much faster. (and likely it
couldn't be as easily applied
to today's tech) |
|
| |
Anyway, as phoenix pointed
out, all this is way off
track. The point was speed.
My computer takes too long to
boot and i want it to do it
quickly. On exactly the same
architecture, it takes my
windows 98 about 3 minutes to
boot, and linux about 45
seconds. (this isn't MS
bashing time - even 45
seconds is too long :P) I
want a desktop computer to
boot in under 10 seconds!
:-))) |
|
| |
[Cameron] Okay, point taken. I'm willing to believe that you can get cheap ROMs. But you'll probably have to do more than just shove everything into ROM to achieve your goal, because just the BIOS self-test takes around 10-20 seconds. |
|
| |
Also, I'm not sure if HDD access is as much of a problem as you think it is. As an experiment, I logged in and out of KDE a couple of times so that it would be loading entirely from disc cache, and ... it took 18 seconds to load KDE entirely from cache (Duron 800, 256mb PC-133 SDRAM), and around 35 seconds from HDD. That's not counting the couple of seconds that it takes to start the X server, either. Does anyone know how to easily measure this for the rest of the OS, or for Windows? |
|
| |
[Rods Tiger] Re. your link, bear in mind that the stated data rate is "500--800 Kbytes/sec". That's waaay slower than a hard drive. |
|
| |
Oh well. I guess that's what
halfbakery is all
about...half baked ideas. :-) |
|
| |
I would gladly deal with not having to upgrade / patch / whatever the thing if it meant it would be stable. Half of the problem it seems with the industry is that it's never staying put, and my disaster of a box is the result. I just want to turn it on and watch it do what's it's supposed to do and not have to mess with the damn thing. |
|
| |
Have a look at RISC OS - ROM based StongArm OS.
Version 5 just announced - www.iyonix.com - runs on XScale processors. *Lots* of applications available. |
|
| |
This may be irrelevant, but I can't help thinking about the text-based BBS I ran for several years from a RAMdrive in a laptop with no hard drive. (Yes, they had laptops with only floppy drives!) It sat on a bookshelf, unattended; I logged on from another computer on a 2nd phoneline. The software was quite stable and utilized a self-maintaining, fixed-size database. The few times the power went out, the battery acted as a UPS. Worked great! Ah, simpler times... |
|
| |
Vista boots off my notebook's SSD in 15 seconds. 5 of that is taken up by the $#@% bios doing its thing. |
|
| |
[phoenix], nice try, but in one respect not what I would have said. See, in the Good Old Days ROM was rather slower than RAM. I don't know if that is still true, though. If so, I would want to be able to copy ROM to RAM and run the code in RAM. I've mentioned the equivalent of this before in a couple other Ideas (see links). |
|
| |