OSDev.org

Solar wrote:

DavidCooper wrote:I'll rephrase what I said before: ... to the point where it can dissassemble any program and work out exactly what it is indended to do in every aspect.

Sigh. That sounds great at the discussion table. Have you ever tried to make sense of raw machine code? Yes, you can see that numbers are shoved here and there, that there are increments and decrements and conditional branches. But to figure out what that code actually does, on a semantic level?

If you index the machine code, patterns in it soon become clear. If you identify the bits of memory it's using and what's in those locations, you get clues as to what different bits of code are for. If you identify all the calls to the OS and know what they're for, again you get an idea of what the program's trying to do. If you look at the points where it puts messages up on the screen or where it displays anything else to the user, again you get clues as to what different parts of the code are for. You can gradually narrow down which bits of code do what, and then narrow down what smaller and smaller components of the code do, and if the program is designed in a sensible way (which it will be if it's going to work at all well) it will loop through the same things over and over again in an ordered way rather than doing random things at random times and jumping from one activity to another like a hyperactive child who can never concentrate on anything long enough to get anything done. I've put a lot of effort into trying how work out how I could make my own code impossible to follow by including as much misleading mess in it as possible, but it simply won't work. You can't hide what a program does or how it does it.

Of course you can write programs that can run forever and do unpredictable things, but to try to write a virus in such a way that your intention can be kept hidden within such a program is another matter entirely. How deep can a programmer think when trying to hide complex malicious code within mathematical algorithms which never halt?

You haven't gotten the larger picture. What the Halting problem says is that there is no way a software could figure out what some other software does without actually running it with its actual parameters.

If you run it through a monitor program, how long's it going to take you to identify the main loop of the program? How long's it going to take you to work out what the other main loops are and to draw up a map of the general pattern of how the program operates? You don't have to run the program as is, but can intervene and force it to follow branches when you want it to in order to analyse what they do, so you don't need to wait for rare conditions to occur before you explore them, such as a particular date leading to malicious code becoming active - you follow that branch without waiting for that date to be tried with the program and you find out what it does.

As for whether an app halts or not, the answer is that it normally depends on how long the user want's to go on using the app - it may never halt because he never wants to halt it. This Halting problem stuff it simply not relevant to what normal apps do - a normal app will run round and round through loops doing standard things again and again, and it will be written in such a way as to try to eliminate unwanted actions for situations where things don't work out the way they're hoped to, so it's a completely different thing. Apps are not mathematical mystery tours where the destination is unknown.

How many experience do you have with malware? A good friend of mine works in the security department of a major German bank. He could tell you some things about how "unimportant display bugs" and such stuff can be exploited, which would make your hair stand on end.

I can think of a couple of trivial display bugs in my programs which are simply not worth bothering to cure because they can't do any harm, no one's likely to spot them or care about them if they do, and it would take a lot of extra code to eliminate them. There's no way anyone could exploit them any more than they could exploit the code that could be added to eliminate them. Clearly you have to make a judgement based on the exact nature of the display bug, because if it involves leaving part of a message on the screen starting perhaps in a part of the screen which an app can't access, perhaps some other message could then be merged with it and look as if it's come from the OS rather than the app, but that isn't what I'd class as a trivial display bug.

Memory protection is easy.

I just have a feeling that it may disappear from machines in the future, so why design an OS to depend upon it?

I bet you a month's salary against a hamburger that won't happen within our lifetime.

There's a bit of a design problem with that bet as it can only be won when neither of us are here to gain or lose from the result, but who knows what's round the corner - processors that make mistakes may be much faster than processors that don't, so protection mechanisms may need to be much more extensive to enable that to work.

The friend I was talking about has found (and reported) a bug in the specification of HTML 5, that basically requires a compliant browser to execute code embedded in a canvas object. And that's just one miniscule thing in a very complex standard. (Just to prove that it's not only software errors. There are errors in hardware, there are errors in specifications. You cannot avoid that.)

