.sparkymat
i had a dream…
Posted on June 12th, 2009 ~ 06:15:53 AM
Tagged as linux os programming tech |
4 Comments »
<geek mode alert!>
I have been musing a lot lately, regarding what would be the perfect operating system (IMO), or as close as it could get. Here it is, in a not-so orderly manner, various characteristics, that I would desire, in my “perfect” operating system.
Kernel
- The kernel would be a microkernel, with everything from the drivers, to applications, running in userspace.
- I liked the idea of the re-incarnation server from Minix. Throw that in as well.
- Every system-critical binary (system files/drivers) will have a stable and a current version (known stable version and latest from repository), and re-incarnation server will automatically bring up the stable if the current crashes at any point.
- Obviously, it would be a 64-bit kernel, with software emulation of 128-bit data as well (not even sure if that makes sense here).
- The scheduler would automagically schedule tasks across CPUs as available. This might necessitate a different programming paradigm than one with a single entry point at main() (be it C/C++/Java.. etc) i.e. the user doesn’t explicitly specify threads or mandate scheduling stuff. He specifies tasks and transcations. Guess this deserves a post of its own.
- A display of VGA@16-bit would be assumed to be available by default. There is no reason for a “text mode” boot with the DM switching it to a “graphics” mode later. The kernel would boot up and put the display into a VGA@16-bit mode with a graphical boot progress, with the DM switching over to a different resolution and display as and when he gets loaded. Possibly, the DM can enable the “proper” video driver on-the-fly before switching resolutions.
VM
- I personally favour Ruby over Python, but I accept that both are equally capable (with Python being more matured in comparison). That said, I still am gonna pick Ruby as the OS’s “native language”. For/against arguments for this decision are not in the scope of this discussion.
- The kernel would launch a VM, a Ruby VM, who would take care of the remaining “booting”.
- Possibly, derive inspirations from the Dalvik VM. Register-based. Opcode loading. Hmmm.. need to read up some stuff here.
- (Going against my initial impulses) application code would reside in their byte-code compiled forms, instead of .rb text files.
- Provide “compilers” for various languages which convert them to said bytecode. Python, Perl, Smalltalk, Java, Lisp etc. should be relatively easy. C, C++, Objective-C would be tougher, but possible (or so I believe).
Graphics sub-system
- A kick-ass software renderer. With the advent of multi-core CPUs, I think we could have a kick-ass software renderer. Will provide OpenGL as a wrapper over its “native” interface
Window Manager
- <many many thoughts upcoming here.. watch this space..>
System API
- Non-time critical “system” API would be exposed via IPC, possibly D-bus. E.g. audio, telephony, location, etc.
- Time-critical “system” API would be exposed via library calls onto the VM. E.g. IPC mechanisms, filesystem access, graphics (??), timers, etc.
Applications
- Applications are sandboxed. Period. You can push messages to other applications via IPC but no direct access to another applications resources are allowed. Also to be taken, caged filesystem areas for each application, as well as a global repository (more on filesystems later).
- Central software repository. Catalogue/store application. Screenshots/reviews/ratings etc.
- Delivered as opcode-binaries. Source available for any OSS applications. Closed-source also possible.
- Capabilities. As in, security mechanism. There will be various capabilities and by default, an application will have only the bare-minimum (or logical minimum). Any action to be taken which needs greater capabilities, will throw a prompt for user-permission to continue (a la UAC). The user can configure an application to be “allowed” to do stuff (see Suite settings in Application Manager.. S60 5th Edition.. for Java apps) without prompting.
This post will be constantly updated. Stay tuned.
Programming Blog
Posted on November 18th, 2008 ~ 03:00:53 AM
Tagged as linux programming ruby |
No Comments »
I have started a programming blog here.
Rubygame 3 on Ruby 1.9
Posted on April 2nd, 2008 ~ 07:23:34 PM
Tagged as game programming ruby rubygame |
2 Comments »
Creating a Ruby 1.9 sandbox
1. mkdir /home/user/ruby19 (example folder)
2. cd /home/user/ruby19
3. mkdir src
4. cd src
5. wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-1.tar.bz2
6. tar -jxvf ruby-1.9.0-1.tar.bz2
7. cd ruby-1.9.0-1
8. ./configure –prefix=/home/user/ruby19
9. make
10. make install
Now you can switch to this sandbox at any time by executing ‘export PATH=/home/user/ruby19/bin:$PATH’ in a shell.
Chipmunk Installation
Chipmunk is required for Rubygame 3
1. wget http://files.slembcke.net/chipmunk/release/ChipmunkLatest.tgz
2. tar -zxvf ChipmunkLatest.tgz
3. cd Chipmunk-4.0.2
4. cd ruby
5. export PATH=/home/user/ruby19/bin:$PATH (* switching to Ruby 1.9 sandbox)
6. ruby extconf.rb
7. make
8. make install
Rubygame 3 Installation
1. mkdir /home/user/rubygame (example path)
2. cd /home/user/rubygame
3. svn co https://rubygame.svn.sourceforge.net/svnroot/rubygame/trunk rubygame3
4. cd rubygame3/
5. export PATH=/home/user/ruby19/bin:$PATH (* switching to Ruby 1.9 sandbox)
6. cat Rakefile | sed s/PLATFORM/RUBY_PLATFORM/ > Rakefile.new;mv Rakefile.new Rakefile (* this replaces PLATFORM with RUBY_PLATFORM in the Rakefile)
7. CFLAGS=”-I/home/user/ruby19/include/ruby-1.9.0 -I/home/user/ruby19/include/ruby-1.9.0/i686-linux” rake install
8. cd ~/rubygame/rubygame3/samples/
9. ruby chimp.rb
10. Punch the monkey!! 
The Classy Struct
Posted on August 8th, 2006 ~ 08:12:20 PM
Tagged as c cpp programming |
No Comments »
So what exactly is the difference between a class and a struct in C++? After wondering and debating internally for quite a long time, I looked around the net and found the (simple) explanation that:
“The only difference between a struct and a class is in the default access.”
That is, a sruct is public by default and a class is private by default. Extending (inheriting) them is also like-wise – public inheritance for struct and private for class.
I believe struct was made public by default to be compliant with C . Thus a C struct can be used similarly in C++. i.e.
[cpp]
struct Foo
{
int bar;
char* baz;
};
Foo makeFoo()
{
Foo temp;
temp.bar = 1;
temp.baz = “test”;
return temp;
}
[/cpp]
The only reason the above code will work in C++ is because of the default access of struct being public.
Building an “include” graph
Posted on August 6th, 2006 ~ 08:08:38 PM
Tagged as programming ruby |
1 Comment »
How easy would it be to build include graphs in ruby?
Here’s my first attempt:
[ruby]
$list_of_files = Hash.new
$list_of_files.each {|node|
node = Array.new
}
def store_includes(pathname)
lines = IO.readlines(pathname)
lines.each {|line|
if line.include? “#include”
include_file = line[line.index("#include")+"#include".size,line.size]
fidx = 0
sidx = 0
if include_file.include?(“”")
fidx = include_file.index(“”") + 1
sidx = include_file.index(“”",fidx+1) – 1
end
if include_file.include?(‘< ')
fidx = include_file.index('<') + 1
sidx = include_file.index('>‘) – 1
end
include_file = include_file[fidx..sidx]
$list_of_files[pathname].add(include_file)
end
}
end
def iterate_files(pathname)
list = [] #alternate way of initializing an array
if pathname==”.” or pathname==nil
list = Dir["*"]
else
list = Dir[pathname + File::SEPERATOR + "*"]
end
list.each { |path|
if File.filetype(path) == “directory”
iterate_files(pathname)
end
if File.filetype(path) == “file”
store_includes(path)
end
}
end
[/ruby]
Any comments?
File extensions in ruby
Posted on August 6th, 2006 ~ 12:06:47 AM
Tagged as programming ruby |
1 Comment »
Is there a more efficient way to extract the file extensions in ruby? I currently do the following.
[ruby]
ext = File.basename(filepath).reverse.split(‘.’)[0].reverse
[/ruby]