OSDev.org

Well, I have been thinking.. To be honest, I don't feel the idea is feasible for the moment.. but anyway

What if you could boot over the internet? Like you had a bootloader "OS" that could access internet well enough to load a kernel image off the internet along with a root image? much like PXE but more flexible and easier to setup(assuming the bootloader OS is easy to install or run off a live CD or whatever)

Now I can already see the slowness of internet argument. Well, that's why the idea isn't feasible just yet. But if you had one of those connections like brynet where a gig download is done in about 10 seconds, then this wouldn't be too bad an idea.. especially combining offline disk caching and such along with it..

benefits? well seemless upgrades... diskless computers that don't require setting up a lot of crap to get PXE going(and wouldn't require a computer with a disk)

also, kernels that could possibly make use of those drivers in the bootloader OS much like a BIOS system, but only with networking stuff.

anyone have any comments about this idea?

I have a pretty damn good connection and I have actually done this some time ago. I modified ReactOS' Freeldr to boot an image of Windows 2000 I prepared and booted it successfully over the Internet. It took 2 minutes and a half to download the image and after that everything seemed to be just fine. I think it's an important step towards distributed computing.

Greetz

I know there are various guides on how to set up Linux-based diskless clusters, such as this one: http://www.gentoo.org/doc/en/diskless-howto.xml. Although, it does use PXE, and I see your point about being hard to configure. The issue is that the thing that is really hard to configure is the operating system of the master node, so if you have an OS that sets this up for you and allows you to make a clone of it over the internet, you're already in business.

It would definitely make updating easier, since it's more or less transparent to end users. Just update the image on the server and anyone that boots it from that point forward is already updated. You could then send a quick message to anyone already running the OS that there's an updated version ready (probably to a few, like 10 or 15, people at a time to keep everyone from rebooting and DDOSing your servers by accident).

Try gPXELINUX. It can run off a boot disk, and can boot over TCP if you wish.

The only problem I see with it is personalizing and "owning" the image... what about applications you want to install and use, without having to worry about reinstalling every reboot? how would you sync it back to your own personalized copy? I thought rcp might be kinda neat for that.. and if combined with like svn and such technologies, it would be easy to roll back whatever changes you did to your computer recently to break it...

But I think this would be really handy to be able to login to "your" computer anywhere there is internet.

The only weird thing is like those people with a TB of music on their harddrives.. where would you divide the offline and online stuff?

Sounds to me like you're thinking about having a basic client to a remote server with all the files & settings for each user.

It would be much more preferable to only load the kernel image, and have the kernel specifically written to obtain data from the remote host. Whatever happens, you will require modifications to the kernel to make this idea work.

Your server would have to be really robust
Imagine at 8 am or just after a power cut... I can't imagine the bandwidth required to boot thousands of computers at the same time
If your server is down, computers will simply not be able to boot


And for security this is very bad
If someone manages to hack the DNS he could very easily put a trojan on any computer using this O/S

Tomaka17 wrote:And for security this is very bad
If someone manages to hack the DNS he could very easily put a trojan on any computer using this O/S

At boot there is far more worse things than trojans

is the principal here not the same as booting over LAN, lots of companies are buying this and to solve the problem of installed programs at least in *nix you can use AUFS or UnionFS for changes or have a second set of servers operating LDAP(much more reliable) the main problem is that these sorts of setups use much more RAM than traditional disk based solutions but their transparency & security is no more at threat than n other linux PC in fact the distro could be many times smaller because who needs all the security packages when your system image is a ROM without privileges to change any files, set up a third server running ClamAV and all thee servers are protected (btw LDAP in linux can be modified to .tar.gz all the LDAP's therefore reducing bandwidth and reducing the risks of virii

I think their must be a few extra security precautions, Such as maybe MD5 checks on "known" kernels and such.. but really I don't think all that is too much to worry about..

yes, RAM usage would be increased, but most computers these days come with 2 and 4G of it, which should be plenty, especially combined with a small harddrive or something like that if you must have a TB of music and play a RAM intensive game at the same time lol

and for the bandwidth bit.. how big would a kernel image be? and a root FS and such? what would all need to be loaded off the server exactly? and if people actually used my OS, I would charge money for internet booting(even if it was open source) so I think I could get enough bandwidth to handle it..

I was talking in general about netbooting and Linux (which is massively filled with bloatware) a usable install for end users would take up about 500mb (openoffice kiosk with firefox) bear in mind dreamhost runs pretty darn much unlimited bandwidth and that the ROM has no upload all you need is userdata and on a netboot machine (i.e. not for games thats not that much space maybe 10-50mb that gets squashfs-ed & gzipped)

Maybe to decrease bandwidth, you could use a diff/patch on a client to update them instead of sending a full image. It would probably work fine if you checksum everything. You could even host the entire OS on git in installed form, and have the filesystem be a built in repository . Users could share private branches of their running systems instead of using a package manager, or keep revision control of files instead of using a "recycle bin" - all without too much extra space use.

Or use a bittorrent-like protocol. For a given application, 99% of files will be exactly the same, which means lots of clients will have them. So why not use them to upload the files to computers that are booting up? Even for user files, most of the large files are music and video. I'd bet a significant portion of those files would be common amongst all the users who have them (or in other words, how many different rips of a given movie are there? I bet not many...).

JackScott wrote:Or use a bittorrent-like protocol. For a given application, 99% of files will be exactly the same, which means lots of clients will have them. So why not use them to upload the files to computers that are booting up? Even for user files, most of the large files are music and video. I'd bet a significant portion of those files would be common amongst all the users who have them (or in other words, how many different rips of a given movie are there? I bet not many...).

hmm.. very interesting idea.. basically it could be like self-supported networks, where the more computers in the network, the more available bandwidth, and if the server went down, not every computer would(sometimes)

though this does seem to pose a privacy and security risk..