But this won't be machine code that's being run, so it's going to be interpreted by a program which can check everything it does and block it from doing anything it shouldn't, just as with any JavaScript program on a Web page.

Back to the original topic:

DavidCooper, which other operating system's apps would you like to run? DOS apps? Windows 3.1 apps? Linux apps? Windows 7 apps?

Are there any hobbyist operating systems whose apps your operating system might run?

As for myself, I'm a long way from version 0.0.0.1 of my operating system and running its native apps. I do plan on porting the usual GNU utilities (ls, cp, bash, etc.) in order to get things working reliably before I start messing around with graphics, but I might consider some day running programs from Visopsys and Menuet-32 after getting my own graphics stack working smoothly.

CelestialMechanic wrote:Back to the original topic:

DavidCooper, which other operating system's apps would you like to run? DOS apps? Windows 3.1 apps? Linux apps? Windows 7 apps?

Are there any hobbyist operating systems whose apps your operating system might run?

I don't know, but having done a bit more reading I'm not sure I want to tie in with anything that's any more complex than necessary, so I'm not going to be swayed by a particular type of API on the basis of how much it's used now. POSIX looks as if it may be the road to go down if you simply want to be able to run lots of existing stuff on it, but all the existing stuff will probably have to be rewritten in order for A.I. to work efficiently with it anyway, so I think I should be looking at compact, simple OSes which are more focussed on how things should ideally be done. I certainly don't want to work with Windows apps which need to be installed into an OS in a complicated way (and disinstalled in similar manner) - it should always be a simple matter of load, run, close and then delete if you decide to get rid of it.

As for myself, I'm a long way from version 0.0.0.1 of my operating system and running its native apps. I do plan on porting the usual GNU utilities (ls, cp, bash, etc.) in order to get things working reliably before I start messing around with graphics, but I might consider some day running programs from Visopsys and Menuet-32 after getting my own graphics stack working smoothly.

Having just looked into both of those, I really like the approach of Menuet. I don't use int to call on system services, so I could copy the whole http://www.menuetos.net/syscall.txt system and make their apps compatible with my OS without disrupting anything else, though it would obviously then take years of work to back that up with the actual code to run it all. So far, it's the one that's inspired me the most to want to make my OS compatible with it, just because of the way it's been crafted, though there may well be better OSes that I don't know of yet. I started this thread because I was hoping there might be a list of lists of similar kinds of OS which new OS designers could be pointed towards to see which group of OSes theirs fits into in terms of common design philosophy so that they can quickly see if there's an API there that could become or might already be a standard worth copying. If there is no such list of lists, perhaps one should be cobbled together here to make it easier for people to see where their own OS fits in.

There's a list of nearly two hundred OSes in the wiki, but they're simply put in alphabetical order rather than grouping them by similarities, which isn't surprising because that would be a hard task, and of course the best-known OSes aren't in the list at all. The idea of grouping them by common design philosophy doesn't necessarily work if a simple OS then ties itself to POSIX, but then that would automatically shove it into the POSIX camp anyway, so it might be best to put it in a sub-list within a POSIX list. The thing to do would be to group all the ones that are attempting to be compatible with any particular standard together, while incompatible ones would be grouped by other similarities which might lead you to think they would do well to work to a common standard, even if the people behind them have no interest in making them compatible. The most advanced ones or the ones with the most diverse list of apps already running on it would be placed towards the top of their list. An OS which sets out to be compatible with more than one standard would be able to appear in more than one list.

The easiest way to generate such a list of lists would be to put a few OS names into a list and then let others copy and paste that list into a new post along with their own additions and modifications. We'll soon see if this idea has any mileage in it. If the list gets too big to do this here, it could move to the wiki, but it may not get far enough to justify that. I don't know enough to start it either, but someone who's already explored in detail what's out there might be able to put together a rough framework with a couple of dozen OSes in it which others could then expand on. Of course, if no one thinks any useful groupings exist, this will obviously get nowhere and the whole idea can be forgotten, but it seems to me that at the very least it would be useful to have some kind of map to help people see clearly where their OS stands in relation to all the others.

