This is rubbish, the trolley cables use electricity and the fiber optic does IP.
Wellington has never been capable of power outages, we have 8 seperate power routes which was designed to keep the capital incapable of power outages and relay the power generated in the South Island hydrodams.
We connect to the Cook Strait cables in the southern suburbs, & the power goes up through 8 separate lines through the city and the harbour.
The only way what he says could be true is if he got the trolley lines to be used as a backup route for power.
The monopoly network is Telecom who offer JetStream DSL against TelstraClear who offer cable internet.
I just wish SlashDot had less people think America is the World.
NZ does not stand for some backwards state of the USA, NZ has the most advanced networks in the world.
Wellington has the world's most domain names per capita, the most internet connections per capita, the most electronic transactions per capita and the most cafes per capita.
BTW, the scenery in Lord of The Rings was computer generated, it was shot around Wellington and the countryside.
TelstraClear cable services 35% of wellington homes, I have the basic broadband at 128k, 10 gig per month @ NZ$80 and we have cable TV and a phone line for NZ$80 per month.
NZ$160 is about US$64, so it isn't anywhere near as expensive or restricted as CityLink.
CityLink only covers half the central city, while TelstraClear has cable around the whole Wellington Region, rolling out in Christchurch and starting up in Auckland.
In 3 years, TelstraClear will reach about 70 percent of New Zealand businesses and homes. Hamilton, Tauranga & Dunedin will be connected from the CBD out.
More details on http://www.telstrasaturn.co.nz/
CityLink details on http://www.citylink.co.nz/
The Wellington CBD is host to many head offices, most of the rest are in the Auckland metropolis & the last few are in Christchurch.
Typically unclear ZDnet: the network runs at 1Gbps, you connect at 0.1Gbps and get 67x better than T1.
CityLink is expanding into Auckland central, but has to go underground as Auckland doesn't have the old tram power lines that Wellington uses for electric buses.
CityLink is a big fiberoptic cable running on top of the bus cables in the central city.
I've used CityLink at the PlayHutt internet cafe, it is incredibly fast and makes the top speed of the TelstraClear cable network (1Mb down, 256 up)look as slow a 300bit modem.
Most people in Wellington just use TelstraClear cable at 128k or DSL with Telecom, it's only the inner city apartments who can get citylink at home.
Grub won't be able to understand the MS database format because MS won't use a standard format and won't document it.
I am developing an operating system, pretty much rewriting BSD from the kernel up.
My system is based on a database filesystem that does it's work through SQL3 and XML.
Microsoft will be using their proprietory extensions to SQL in such a way that only their SQL programs can use the fs.
In contrast, my system will be able to be worked on by any program that does SQL3 or XML.
Ask yourself which is more convienient.
> I suppose I am playing the devils advocate here, but I must also point out that Linux is here to stay.
Yes, you can't kill off open source development.
> I just hope the buzz isn't. As long as there is a core team willing to maintain each BSD as free and relevant (current), then they will remain free.
You may not have heard about my KaosBSD, it's not free in my core areas at all.
However, it has all of OpenBSD in it and may use some of the NetBSD ports.
> In the sci-fi post apocalyptic future, when only corporate entities have interest in maintaining BSD kernels, they will mutate into horribly disfigured proprietary mutants.
Perhaps you have heard of KaosBSD, it's a proprietory mutant if there ever was one.
However, it is significantly differnet from the free BSDs and is worth using.
> Assuming that governments enforcing Intellectual Property are more resillient than Free, Open 'Net-using BSD maintainers, Linux will remain the horribly disfigured yet free mutant kernel that it is today.
You think linux has an ugly kernel? wait till you see my exokernel system in KAOS.
Allowing apps to do sstem functions is pretty ugly.
Darwin is mostly FreeBSD with the powerPC port of NetBSD.
OpenBSD isn't used much in OS X as there are issues with american companies using strong encryption for export.
OS X got most of their stuff from Jordan Hubbard, a prominent BSD guru.
> But, you ARE purchasing all that in one big interconnected and tied together glob in Microsoft Windows. It's ties so tightly that it's almost impossible for a competitor to offer any components.
True, which is why my kaos system is only restricted in the core kernel. The component system is publically documented and can be improved by anyone who credits me and does not compete with me on those items.
> It seems to me that Windows is a Swiss Army Knife of components. It has a knife - not the best, it has a can opener - not the best, it has a corkscrew - not the best, it likely has a saw component - once again, not the best.
Yes, but the convienence of having all that in 1 gadget is the real selling point.
> Now how about if you could remove the knife component and replace it with a compatible BETTER knife component? The specifications for size and connectivity of this knife component would need to be published.
That sounds good, I'll do that for kaos.
I'd be happy to see people come up with better components.
> Maybe you don't WANT a corkscrew - with this hypothetical Swiss Army Knife, you get the corkscrew whether you want it or not AND it's cost is integrated into the cost of the amalgamated product.
Yes, that is how my system is sold. But you can replace the components you don't want.
> Do you like paying for tools you never use?
I use Mac OS X, there are some system tools I'll never use yet paid for in the box.
>> So let me get this straight. Just because putting a database as the filesystem backend will give them an advantage over some of their competitors, us desktop Windows users should be denied the benefits it would afford us?
No, the database should go into windows filesystem. It just shouldn't be microsoft SQL.
> What benefits? Most Windows users don't even know what a filesystem is much less a relational filesystem. Users just want to run their stuff.
The benefits of database filesystem are the simpler search for files and better performance.
> Microsoft has a monopoly in the PC market in Operating Systems. They are using their power in one market to vie for another market.
I agree, but I don't think their database is strong enough to win more market share.
> There are companies out there that would like to compete - they have families to feed, they have dreams and goals too. Shall we deny them the chance to make it by allowing a monopolist to run unchecked?
While I have no family of my own to feed yet, I'd like the chance to make money if I compete with microsoft.
> Are you a monopolist?
> Microsoft is attempting to coopt the Applications into the Operating System i.e. tie their applications to the Windows OS so that competition is stiffled.
I agree, there is too much bloat already in windows without throwing more crap in.
> We need firm definitions of what an Operating System and Application IS so that competition can occur and therby stimulate real innovation.
An operating system is the basic software that your hardware needs to run.
Applications are what you need to do specialised tasks on your OS.
> Here is what I think would be a good start on an idea that would provide for both competition and innovation for consumers of Operating Systems:
I think this is a bit too narrow, but it could work for linux.
> Define an Operating System as a kernel i.e. that single piece of code that has ultimate programmatic control over the machine and is not preemptable by any other piece of code.
> The running level of the kernel is to be deemed kernelspace.
> Define an Application as a client of the kernel and as receiving services provided by the kernel and that operating environment that is preemptable by the kernel and doesn't run in kernelspace is to be deemed userspace.
my exokernel is different again by letting applications do high end OS operations.
> Require interfaces between clients of the kernel and between clients and the kernel to be documented and published 6 months prior to the Operating System Producers version of same interfaces and any derivatives therof.
That should be no problem for my system as it uses the OpenBSD model of 6 months stable before release.
I can just publish the APIs when a branch goes into stability & security testing.
> Define a module or driver as a pseudo-client of the kernel OS and it's interfaces shall be documented in the same spirit as any code that runs in a particular space.
This is basically how an exokernel works.
> When the pseudo-client/driver/module is present in the kernel i.e. loaded and running in kernelspace, it is to be considered as part of the running kernel and subject to it's benefits and responsibilities.
Dynamic module loading is a standard feature of exokernel systems.
> When the pseudo-client/driver/module is running in userspace it is to be considered an application and subject to it's benefits and responsibilities.
I have no problem with this, unles the app gets less capacity to do things.
> Whatever a competitor wants to do inside the black box of the kernel/OS, Application/client or pseudo-client/driver/module can be deemed proprietary insofar as the black-box doesn't try to communicate such proprietary data, information or interfaces between components, interfaces or running levels i.e. kernelspace and userspace.
The kernel blackbox is securely locked in kaos, 3rd parties can load their own modules dynamically in the running kernel.
Communications are handled by agents and allow full interoperation between apps.
> IANAL and I'm sure others may have better or more concise definitions but.... the definitions should be made and separation of the various pieces should be enforced as well as the publicly available documentation of their interfaces in a timely and competitive manner.
I have documentation which will be published on my website when it has it's own domain name. Hopefully I'll get by going by Friday.
What you're describing is an exokernel. my Kaos is an exokernel operating system.
The core is the kernel and it runs on a ramdisk in my system.
The other features are in the LibOS API: RDBMS; SMTP service; HTML rendering , window manager; dhcp server; wins server; web server; mac server; file sharing server; print server; a web browser help system, etc...
These are all system applications that come with the system that make it work.
Most applications you can purchase from seperate companies or my subsidary companies.
You've probably heard of my Kaos operating system, see my journal and website for more info.
> Actually, that one's pretty easy. Intel wants p2p to be big, too. Why? Because they want people to buy bigger and badder PCs. You'll need all that OS/hard drive/Processor to do p2p computing.
P2P doesn't need better hardware, it needs a better OS designed to use P2P.
> At some point someone might just make an actual "thin client" because traditional Interent applications (email, browsing, etc.) and many business functions can be light client/heavy server apps.
I'm already working on that with kibble slim binary apps, kibble downloads the source code then compiles to that hardware.
The whole system can be light/heavy or heavy/light client/server based on a distributed grid.
> These apps don't need big Pentium 6's running at 10 ghz. They also don't need a 2 GB OS. So P2P is a PC "killer app".
Kaos is called the Killer App Operating System because it has P2P, heavy encryption & application crashproofing.
> The sooner client/server computing is moved towards p2p in terms of horsepower, the better for the Duopoly.
I can get my Kaos system with P2P running on any platform NetBSD runs on.
Microsoft is incapable of porting to 30 platforms.
I'm doing this for my operating system.
P2P built in is ok if they don't screw up, but this is microsoft. Do you think they can't screw this up?
The problem is, they will use VisualBasic and let those virii do things like make that goatse.cx picture as your startup screen.
My system has a database filesystem, encrypted P2P, Video and Voice conferencing, task docks built in already.
However I think I'm more likely of getting a stable, secure implementation out there than the great monolith of microsoft.
Although I disagree with most of the rubbish RevAaron has to say, Squeak is pretty good at this sort of thing.
I'm even thinking of learning smalltalk to play with squeak for a while.
> After tooling with the kernel, I have been told time and time again, if it needs to be in the kernel, then put it in. If not, make it user space.
> This process hibernation deal does not need to be in the kernel simply because a program should have the option of sleeping, or what have you built into the programs construct.
My KaosBSD has this in the exokernel because hibernation and application status logging is part of the JFS API available to all applications.
> To put an operating system kludge to support a program's shortcomings is a microsoft mentality that I would rather not have repeated in Linux.
What's the difference between closed kludge and open kludge? can't you fix open kludge?
> If at the very most, the kernel should give the process the ability to capture all of its relevent data before closing.
Which is exactly how I've implemented hibernation.
> Reasons why to not implement "random access" process hybernation:
> 1. File Access:
> The operating system would have to guarantee that the file descriptor is stored, and that the referencing file is not unlinked. The alternative is having the program smart enough to realize it was put into hibernation, hence throwing away the advantage of a kernel solution.
I have hibernation and app status setup to allow programs to reload the status saved. This is best done in the exokernel.
> 2. Mutual Exclusion:
> If you have a program that uses OS based mutual exclusion, you will run into several problems.
> (a) If the OS does not yank the lock, other programs that share the lock will be stuck forever, which could break like tons of programs. Most shared libraries should use locking to keep the two processes from trouncing on one another during execution in the module, so...
Which is why I use an exokernel to handle basic system processing.
> (b) If the OS releases the lock, then when unhibernated, the program could run into serious problems if it thinks it has a lock, but in reality, does not, or you can run into cyclic lock dependencies and race conditions if the locking code was not writen right. This issue has the same issues involved with preemption.
My Kaos system uses parallel probability prediction instead of preemptive multitasking.
locking is not a problem.
> 3. Networking:
> Pretty obvious, but if the program and the server do not know about the hibernation, the server should grumble but live on (never trust those clients..), and the client will probably become SOL and defunct.
Kaos apps are designed to run on a grid, programs communicate with the server just fine.
> Since there is no notification that the connection was broken, the OS can either send an invalid descriptor (if it isn't stored), or it can be a little smarter and say that the foreign host closed the connection.. This one can be solved, but I think that saving the descriptor and reviving it could be interesting..
It's part of the JFS API in Kaos, program revival is simple.
> I am sure there things I have not covered, (Removable media syncs..), but this is too long already. There are a lot of technilogical factors which would make this very hard for a single kernel fix, but if we tied a unified solution into the user space, we could make a slow transition to supporting this.
I'm not going to use existing kernels because I'm going over to an exokernel structured system. It will run faster and better than just patching the system.
Perhaps linux is too bloated already with kernel patches.
I'm writing a new system, KaosBSD. I consider this to be one of the main problems of existing programs, so I'm putting application status logging into the JFS API.
All the app has to do is call JFS and it gets autosaving in the background, usually every minute but you can change the preference for that.
Ported unix apps should call JFS to get at the system anyway, so this should be worth running KAOS.
I'm starting to feel like other slashdotters have been reading my mind...
That's exactly how Kaos is designed, the memory system isn't capable of being restored properly, so I'm using a status log manager as part of JFS.
> And it makes no sense for every programmer to create the feature in every application he ever writes. It should be an operating system capability.
Which is exactly why I've designed KaosBSD to have this in the JFS API.
This is a simple autosave routine that can save your days of SETI processing, genome crunching or mozilla browsing in a status file.
KAOS apps can only crash agent processes, but ported apps that can crash the whole app would still use the JFS API to save your work.
I'm writing KaosBSD from the exokernel up. I'm working status filing into the JFS which is almost what you want. KaosBSD notes what the app process agents are doing every few seconds then writes to the status files.
This saves the space needed to write the RAM usage, it only worries about what the agents are doing. It can do this for individual apps or the system.
I'm developing KaosBSD with this feature built in. Because I'm writing a different kind of kernel (exokernel) this feature is in an API that KAOS apps call anyway.
What this means is you can port your app, then it has this feature in Kaos and the GUI is made to handle hibernation.
Feel free to request features you want or tell me how you'd like this done.
See my notes on the KaosBSD way of handling process restoration.
BTW, Kaos has freeze to pause a process, you could save it's state or hibernate the application (save the status of all process agents then quit) if you're going to run out of power.
Slashdot Mirror
This is rubbish, the trolley cables use electricity and the fiber optic does IP.
Wellington has never been capable of power outages, we have 8 seperate power routes which was designed to keep the capital incapable of power outages and relay the power generated in the South Island hydrodams.
We connect to the Cook Strait cables in the southern suburbs, & the power goes up through 8 separate lines through the city and the harbour.
The only way what he says could be true is if he got the trolley lines to be used as a backup route for power.
The monopoly network is Telecom who offer JetStream DSL against TelstraClear who offer cable internet.
I just wish SlashDot had less people think America is the World.
NZ does not stand for some backwards state of the USA, NZ has the most advanced networks in the world.
Wellington has the world's most domain names per capita, the most internet connections per capita, the most electronic transactions per capita and the most cafes per capita.
BTW, the scenery in Lord of The Rings was computer generated, it was shot around Wellington and the countryside.
TelstraClear cable services 35% of wellington homes, I have the basic broadband at 128k, 10 gig per month @ NZ$80 and we have cable TV and a phone line for NZ$80 per month.
NZ$160 is about US$64, so it isn't anywhere near as expensive or restricted as CityLink.
CityLink only covers half the central city, while TelstraClear has cable around the whole Wellington Region, rolling out in Christchurch and starting up in Auckland.
In 3 years, TelstraClear will reach about 70 percent of New Zealand businesses and homes. Hamilton, Tauranga & Dunedin will be connected from the CBD out.
More details on http://www.telstrasaturn.co.nz/
CityLink details on http://www.citylink.co.nz/
The Wellington CBD is host to many head offices, most of the rest are in the Auckland metropolis & the last few are in Christchurch.
Typically unclear ZDnet: the network runs at 1Gbps, you connect at 0.1Gbps and get 67x better than T1.
CityLink is expanding into Auckland central, but has to go underground as Auckland doesn't have the old tram power lines that Wellington uses for electric buses.
CityLink is a big fiberoptic cable running on top of the bus cables in the central city.
I've used CityLink at the PlayHutt internet cafe, it is incredibly fast and makes the top speed of the TelstraClear cable network (1Mb down, 256 up)look as slow a 300bit modem.
Most people in Wellington just use TelstraClear cable at 128k or DSL with Telecom, it's only the inner city apartments who can get citylink at home.
Grub won't be able to understand the MS database format because MS won't use a standard format and won't document it.
I am developing an operating system, pretty much rewriting BSD from the kernel up.
My system is based on a database filesystem that does it's work through SQL3 and XML.
Microsoft will be using their proprietory extensions to SQL in such a way that only their SQL programs can use the fs.
In contrast, my system will be able to be worked on by any program that does SQL3 or XML.
Ask yourself which is more convienient.
> I suppose I am playing the devils advocate here, but I must also point out that Linux is here to stay.
Yes, you can't kill off open source development.
> I just hope the buzz isn't. As long as there is a core team willing to maintain each BSD as free and relevant (current), then they will remain free.
You may not have heard about my KaosBSD, it's not free in my core areas at all.
However, it has all of OpenBSD in it and may use some of the NetBSD ports.
> In the sci-fi post apocalyptic future, when only corporate entities have interest in maintaining BSD kernels, they will mutate into horribly disfigured proprietary mutants.
Perhaps you have heard of KaosBSD, it's a proprietory mutant if there ever was one.
However, it is significantly differnet from the free BSDs and is worth using.
> Assuming that governments enforcing Intellectual Property are more resillient than Free, Open 'Net-using BSD maintainers, Linux will remain the horribly disfigured yet free mutant kernel that it is today.
You think linux has an ugly kernel? wait till you see my exokernel system in KAOS.
Allowing apps to do sstem functions is pretty ugly.
Darwin is mostly FreeBSD with the powerPC port of NetBSD.
OpenBSD isn't used much in OS X as there are issues with american companies using strong encryption for export.
OS X got most of their stuff from Jordan Hubbard, a prominent BSD guru.
Basically, this is a description of an exokernel.
> But, you ARE purchasing all that in one big interconnected and tied together glob in Microsoft Windows. It's ties so tightly that it's almost impossible for a competitor to offer any components.
True, which is why my kaos system is only restricted in the core kernel. The component system is publically documented and can be improved by anyone who credits me and does not compete with me on those items.
> It seems to me that Windows is a Swiss Army Knife of components. It has a knife - not the best, it has a can opener - not the best, it has a corkscrew - not the best, it likely has a saw component - once again, not the best.
Yes, but the convienence of having all that in 1 gadget is the real selling point.
> Now how about if you could remove the knife component and replace it with a compatible BETTER knife component? The specifications for size and connectivity of this knife component would need to be published.
That sounds good, I'll do that for kaos.
I'd be happy to see people come up with better components.
> Maybe you don't WANT a corkscrew - with this hypothetical Swiss Army Knife, you get the corkscrew whether you want it or not AND it's cost is integrated into the cost of the amalgamated product.
Yes, that is how my system is sold. But you can replace the components you don't want.
> Do you like paying for tools you never use?
I use Mac OS X, there are some system tools I'll never use yet paid for in the box.
>> So let me get this straight. Just because putting a database as the filesystem backend will give them an advantage over some of their competitors, us desktop Windows users should be denied the benefits it would afford us?
No, the database should go into windows filesystem. It just shouldn't be microsoft SQL.
> What benefits? Most Windows users don't even know what a filesystem is much less a relational filesystem. Users just want to run their stuff.
The benefits of database filesystem are the simpler search for files and better performance.
> Microsoft has a monopoly in the PC market in Operating Systems. They are using their power in one market to vie for another market.
I agree, but I don't think their database is strong enough to win more market share.
> There are companies out there that would like to compete - they have families to feed, they have dreams and goals too. Shall we deny them the chance to make it by allowing a monopolist to run unchecked?
While I have no family of my own to feed yet, I'd like the chance to make money if I compete with microsoft.
> Are you a monopolist?
> Microsoft is attempting to coopt the Applications into the Operating System i.e. tie their applications to the Windows OS so that competition is stiffled.
I agree, there is too much bloat already in windows without throwing more crap in.
> We need firm definitions of what an Operating System and Application IS so that competition can occur and therby stimulate real innovation.
An operating system is the basic software that your hardware needs to run.
Applications are what you need to do specialised tasks on your OS.
> Here is what I think would be a good start on an idea that would provide for both competition and innovation for consumers of Operating Systems:
I think this is a bit too narrow, but it could work for linux.
> Define an Operating System as a kernel i.e. that single piece of code that has ultimate programmatic control over the machine and is not preemptable by any other piece of code.
> The running level of the kernel is to be deemed kernelspace.
> Define an Application as a client of the kernel and as receiving services provided by the kernel and that operating environment that is preemptable by the kernel and doesn't run in kernelspace is to be deemed userspace.
my exokernel is different again by letting applications do high end OS operations.
> Require interfaces between clients of the kernel and between clients and the kernel to be documented and published 6 months prior to the Operating System Producers version of same interfaces and any derivatives therof.
That should be no problem for my system as it uses the OpenBSD model of 6 months stable before release.
I can just publish the APIs when a branch goes into stability & security testing.
> Define a module or driver as a pseudo-client of the kernel OS and it's interfaces shall be documented in the same spirit as any code that runs in a particular space.
This is basically how an exokernel works.
> When the pseudo-client/driver/module is present in the kernel i.e. loaded and running in kernelspace, it is to be considered as part of the running kernel and subject to it's benefits and responsibilities.
Dynamic module loading is a standard feature of exokernel systems.
> When the pseudo-client/driver/module is running in userspace it is to be considered an application and subject to it's benefits and responsibilities.
I have no problem with this, unles the app gets less capacity to do things.
> Whatever a competitor wants to do inside the black box of the kernel/OS, Application/client or pseudo-client/driver/module can be deemed proprietary insofar as the black-box doesn't try to communicate such proprietary data, information or interfaces between components, interfaces or running levels i.e. kernelspace and userspace.
The kernel blackbox is securely locked in kaos, 3rd parties can load their own modules dynamically in the running kernel.
Communications are handled by agents and allow full interoperation between apps.
> IANAL and I'm sure others may have better or more concise definitions but.... the definitions should be made and separation of the various pieces should be enforced as well as the publicly available documentation of their interfaces in a timely and competitive manner.
I have documentation which will be published on my website when it has it's own domain name. Hopefully I'll get by going by Friday.
What you're describing is an exokernel. my Kaos is an exokernel operating system.
The core is the kernel and it runs on a ramdisk in my system.
The other features are in the LibOS API: RDBMS; SMTP service; HTML rendering , window manager; dhcp server; wins server; web server; mac server; file sharing server; print server; a web browser help system, etc...
These are all system applications that come with the system that make it work.
Most applications you can purchase from seperate companies or my subsidary companies.
Which is why I've had that in the Kaos project since day 1.
This allows heirarchal filing, relational filing, etc.
Read my journal or website for more details.
You've probably heard of my Kaos operating system, see my journal and website for more info.
> Actually, that one's pretty easy. Intel wants p2p to be big, too. Why? Because they want people to buy bigger and badder PCs. You'll need all that OS/hard drive/Processor to do p2p computing.
P2P doesn't need better hardware, it needs a better OS designed to use P2P.
> At some point someone might just make an actual "thin client" because traditional Interent applications (email, browsing, etc.) and many business functions can be light client/heavy server apps.
I'm already working on that with kibble slim binary apps, kibble downloads the source code then compiles to that hardware.
The whole system can be light/heavy or heavy/light client/server based on a distributed grid.
> These apps don't need big Pentium 6's running at 10 ghz. They also don't need a 2 GB OS. So P2P is a PC "killer app".
Kaos is called the Killer App Operating System because it has P2P, heavy encryption & application crashproofing.
> The sooner client/server computing is moved towards p2p in terms of horsepower, the better for the Duopoly.
I can get my Kaos system with P2P running on any platform NetBSD runs on.
Microsoft is incapable of porting to 30 platforms.
I'm doing this for my operating system.
P2P built in is ok if they don't screw up, but this is microsoft. Do you think they can't screw this up?
The problem is, they will use VisualBasic and let those virii do things like make that goatse.cx picture as your startup screen.
My system has a database filesystem, encrypted P2P, Video and Voice conferencing, task docks built in already.
However I think I'm more likely of getting a stable, secure implementation out there than the great monolith of microsoft.
enter anyone's name and you get this cool script.
has anyone tried http://CmdrTaco.isgay.com
?
Although I disagree with most of the rubbish RevAaron has to say, Squeak is pretty good at this sort of thing.
I'm even thinking of learning smalltalk to play with squeak for a while.
> After tooling with the kernel, I have been told time and time again, if it needs to be in the kernel, then put it in. If not, make it user space.
> This process hibernation deal does not need to be in the kernel simply because a program should have the option of sleeping, or what have you built into the programs construct.
My KaosBSD has this in the exokernel because hibernation and application status logging is part of the JFS API available to all applications.
> To put an operating system kludge to support a program's shortcomings is a microsoft mentality that I would rather not have repeated in Linux.
What's the difference between closed kludge and open kludge? can't you fix open kludge?
> If at the very most, the kernel should give the process the ability to capture all of its relevent data before closing.
Which is exactly how I've implemented hibernation.
> Reasons why to not implement "random access" process hybernation:
> 1. File Access:
> The operating system would have to guarantee that the file descriptor is stored, and that the referencing file is not unlinked. The alternative is having the program smart enough to realize it was put into hibernation, hence throwing away the advantage of a kernel solution.
I have hibernation and app status setup to allow programs to reload the status saved. This is best done in the exokernel.
> 2. Mutual Exclusion:
> If you have a program that uses OS based mutual exclusion, you will run into several problems.
> (a) If the OS does not yank the lock, other programs that share the lock will be stuck forever, which could break like tons of programs. Most shared libraries should use locking to keep the two processes from trouncing on one another during execution in the module, so...
Which is why I use an exokernel to handle basic system processing.
> (b) If the OS releases the lock, then when unhibernated, the program could run into serious problems if it thinks it has a lock, but in reality, does not, or you can run into cyclic lock dependencies and race conditions if the locking code was not writen right. This issue has the same issues involved with preemption.
My Kaos system uses parallel probability prediction instead of preemptive multitasking.
locking is not a problem.
> 3. Networking:
> Pretty obvious, but if the program and the server do not know about the hibernation, the server should grumble but live on (never trust those clients..), and the client will probably become SOL and defunct.
Kaos apps are designed to run on a grid, programs communicate with the server just fine.
> Since there is no notification that the connection was broken, the OS can either send an invalid descriptor (if it isn't stored), or it can be a little smarter and say that the foreign host closed the connection.. This one can be solved, but I think that saving the descriptor and reviving it could be interesting..
It's part of the JFS API in Kaos, program revival is simple.
> I am sure there things I have not covered, (Removable media syncs..), but this is too long already. There are a lot of technilogical factors which would make this very hard for a single kernel fix, but if we tied a unified solution into the user space, we could make a slow transition to supporting this.
I'm not going to use existing kernels because I'm going over to an exokernel structured system. It will run faster and better than just patching the system.
Perhaps linux is too bloated already with kernel patches.
I'm writing a new system, KaosBSD. I consider this to be one of the main problems of existing programs, so I'm putting application status logging into the JFS API.
All the app has to do is call JFS and it gets autosaving in the background, usually every minute but you can change the preference for that.
Ported unix apps should call JFS to get at the system anyway, so this should be worth running KAOS.
I'm starting to feel like other slashdotters have been reading my mind...
That's exactly how Kaos is designed, the memory system isn't capable of being restored properly, so I'm using a status log manager as part of JFS.
> And it makes no sense for every programmer to create the feature in every application he ever writes. It should be an operating system capability.
Which is exactly why I've designed KaosBSD to have this in the JFS API.
This is a simple autosave routine that can save your days of SETI processing, genome crunching or mozilla browsing in a status file.
KAOS apps can only crash agent processes, but ported apps that can crash the whole app would still use the JFS API to save your work.
KaosBSD hibernates by status filing in the JFS. This can then be used to restore an agent process, an app or the whole system on another machine.
KaosBSD notes what the app process agents are doing every few seconds then writes to the status files.
This saves the space needed to write the RAM usage, it only worries about what the agents are doing. It can do this for individual apps or the system.
I'm developing KaosBSD with this feature built in. Because I'm writing a different kind of kernel (exokernel) this feature is in an API that KAOS apps call anyway.
What this means is you can port your app, then it has this feature in Kaos and the GUI is made to handle hibernation.
Feel free to request features you want or tell me how you'd like this done.
BTW, Kaos has freeze to pause a process, you could save it's state or hibernate the application (save the status of all process agents then quit) if you're going to run out of power.