8:33 PM - (no subject)
I got some work done on the CMS. Its been an odd night. I went so far on it and realized that it will work a lot like JJ only slightly more generalized. It doesn't seem right. I'm sure it would work but its not a good generalized solution. Hell i'm writing code that belongs in apache! Stupid java. I'm half tempted to go back to C at this point. I like C and if i have to reinvent the wheel, might as well do it in a fast, portable language.
I realized why i failed with my os project. Obviously my drive crashing was the big factor, but i was just trying to fix a few problems with unix. There are a LOT of problems with unix. Its 30 years old after all. Video is the big problem.. the interface is another. I like console but its not good for the masses. Thats why OSX is the most sold unix operating system. I've always wondered something.. if you look at the process list in OSX, there is a window server but what causes the boot screen to work. If you run darwin its color and looks more polished than a regular unix terminal.. why is that? I'm wondering if they actually use the same framebuffer to draw on OSX directly. It would explain the speed and quality. Loading extensions isn't a big deal... the login screen is even layered.. thats how apple thinks.
What if one were to do the following:
Start with a bsd base: net or free...
1. keep the console driver but write an entirely new one that is a full color vesa compliant frame buffer. Don't write raw data to it during the design.. actually create an interface like the original mac os had.. Quickdraw or something beter style with a font mananager, etc. I think 1984 technology would be a big bump sadly in UNIX console land. Write a Sco, vt100 or some console driver for this thing. You could use the freebsd or netbsd code as a starting point.
2. Implement a lite window manager that can run on the console. During bootup you could use the console driver module and then lauch the window manager during stage 2. You'd never change drawing modes, just the controlling process for the display.
3. Implement a shell environment for this window manager.
Basically you'd get a cross between how i think mac os worked and maybe early windows environments except that instead of windows running on command.com, you'd actually have the window server itself as the environment. Another words native access to the operating system through the windowing environment AND you can use a shell running on the environment since its really posix underneath. It would be fast and not gay like X11. 128mb of ram is bullshit!
Since this whole damn thing is small and part of the OS it would run fast and could include OS built in menu systems, font management, copy/paste and other operations. The unix philosopy is to run a shit load of processes. Its good most of the time but there's a reason nextstep was FAST on a 25mhz processor. 8 billion programs running requires a good fucking scheduler and i haven't seen one yet. I think windows scheduler is the biggest problem with it. Run windows on an SMP system and watch what its doing sometime. Scheduling is a bitch to write.
Maybe this idea is bullshit.. i dont know.