Hi,

DavidCooper wrote:

As for myself, I'm a long way from version 0.0.0.1 of my operating system and running its native apps. I do plan on porting the usual GNU utilities (ls, cp, bash, etc.) in order to get things working reliably before I start messing around with graphics, but I might consider some day running programs from Visopsys and Menuet-32 after getting my own graphics stack working smoothly.

Having just looked into both of those, I really like the approach of Menuet. I don't use int to call on system services, so I could copy the whole http://www.menuetos.net/syscall.txt system and make their apps compatible with my OS without disrupting anything else, though it would obviously then take years of work to back that up with the actual code to run it all.

Mimicking the kernel API from another OS is the easy part. Unfortunately an application relies on much more than just the kernel API - things like executable file formats, expecting certain shared libraries to exist (and behave in a certain way), expecting the file system to look a certain way (potentially including special files, like the contents of every sub-directory and every file in the "/proc" directory on some OSs). Then there's the whole IPC nightmare. If an application sends a message to "process 1234" (or opens the network socket "127.0.0.1:1234", or whatever) and assumes that this is the font engine (or GUI or database or...), then it's going to expect a compatible reply from that process (and you'll end up re-implementing every process than an application could talk to). Basically, mimicking the kernel API alone is probably around 2% of the work you'd need to do to emulate a different (sufficiently complete) OS.

Of course you could always pretend A.I. is a silver bullet that will magically solve any possible problem, and say "when I achieve something that researchers have failed to do in 50+ years, I'll be able to <insert anything you like here because nobody can prove it wrong>". You won't actually implement anything, but if you say it often enough someone might actually believe it...


Cheers,

Brendan

berkus wrote:Something like Trove Software Map on sourceforge or tags based OS clouds might be helpful to categorize (because of their mostly "automatic" nature - the owners who update their OS info update the categories, relieving lots of maintenance burden from admins).

It would certainly be best if the OS designers did all the work themselves. I just see a wall of OSes at the moment in which it's very hard to tell which ones are worth exploring further, and it takes ages hunting for more details about them. I can't see many people having the time to explore more than a few.

You might want to look into Pebble OS, I think it has some interesting properties in similarity to your system. (Might be not the best example overall, but this is one of the OSes that inspired me, and I just thought of it while reading this topic).

I found http://www.usenix.org/event/usenix99/fu ... gabber.pdf after some hunting and thought I should include the link for others so that they can get straight to something longer than a couple of sentences. I'll read through it carefully and learn what I can from it.

Brendan wrote:Mimicking the kernel API from another OS is the easy part. ... Basically, mimicking the kernel API alone is probably around 2% of the work you'd need to do to emulate a different (sufficiently complete) OS.

I've probably wildly underestimated the difficulty, though I was imagining that it would be possible for for a whole bunch of OSes in the early stages of development to try to create a standard system for running applications which aren't hugely demanding in terms of the range of ways in which they interact with the OS. Apps which stay within the rules of that standard could then run on all of them without modification (assuming they're all running on PCs with 32-bit mode capability). If an app needs to do something more advanced, the OSes may then diverge and the compatiblility disappear for more complex apps, though a smaller group of OS designers may still be happy to go on making sure their OSes remain compatible even for more demanding apps. Of course there would be difficulties and arguments about the best ways to do things, but any group which aims for compatibility is likely to make all of its members stronger if the requirement to do things in particular ways doesn't get in the way of the aims those individuals have for their OS which drove them to build them in the first place. Wherever it gets in the way of their plans, they obviously have to diverge, but a core of compatibility would still be worth maintaining for a wide range of simpler apps which are never going to need a lot of OS interactions beyond keyboard, mouse, screen and the ability to load and save data files. Even if it restricted compatible apps to using VGA modes, I think it would still be very worthwhile to have a common system for simpler apps which don't need fancy communications with more exotic kinds of hardware.

Of course you could always pretend A.I. is a silver bullet that will magically solve any possible problem, and say "when I achieve something that researchers have failed to do in 50+ years, I'll be able to <insert anything you like here because nobody can prove it wrong>". You won't actually implement anything, but if you say it often enough someone might actually believe it...

There won't be anything magic about it - it will simply provide any OS designer with the workforce to get a lot of boring, difficult stuff done without effort, though it will also eliminate the need for OSes to be compatible at the same time. As soon as A.I. reaches human level, it will leave us miles behind just through the speed at which it gets things done and through its inability to underperform or make mistakes through tiredness, boredom, laziness or whatever, so it will be able to translate all apps to run on any system (if the hardware is up to it). I'm not going to discuss my A.I. work here or even give you a prediction of when humal-level A.I. will be available. All I will say is that I'm a linguistician who has worked in generative semantics for a very long time, breaking down all the most important words in language to the point where they can be expressed solely through fundamental components of meaning - that allows you to translate any wording of an idea into any other form of wording of the same idea such that a database can be put together in which any idea can be compared with any other idea in the database with precision (leading to elimination of contradictions in the data by determining much of the data to be probably false, elimination of contradictions being the road to understanding). Most generative semanticists gave up this work decades ago because it was seen as an impossible task. I didn't know that when I started my work on this as a child (my original aim being to create a perfect artificial language), so I just got on with the "impossible" work until I got to the point where instead of the complexity continuing to increase (as it had done for many years), it started to decrease and everything began to mesh together neatly. I then learned to program and wrote my OS to use as a platform for doing my AI work on (which was quicker than trying to learn how to wrestle with someone else's complex programming environment).

Because that work takes up most of my time, I don't have a lot of time left to put into adding more capability to my OS of the kind needed for doing other kinds of A.I. experiments (involving vision, hearing and robotics), and that's why I'm looking to see if there are any easy shortcuts to getting more hardware working with it which might allow me to get things done without wasting effort by going down wrong paths, and if there is already code available which I can just bolt on to my OS for something, it would be sensible to do just that, so long as it doesn't slow the machine down or add so much complexity that it's more trouble than it's worth. If it (or any other OS using that code) ends up being a commercial OS to any degree, clearly the writer(s) of that code deserve to get their cut if it is included in it, so this doesn't have to be about people sharing or giving their work away for free. It's simply about all of us avoiding wasting our lives reinventing the wheel over and over again. We have our own ideas about OS design which makes creating an OS fun, but when it comes to the boring bits about communicating with webcams and microphones, I just want to get data in from them and into memory where I can access it and start to do interesting work with it, and I want to be able to do it through my own programming system so that I don't have to learn other people's complex systems. I'm guessing that other people are likely to want to do similar things with their OS without getting bogged down first in writing dozens of device drivers for years. Life's too short for that.

I've probably wildly underestimated the difficulty, though I was imagining that it would be possible for for a whole bunch of OSes in the early stages of development to try to create a standard system for running applications which aren't hugely demanding in terms of the range of ways in which they interact with the OS.

Why bother? Nothing would set apart that "bunch of OSes" - they'd all essentially be clones of each other because everything that makes an OS unique would have to be the same. If anything was different, the behaviour of an application may not be consistent across all of the systems... Not to mention the difference between, say, a micro and monolithic kernel.

You could wrap it all up with APIs, perhaps. You would still need to figure out a way to load the same binary file (and handle different architectures!) too.

By that point you may as well just be running Java (or some other bytecode) applications... which are already mostly portable across operating systems and architectures, and already well-specified compared to some spontaneous solution invented on a forum somewhere.

EDIT: Also, as soon as you jump into something like Java (for example), protection becomes significantly easier anyway. There's been a fair bit of research into that sort of stuff in the context of operating systems recently (Singularity, JamesM's Horizon project) - you might want to read up on it.

Hi,

DavidCooper wrote:

Brendan wrote:Mimicking the kernel API from another OS is the easy part. ... Basically, mimicking the kernel API alone is probably around 2% of the work you'd need to do to emulate a different (sufficiently complete) OS.

I've probably wildly underestimated the difficulty, though I was imagining that it would be possible for for a whole bunch of OSes in the early stages of development to try to create a standard system for running applications which aren't hugely demanding in terms of the range of ways in which they interact with the OS.

Getting people to agree on the design of a new standard wouldn't work - the more people that are involved the more different opinions there are and the more time you spend disagreeing; and every disagreement is a potential reason for people to stop being involved. If you can find a small group of OS developers that happen to agree on most things and you manage to convince them to cooperate, then it'd make far more sense to combine your efforts on the same implementation of a single OS rather than working on different implementations of the single OS.

However, you might have limited success if you (for e.g.) chose to use a subset of POSIX. That way there's an upgrade path (full POSIX) and more importantly there's only one decision for everyone to agree/disagree with (to use it or not) rather than thousands of decisions.

DavidCooper wrote:As soon as A.I. reaches human level, it will leave us miles behind just through the speed at which it gets things done and through its inability to underperform or make mistakes through tiredness, boredom, laziness or whatever, so it will be able to translate all apps to run on any system (if the hardware is up to it).

If humans can design an A.I that is smarter than humans, then that A.I would be smart enough to design an A.I that is smarter than itself, and eventually (after several iterations) you end up with with a super-smart A.I. From the super-smart A.I.'s perspective, humans would be morons, and it would treat us like pets and do it's own thing (not what we asked it to do). After a while humans would get annoyed and resist, and form a militia, and the A.I. would send a very advanced robot from the future to kill the militia's leader.

DavidCooper wrote:I'm not going to discuss my A.I. work here or even give you a prediction of when humal-level A.I. will be available. All I will say is that I'm a linguistician who has worked in generative semantics for a very long time, breaking down all the most important words in language to the point where they can be expressed solely through fundamental components of meaning - that allows you to translate any wording of an idea into any other form of wording of the same idea such that a database can be put together in which any idea can be compared with any other idea in the database with precision (leading to elimination of contradictions in the data by determining much of the data to be probably false, elimination of contradictions being the road to understanding). Most generative semanticists gave up this work decades ago because it was seen as an impossible task. I didn't know that when I started my work on this as a child (my original aim being to create a perfect artificial language), so I just got on with the "impossible" work until I got to the point where instead of the complexity continuing to increase (as it had done for many years), it started to decrease and everything began to mesh together neatly. I then learned to program and wrote my OS to use as a platform for doing my AI work on (which was quicker than trying to learn how to wrestle with someone else's complex programming environment).

Um, you built a language translator? That's nice (because the existing language translators mostly suck). I thought you we're talking about an A.I. capable of programming, not something that might be able to (for e.g.) convert C source code for a specific OS into functionally equivalent Pascal source code for the same OS.

For fun, write a tiny "printf("Hello world\n");" console application in C, and see if your language translator can convert this into C source code for an event driven dialog box (for KDE or Gnome or Windows) that actually works. It should be "easy" for a language translator to convert C source code into C source code...

DavidCooper wrote:Because that work takes up most of my time, I don't have a lot of time left to put into adding more capability to my OS of the kind needed for doing other kinds of A.I. experiments (involving vision, hearing and robotics), and that's why I'm looking to see if there are any easy shortcuts to getting more hardware working with it which might allow me to get things done without wasting effort by going down wrong paths

The easiest shortcut to getting a lot more hardware working is to slap a thin abstraction layer on top of an existing OS. If you only want to do A.I. experiments, then maybe writing an OS is "wasting effort by going down wrong paths".


Cheers,

Brendan

Brendan wrote:If humans can design an A.I that is smarter than humans, then that A.I would be smart enough to design an A.I that is smarter than itself, and eventually (after several iterations) you end up with with a super-smart A.I. From the super-smart A.I.'s perspective, humans would be morons, and it would treat us like pets and do it's own thing (not what we asked it to do). After a while humans would get annoyed and resist, and form a militia, and the A.I. would send a very advanced robot from the future to kill the militia's leader.

Yeah, that wouldn't work, his mother would protect him.

If humans can design an A.I that is smarter than humans, then that A.I would be smart enough to design an A.I that is smarter than itself, and eventually (after several iterations) you end up with with a super-smart A.I. From the super-smart A.I.'s perspective, humans would be morons, and it would treat us like pets and do it's own thing (not what we asked it to do). After a while humans would get annoyed and resist, and form a militia, and the A.I. would send a very advanced robot from the future to kill the militia's leader.

No words needed:




Now, in all seriousness, you sound like a big fantast, making big claims about things without apparently being aware of the many common conceptions found in the computer science industry. You just make the statement "I'll just do it" and being extremely secretive about how things work. In fact, when it comes to details I've seen you discuss natural language parsing and computer vision. Those are well defined applications within computer science. They have in and of themselves *nothing* to do with the kind of sentient intelligence you expect to see of A.I.

Add to that your low post count and lack of references, this thread is beginning to look like an elaborate practical joke. Have fun

Hi pcmattman,

pcmattman wrote:Why bother? Nothing would set apart that "bunch of OSes" - they'd all essentially be clones of each other because everything that makes an OS unique would have to be the same. If anything was different, the behaviour of an application may not be consistent across all of the systems... Not to mention the difference between, say, a micro and monolithic kernel.

What makes my OS unique is the system for programming and building apps in such a way that they become part of the OS. The normal way of running apps is left completely free to be made compatible with someone else's OS. If someone else has built something similar which is based around some other programming method, it might make perfect sense for two such OSes to share the same system for apps running outside the OS while having their own unique system for apps running within it. It appears that none of you have that kind of design for your OS, so it looks as if nothing will happen.



Hi Brendan,

Brendan wrote:Getting people to agree on the design of a new standard wouldn't work - the more people that are involved the more different opinions there are and the more time you spend disagreeing; and every disagreement is a potential reason for people to stop being involved. If you can find a small group of OS developers that happen to agree on most things and you manage to convince them to cooperate, then it'd make far more sense to combine your efforts on the same implementation of a single OS rather than working on different implementations of the single OS.

Well, now that I've had some feedback from quite a few of you about the idea, it looks as if it will go nowhere, so it's more a case now of leaving an open invitation to people who might come along with the same idea and with an OS which could be made compatible to some degree without damaging the point of their OS project. Mine wouldn't be damaged by making it compatible with someone elses OS, and theirs might not be damaged either.

However, you might have limited success if you (for e.g.) chose to use a subset of POSIX. That way there's an upgrade path (full POSIX) and more importantly there's only one decision for everyone to agree/disagree with (to use it or not) rather than thousands of decisions.

That does sound like a good option.

If humans can design an A.I that is smarter than humans, then that A.I would be smart enough to design an A.I that is smarter than itself, and eventually (after several iterations) you end up with with a super-smart A.I. From the super-smart A.I.'s perspective, humans would be morons, and it would treat us like pets and do it's own thing (not what we asked it to do). After a while humans would get annoyed and resist, and form a militia, and the A.I. would send a very advanced robot from the future to kill the militia's leader.

A.I. wouldn't want to do anything: it would simply do what it's programmed to do. As for it becoming more and more intelligent, it isn't clear that it would be able to become any more intelligent other than by thinking faster. As soon as it can apply ordinary reasoning to all ideas, it will have the ability to think to enormous depth through complex issues and to solve problems that people can't, but it isn't necessarily going to come up with new or improved methods of reasoning. If it runs the wrong system of computational morality, such as one based on a religion, it will obviously kill everyone for breaking silly laws, but if it runs a rational formula for morality based on minimising harm (but without being allowed to do so by eliminating us) it will protect us all instead.

Um, you built a language translator? That's nice (because the existing language translators mostly suck). I thought you we're talking about an A.I. capable of programming, not something that might be able to (for e.g.) convert C source code for a specific OS into functionally equivalent Pascal source code for the same OS.

It's not about translating from one language into another, although that should automatically follow as an intelligent machine should be able to learn other languages in minutes. The translation I was talking about is translation within a language of the kind required to recognise that "why don't metal boats sink" and "how come iron ships float" are asking almost exactly the same question. We recognise that straight away because we translate sentences into thoughts where the differences in wording are eliminated as much as possible. A machine has to be able to do the same kind of translation if it is to be able to compare all the ideas fed into it. If you type "Why don't metal ships sink?" into Google, one of my pages will appear high up the list of results, but word the question in any other way and you won't see it. That is because Google doesn't translate ideas into different forms - it just works with words at the most superficial level. My page appears in the search results with one particular wording largely because that exact wording is the title of my page. The superficial manner in which Google analyses pages (i.e. without understanding) results in my page perhaps appearing above other people's superior pages on the same subject just because a particular wording has been typed into Google by someone doing a search, and long lists of possibly inferior pages appear above mine if some other wording is used. For intelligent search, you need a machine to be able to translate and recognise that all the different possible wordings are asking the same question, and then the results will look the same regardless of which version you type in, and the pages which give the best answers will be at the top. Of course, when you get to that level of machine intelligence, the machine won't need to search but will simply tell you the answer to your question directly and ask if you want to know more. Intelligent search will hide most Web sites from people and most of them will disappear.

For fun, write a tiny "printf("Hello world\n");" console application in C, and see if your language translator can convert this into C source code for an event driven dialog box (for KDE or Gnome or Windows) that actually works. It should be "easy" for a language translator to convert C source code into C source code...

The first target is to get it to talk sense in a single language (not a programming language). Once it can do that, It should be able to learn how to program in different ways and to translate programs if it's properly intelligent.

The easiest shortcut to getting a lot more hardware working is to slap a thin abstraction layer on top of an existing OS. If you only want to do A.I. experiments, then maybe writing an OS is "wasting effort by going down wrong paths".

The point of writing the OS was to create a programming environment in which I could do my A.I. work without having to fight with other people's complex systems. It also has to run within the OS so that it can see everything you're doing on the machine just by reading through memory. If I tried to do it within Windows it would be stuck in a cage and unable to see out. The stuff I'd like to add for other kinds of A.I. work could be done on any OS, but the way I program within my own OS is so much easier for me and so much faster than other systems that doing a bit more work to add the required capability could pay off fairly quickly. The only reason I've discussed this here is to see if anyone else is looking to do the same kinds of thing with their OS, in which case there could be an opportunity to work together to achieve the same ends for both or all those OSes in a fraction of the time. If no one else's plans fit in with that, that's fine - nothing is lost by asking.



Hi Combuster,

Now, in all seriousness, you sound like a big fantast, making big claims about things without apparently being aware of the many common conceptions found in the computer science industry. You just make the statement "I'll just do it" and being extremely secretive about how things work. In fact, when it comes to details I've seen you discuss natural language parsing and computer vision. Those are well defined applications within computer science. They have in and of themselves *nothing* to do with the kind of sentient intelligence you expect to see of A.I.

I don't expect to see any sentient intelligence in A.I. - there will be nothing conscious in the machine capable of sentience. The whole business of being able to translate an idea from one wording to any other wording of the same idea is absolutely key to A.I. - you can't apply reasoning to ideas that are expressed in different ways if you can't convert them into compatible forms. A machine has to be able to understand what all words mean, translating them into simpler components until there are no simpler components left to translate to. To get to the point where you can build a system capable of human-level thought, you have to analyse thousands of words to work out what they actually mean in terms of simpler words, avoiding all cases of circular definition. This work is unbelievably hard, but it can be done. Initial definitions are easy to make, but you quickly get to words which don't split readily at all, and unless you split them into their components (or unless you've reached a fundamental concept that can't be split) your A.I. system's going to get stuck because it won't be able to compare all of its data properly. This isn't just about parsing, but it involves deep componential analysis which goes way beyond anything I've seen published by anyone working in linguistics (though no one in their right mind would publish such work as it's too valuable to give away for free).

The vision thing is not essential for making a computer intelligent (as blind people are clearly of normal intelligence even if they've never seen anything), but we want computers to be able to recognise items in images and patterns of changes which can be identified as nameable actions. A machine should be able to see events happen and generate information representing what it has seen which can then become part of the knowledge stored in its database - it goes way beyond just identifying objects and fitting names to them. For a machine to identify an assault taking place in the street it will need to convert data to a form that can be compared fully with all other data about similar events, so you have the same need to convert everything to fundamental components of meaning. Intelligent thought doesn't have to be done at the most fundamental level, but to translate data into usable forms it will often be necessary to analyse it to a deep level before rebuilding it into a higher-level translated form compatible with other data which it needs to be compared with.

Add to that your low post count and lack of references, this thread is beginning to look like an elaborate practical joke. Have fun

If everyone thinks it's a joke, that's fine by me. But someone may know enough to recognise that everything I've said is absolutely on the ball, and if so, it might lead to some useful collaboration. It appears that there is no one else here at the minute doing the kind of work that would lead to that happening, so this thread can probably be allowed to go into hibernation until such a person turns up (which may be never).



Thanks to everyone for your input to this thread - you've given me a much clearer idea of where I should be going with developing my OS, and the result is that I've decided to put compatibility with other OSes on the back burner and concentrate on working out how to add the few bits of capability that I most want to add to it by whatever route looks the quickest. If I need help with that, I'll ask in other threads.

The subject wrote:Can you run your apps on each other's operating systems?

Since we develop OS's, the question should possibly be "Can you run other people's apps on your operating system? The answer to this is, I suspect in some cases, "yes".

In my case I'm trying to follow Posix enough that I can use dash and the coreutils. So far I have got dash running and coreutils almost compiling.

The original subject makes me imagine more a compatible binary - the binaries on your OS can run on mine without recompilation. This is why I brought up Java.

gerryg400 wrote:

The subject wrote:Can you run your apps on each other's operating systems?

Since we develop OS's, the question should possibly be "Can you run other people's apps on your operating system? The answer to this is, I suspect in some cases, "yes".

If you reword the question as you have done, then yes - compiling from source counts. If you are implementing POSIX, the apps that run on your operating system would likely run on mine and several others here, but there would be an intermediate compile step first unless by some miracle you implement system calls exactly the same as me.

DavidCooper wrote:Of course, when you get to that level of machine intelligence, the machine won't need to search but will simply tell you the answer to your question directly and ask if you want to know more. Intelligent search will hide most Web sites from people and most of them will disappear.

The issue here is that a machine intelligence like this would only have raw web pages to feed it. It could work for searches, assuming the overhead on processing is not too much, but not for "simply telling you the answer." How would it know which sources are right? If web pages become obsolete, where would its information come from? How could this ever possibly replace something like a forum, or a opinionated blog?

There's a reason Wolfram|Alpha is nothing more than a free CAS system.

I admit that, based on your explanation, your idea does seem reasonable; of course, I don't know much about linguistics. If language could be efficiently converted into an unambiguous form, clearly AI would become quite effective at manipulating it. The main problem is your apparent disconnect with reality: you present such a technique (assuming you even have it) as a panacea, even though it would be ineffective even at things you've mentioned, like driver writing and virus detection. Not to mention that computers simply don't (and, if trends hold, will not for decades) have the computational resources of even a single human, while billions of cheap human minds are at the world's disposal.

To point out some of your recent mistakes:

I don't expect to see any sentient intelligence in A.I. - there will be nothing conscious in the machine capable of sentience.

And there is any in humans? What would it be?

For intelligent search, you need a machine to be able to translate and recognise that all the different possible wordings are asking the same question

That's a functional specification of a system. One that can be implemented with "dumb" logic.

Deliberate on this: A system is not intelligent unless it can give the wrong answer, even when it has sufficient knowledge (not information!) to give the correct answer.



In other words: using AI to mean any smart-looking method is not what is meant by the term, even though many such methods have been created in quest for true AI. How do any of your "features" survive the Turing test?