From sonoflilit at gmail.com Tue May 9 21:16:07 2006 From: sonoflilit at gmail.com (Son SonOfLilit) Date: Wed, 10 May 2006 03:16:07 +0200 Subject: [Ros-talk] Think Ruby! Message-ID: Hello fellow Ruby hackers. I remembered ROS while I was reading the TUNES (http://tunes.org) manifesto. Immediately I thought: "TUNES, they think far ahead, to when for desktop use that isn't graphics-intensive you won't need as much as 5% of the processor time you have. So they think, let's put an OS that lets the user do everything comfortably and does most of the stuff behind the scenes so he doesn't need to. Wow. Wait, in 5 years from today such an OS will have enough CPU speed to run desktop and coding apps. So this should be done /now/. But they're using LISP for a backend. Didn't they learn the famous MIT lesson? LISP is for math graduates. And for no one else. Not for desktop users." Then I thought, "Ruby, that's a language to do stuff in." Why, whytheluckystiff proposed something that really reminds me of this, with a ruby coding environment for game consoles intended for kids. "Oh wait, wasn't there a RubyOS project on rubyforge?" So I checked your Idea Book. Now, let me confess. I am a teenager, and I'm not a very good coder. I win competitions and am considered a genius because I am a natural knowledge freak. I remember everything I pick up, and I connect everything. But I'm not good with practics - I tend to be too curious and impatient to do big things. I always move on. I am good at proposing ideas and critisizing, but don't earn hacker respect for doing things. I know how to do almost anything, but almost never did a single thing to the end. So I speak with little credentials to back me up. And yet, my thoughts: The RubyOS design you proposed is not a Ruby based OS, it is a unix with ruby as it's main tool. Anything it does, it does the unix (or rarely the mac) way. That is great. Read ESR, he shows why unix is really the best thing around. But as the TUNES people said, unix is based on system constraints and not on human constraints. Let's look at how a system designed for human beings would be. Ever played a MOO? That's a model for a futuristic OS. Everyone, soon, will learn basic programming at school. So object orienting everything to allow people to add functions and views to things and to bind everything together will improve computer use by thousands of percents. We have "Everything is an object". We have "Computers for human beings". Those are Ruby philosophy words. I believe no one has got closer to them than ruby. So if we design an OS on top of Ruby (not /alongside/, as you did - on top of), we should strive to Think Ruby - to let the Ruby philosophy show in the OS design. Here are some sketchlines: * After a Java weekend, my good friend Shai Shkolnitski said: "God is Class Object". * The kernel should run a Ruby interpreter and hardware-dependent code (some device drivers, not all). That's it. All else is in Ruby. * Like LISP machines, the Ruby interpreter /is/ the OS. * Start with a command-line. A good GUI system based on Ruby philosophy doesn't yet exist. Rails is the closest, but there's a way to go from there. * The command line, of course, is an irb. * You spoke of a file system. With stuff like resources (which unix philosophy advocates convincingly to be bad, see ESR). That's primitive. Ruby doesn't save FILES. It saves Objects. And Classes and Instances. Resources? Users just add methods to the classes. So a user could add a filter method to his low volume mp3, or, better, mix a normalizing module into class mp3 and from then on hear /all/ his mp3s on the same volume. Sharing such functions is trivial. In Ruby there is the hierarchy advantage - you can choose where to mix in and decide if it will affect the mp3, all mp3s, all sound files, or maybe all files. This is the kind of programming that future end-users will gladly do. It allows to tinker with /everything/ comfortably. So we said the hard disk holds snapshots of objects. Your IO Slaves are therefore trivial. Same for tarball transparency. Or let's look at the path shortcuts. I know from Ruby the code: color = program.goban.board[pos.x][pos.y].color Isn't it a shortcut? Variable assignment by reference is so great sometimes :-) Now, hard disk operation should be transparent: A user only sees the objects, and the HD acts as a huge swapfile to store some of them. The system saves and loads transparently so that on reboot you always return to the same state. Want to delete? Remove all the references to the object and let the garbage collector do it's thing. Versioning should be as simple as coding some versioner methods with some metaclass hacking and mixing them into the objects you want version-tracked. * User Interface - I don't like XUL. XUL is not Ruby. XUL is for computers, not for programmers. A good Ruby GUI system should yet be designed, but I envision it being usable like Log4r or maybe like Rails. * Administration - think rake. Ruby administers great. With so much metaclass hacking possibilities, maintaining a system where everything is an object would be easy as hell to automate. * Package management - I think you can metaclass hack to support automatic dependencies. If everything is in Ruby code (or Ruby bytecode - see fwd.), there's almost nothing to it. * Kernel - For now, a linux picokernel (think google://tomsrtbt) stripped of all but device drivers and a Ruby Interpreter, could do the job super. Later - some great hackers would eventually write a really good bootable Ruby Virtual Machine that would improve speed to sane levels. Fromthe TUNES faq: "Reflection is important because it is the essential feature that allows for dynamic extension of system infrastructure. Without Reflection, you have to recompile a new system and reboot everytime you have to change your infrastructure, you must manually convert data when you extend the infrastructure, you cannot mix and match programs developed using different infrastructures, you cannot communicate and collaborate with people with different background. At the technical level, all these mean interruption of service, unreliability of service, denial of service, and unawareness of progress; but at the psycho-social level, lack of reflection also means that people will have to make irreversible static infrastructural choices and close their mind to infrastructural change, and will not communicate with people having made different infrastructural choices. Reflection is a deep technical benefit, but also a deep psycho-social requirement, that allows individual progress despite historical choices by evolution of the conceptual infrastructure, and community progress despite variety of individual and unshared backgrounds by unification of infrastructures. " Ruby is natural about reflection. You can change class implementation in runtime. It is being done quite a lot by contemporary Ruby coders. I'm getting too long. http://tunes.org/papers/WhyNewOS/WhyNewOS.html explains exactly why RubyOS as a ruby vm-based OS is potentially the next-huge-thing. Remember: soon the computing power will be cheap enough. How should such a system be developed? I suggest creating a rubyos install and run boot diskette, that runs a linux shell from which you can create a partition for the ruby swapfile. Then you run an irb. When the irb is exited, it saves all it's state to the file (moderate ruby hacking, I assume?). From within it, a good text editor /must/ be included. And a way to save version-tracked modules on a centralized development server and d/l them. From there on - it's a Ruby playground to build everything needed for a modern OS in 99% ruby :-) With the Version Tracking server, developers will just submit full software or even just useful mixin modules. With time the OS will build. And /do not allow anything to run outside the interpreter/. No ``. No system(), no exec. Anyone up to the task of setting up an OS that will actually improve humanity and it's use of computers? btw notice that ruby was planned with internal threading - making the whole thing much easier. :-) Thanks Matz. From sonoflilit at gmail.com Tue May 9 21:25:12 2006 From: sonoflilit at gmail.com (Son SonOfLilit) Date: Wed, 10 May 2006 03:25:12 +0200 Subject: [Ros-talk] Fwd: Think Ruby! In-Reply-To: References: Message-ID: I want to add: There are problems with this. Ruby, in fact, isn't evolved enough to be an OS. Metaclassing syntax, especially, should be far less lingua arcana, and working with object clones should be far simpler. In fact, the requirement is that average 10 year olds could be fluent in the language using for this futuristic OS. But Ruby is the closest. And coding the OS utilities should come before designing a better language - porting should be easy. ---------- Forwarded message ---------- From: Son SonOfLilit Date: May 10, 2006 3:16 AM Subject: Think Ruby! To: ros-talk at rubyforge.org Hello fellow Ruby hackers. I remembered ROS while I was reading the TUNES (http://tunes.org) manifesto. Immediately I thought: "TUNES, they think far ahead, to when for desktop use that isn't graphics-intensive you won't need as much as 5% of the processor time you have. So they think, let's put an OS that lets the user do everything comfortably and does most of the stuff behind the scenes so he doesn't need to. Wow. Wait, in 5 years from today such an OS will have enough CPU speed to run desktop and coding apps. So this should be done /now/. But they're using LISP for a backend. Didn't they learn the famous MIT lesson? LISP is for math graduates. And for no one else. Not for desktop users." Then I thought, "Ruby, that's a language to do stuff in." Why, whytheluckystiff proposed something that really reminds me of this, with a ruby coding environment for game consoles intended for kids. "Oh wait, wasn't there a RubyOS project on rubyforge?" From dennis at lauschmusik.de Wed May 10 06:24:12 2006 From: dennis at lauschmusik.de (Dennis Oelkers) Date: Wed, 10 May 2006 12:24:12 +0200 Subject: [Ros-talk] Think Ruby! In-Reply-To: References: Message-ID: <4461BF4C.8060008@lauschmusik.de> Hello whatever-your-real-name-is, hello list, I have to thank you for your interesting and motivating mail, it gave me a lot of inspiration to start coding in that area. I hope it has the same effect on other readers of this list, and the whole project will somehow get back to life again ... Thanks! Dennis Oelkers From sonoflilit at gmail.com Wed May 10 08:31:06 2006 From: sonoflilit at gmail.com (Son SonOfLilit) Date: Wed, 10 May 2006 14:31:06 +0200 Subject: [Ros-talk] Think Ruby! In-Reply-To: <4461BF4C.8060008@lauschmusik.de> References: <4461BF4C.8060008@lauschmusik.de> Message-ID: Lo and behold! RubyOS has a new spam-free wiki! What a wonder... http://www.editthis.info/rubyos/ Dennis, You are the first to reply to my idea. I am very glad that you found it so driving, but am even gladder about the more general meaning: This idea interests people. So I set up a wiki, it being the best current way to collaboratively design known to me. It sounds so good, just a day after I propose this, to hear that someone started coding. I am dead curious to hear what kind of code you're working on. Is it the HD save code? The Linux Distro? Maybe some high level service code that the OS will grant? I would suggest, though, that we stop for a moment and consider the big picture. Not in details, just to see what we're striving for, a faint idea. With that we can code. Some thinking I've done resulted in this: It doesn't, at this stage, need to be a bootable distro. In fact, a slight mod of the ruby binary could work. We can code the OS from withing another in a Ruby session that is restrained from communicating with any part of the OS which isn't the net. The code that saves a ruby vm state to disk and restores is really important, though, to be done quick. We need to think a bit about design. For example, today interprocess comm is done using pipes and mutexes. If everything ran within the same Ruby session, I'm sure a better way would be found. We need to agree on what is a software package, and how it is executed. We need some librarian to keep all the loaded but not executed packages in memory. We need a Ruby ncurses interface that looks like Ruby a Ruby library and not an interface to a C library (I'll add an example in the end). When we design it we should already be thinking that it should have the same class interface as the GUI. We need a good way to share our code. We need urgently a mixin to class Module that allows us to ClassName.showcode and to ClassName.editcode. I'm not sure current Ruby would allow this. We need to consider security. ACLing everything would sound good at first but I'm a bit irritated by it's complexity. Perhaps adding a unix like mode bitmask to every object would suffice. I also think that's doable in 100% Ruby code. That's a very good thing. We need to consider if we want to allow non-priviledged software to extend classes (not instances) without the extensions showing to other users (I think forcing subclasses would have to be the solution, even though it's awfully not Ruby). We need to think up a way for software to be selleable profitably on our platform - a full opensource world would just not work, people gotta live outta something. I'm considering RPC, but that would be risky for buyers if the selling company falls and also quite unreliable. Nothing else pops to mind. There is a lot we need to do. Let's code to a better future! p.s. My name is Aur Saraf. Here is the example ncurses client concept: class Editor wrote: > Hello whatever-your-real-name-is, hello list, > > I have to thank you for your interesting and motivating mail, it gave me > a lot of inspiration to start coding in that area. I hope it has the > same effect on other readers of this list, and the whole project will > somehow get back to life again ... > > Thanks! > Dennis Oelkers > >