Writing an entire OS?

Has anyone here ever writen an entire OS, or thought about writing one? I planing to write one from scratch in lisp based on the linux kernel. Im kind of tired on of unix like systems and windows is buggy crap too.

Another Lisp OS project?

As much as I like Lisp OSes, are you sure you want to undertake this project? OSes are reasonably large systems and creating and maintaing them are large undertakings. A large part of this includes hardware support, which means a lot of tedious work implementing drivers.

If you want to see some Lisp OSes, you could look at Symbolics's OpenGenera (proprietary, but source is available to 90% of the OS), or Movitz(BSD license) which is a baremetal Lisp implementation.

And how are you going to base it on the linux kernel? linux is written in C, and mixing too much C with Lisp kind of takes the fun out of making a pure Lisp OS, altough if you meant that you'll use the linux kernel as a reference, then that's fine.

As for you calling other OSes buggy, all major OSes are pretty stable these days (Linux, *BSD, NT(Windows' Kernel)). Some of them suffer from bloat and being grown to maintain compatibility, but that's what's needed in the real world.

Anyway, I wish you luck on your project and have fun!

/prog/ should take over the LAIN OS project

>>2
There is also http://losak.sourceforge.net/

>>3
Well, there's also a bunch of other old abandoned Lisp OSes which are open source (pre-Genera), which were made for the Lisp Machines. Some of those might be interesting to port, altough there exist emulators for running them already.

>>2
you misunderstood me: i said im tired of unix like OSes and that windows is buggy.

And i will use the linux kernel as kernel and write my own userland, i will just write a interpreter and then execute lisp scripts using the interpreter.
Linux automaticly feeds files that start with #! to the the coresponding interpreter.
Maybe i will write it one day to run on other kernels as well.

OOH IM LOOKING FORWARD TO THIS RELEASE IN 10000 YEARS TIME

>>5
Do you honestly believe you're going to be able / have the motivation to write the entire userland? Do not do this; it will take forever and you'll have nothing to show for it. If you are serious about writing an operating system, focus on the kernel and write a compatibility layer for "legacy" apps.

>>5
Soon you'll get a girlfriend and forget about this silly thing.

>>8
Soon you'll get a girlfriend and forget about this silly thing.

i expected to hear alot, but this.

you never cease to suprise me /prog/

>>8
What about me‽ Will I be getting a girlfriend soon, too?

>>8
More like she'll want all your free time.
BITCHES AND WHORES

Tired of ``unix like [sic] OSes'', so you want to base a new one off the Linux kernel?
You can't even manage to write a whole post in English. I don't think you're going to manage an operating system in Lisp.

>>10
Holy shit, interrobang in the wild! No, probably not.

>>13
No, we're all proggitors too

I wonder any of if the old home computer OS's are open source like for the C64, Atari, CP/M. It would be a good project to port one of those to a modern embedded processor like ARM or MIPS.

you can work on HURD, since that is a microkernel instead of a monolithic kernel like Linux or BSD you can work on just one module.

Also instead of working on the Linux kernel it might be more productive if you just made your own distro and used Lisp as a scripting language to handle OS tasks within the distro.

>>1
If you want something truly practical, don't bother starting your own OS. If you're doing it for pleasure, maybe you should pick up any of the other Lisp OS that have been mentioned ITT.

>>16
Im going make a a syscall function which uses int 0x80h, so it should be compatible with allmost all unix like kernels.

Then im gonna write high level system interfaces in lisp using this function.

So choosing a kernel should not be that big of a problem.

>>18
Don't forget your
(eval-when (compile eval load)
  (require :void)
  (use-package :excl.void))

>>1,18
Do you seriously plan to create a non-toy OS?

>>20
Not really, i plan on kind of doing one that works, learn as much as i can and then i see where it takes me.

For short: i dont know.

LFS [/thread]

>>5
interpreter
You're going to make everything but the kernel interpreted? Oh, wow.

>>19
Included in void.h?

>>23
RMS Michael Stallman at some point considered the idea of purely-interpreted userland for HURD -- banning all compiled code in fact. Because, you see, with interpreted languages you can't withhold the source.

And I can't even be entirely sure that this was an April Fools joke, because, after all, having undocumented, poorly designed and unpredictably changing internal interfaces is the official, written policy of GCC, I kid you not. It is supposed to prevent evil proprietary enemies of Freedom from using GCC with their proprietary backends/frontends.

>>25
I'd actually would like to see some citation(s) on that second paragraph of yours. I've seen it claimed a few times, and I've seen it happen to a few other large opensource projects, where someone I know is maintaining something which plugs into one large GPLed library and makes use of it in various ways. That coder usually complains about random changes to the interfaces every (few) months or so when they break half of his code and he has to rewrite large parts each time. While I have no idea if this is the case for GCC, I'd like to read such a policy to see if it's indeed true.

The policy is basically voided with the new plugin system.

>>26
http://gcc.gnu.org/wiki/GCC_Plugins
And some of the links from there.

I can't find the email I had in mind, where one of the GCC maintainers stated explicitly that the lack of documentation and incomprehensible, often changing interface are good things. But even in the page I've linked you can find indirect proof that this is indeed the official position (of some of the maintainers at least) that is argued against by the proponents of the plugin architecture. Like, "We gain nothing by holding infrastructure advances in GCC. While GCC still has the advantage of being widely used, its internal infrastructure is still relatively arcane and hard to deal with. We have already kicked it into the mid 90s, but we still have a lot of ground to cover. An antiquated and arcane infrastructure will only help turn new developers away." -- which means that there are people holding said infrastructure advances.

I won't search any further, the concentration of crazy there makes my mind reel.

>>27 would be voided, you wanted to say?

>>28
This is why I contribute to LLVM.

>>28
official position
some of the maintainers
I don't think you know what ``official'' means.

which means that there are people holding said infrastructure advances.
Even if it did mean that (which it obviously doesn't), that doesn't imply the conspiracy perpetrated by GPL militants hell-bent on world domination you want to see in it. It's a recognition of the fact that implementing such advances is likely a lot more effort than it's worth, particularly when the current system actually works more than adequately.
The size and importance of the GCC codebase means that fundamental infrastructure decisions can't be rushed in to just because some twit thinks things could be better.

I'm sorry, but the crazy only exists inside your own head.

>>28
Like >>30 said, GCC is already highly mature and the developers are not interested in radical fundamental infrastructure design. That would be the job of a new project (such as LLVM).

>>30
I don't think you know what ``official'' means.
I don't think you know what ``official'' means in F/OSS.

Even if it did mean that (which it obviously doesn't)
It obviously does. The discussion happened more than two years ago. The advances were held.

that doesn't imply the conspiracy
Of course it doesn't, there's no conspiracy, they say it openly: our shit is contrived and undocumented and we like it just right because we know our ways around it and we don't think that allowing outsiders to learn and modify the source is worth our trouble. Because some of the outsiders would be Proprietary Enemies, and we value blocking them off more than allowing other people in. It works "adequately", sure.

Anyway, there's nothing to argue about. Some people consider obfuscating the source (the real source, not something that gets delivered to the users) to be unacceptable for any reason, and even more unacceptable (if unacceptable had gradations) for someone who values users' freedoms. The entire discussion has no right to exist, at all, the one to propose retarding the technology to achieve some ideological goals should have been immediately laughed at, hit with piss-soaked rags, struck down and driven into the earth forthwith, for the land of the heathen to consume them. Or so do some people believe.

Some other people like RMS for instance are totally OK with intentionally doing such stuff if it could prevent unrighteousness. Like, you know, some game publishers think that it's OK to inconvenience honest users with crazy DRM to prevent pirates from thieving, and even profits are not really important here, the unrighteousness is. I understand that.

You, my friend, are pathetic because you try to sit on the fence. You don't want to go full-RMS for some reason, and invent laughable excuses. "Fundamental infrastructure decisions can't be rushed," my ass! When the very first reply to the very first post that is referenced first in the GCC wiki as the one prompting the creation of that very page is fucking this: http://gcc.gnu.org/ml/gcc/2007-11/msg00193.html

"Date: Wed, 7 Nov 2007 08:41:01 -0800". Pesky infrastructure decisions, they sure do take a long time, especially when nobody actually discusses them because it's obviously a waste of time, because RMS would not approve!

This fence you're sitting on, my nigga, comes equipped with some long, ragged-edge, anus-thirsty spikes. And your hold of it is slipping.

>>32
Conspiracies don't necessarily have to be hidden to be a conspiracy. Conspiracies don't necessarily have to be evil to be a conspiracy. For example, the RIAA have publically conspired to litigate against file sharers in court. Businesses publically conspire to provide goods and services to sells.

>>32
Cool red herrings bro.

>>30
the current system actually works more than adequately
Give me a call when MSVC or ICC don't have a 10% speed advantage anymore with comparable compiling speed.