Re: 2.7 (=~e)
Everyone knows the next great OS will be written in Javascript :) The One True OS is just a new name for The One True Editor. And as everyone knows, it's in Lisp ^^ Happy trolling :D -- Sylvain Abélard J'ai décidé d'être heureux, c'est meilleur pour la santé. -Voltaire
Re: 2.7 (=~e)
On 2008-02-27, Sylvain Abélard [EMAIL PROTECTED] wrote: Happy trolling :D Could be more fun than sitting in front of the computer and typing crap, but the lakes are frozen.. finally.. and yet not well enough to be safe for jigging. This winter sucks. -- Tuomo
Re: 2.7 (=~e)
On 2008-02-27, Tuomo Valkonen [EMAIL PROTECTED] wrote: Could be more fun than sitting in front of the computer and typing crap, but the lakes are frozen.. finally.. and yet not well enough to be safe for jigging. This winter sucks. (Actually my dictionary is probably wrong -- they often are -- claiming jigging is pilkkiminen, and it's really just ice fishing.) -- Tuomo
Re: 2.7 (=~e)
On Thu, Feb 7, 2008 at 9:40 AM, Tuomo Valkonen [EMAIL PROTECTED] wrote: 2002-02-07 - Last release of Ion1 (it never had ds/rc/stable) 2004-02-07 - First stable release of Ion2 2008-02-07 - First stable release of Ion3 2016-02-07 - ? I can't fully blame myself for missing this post in the first place (being in a hospital and not owning a bluetooth-enabled cellphone), but it's congratulations nevertheless! Despite of the disagreements I might have posted against you, I still think I owe you some beer (not having a chance to meet in person back a while ago when I used to live in Finland). :) (Well, I doubt there's a semi-usable non-fascist platform left by then. So much does the present state of FOSS and the course it is taking suck. Although, with enough manpower, it might be possible to write a full OS in eight years. So who's signing up?-) I'm kinda on it for a while now, although not nearly as ready for anything yet. Still, this post gives me sort of an ass kick, therefore I'd like to continue this conversation more subject-wise, like collecting ideas and opinions and with a higher seriousness than that of hey, I'm writing a new operating system, it'll be mostly like linux, except for I'm the author approach that I can possibly call for. Thanks for bringing this up. -- wit beyond measure is man's greatest treasure
Re: 2.7 (=~e)
To summarise: Return the low-level. Remove the mid-level. Add the high-level. I think it is impossible to avoid the mid-level because in the near future there will be a lot of platforms which are differs on a hardware level (e.g. mobiles, desktops, computing nets, brain chips etc), and a lot of low-level OSes on it. We need a kind of an API-buffer like .NET for portability of a software. So the point of application of kernel development will shift to development of a kernel of that API-buffer, IMHO.
Re: 2.7 (=~e)
On 2008-02-08, Evgeny Kurbatov [EMAIL PROTECTED] wrote: I think it is impossible to avoid the mid-level because in the near future there will be a lot of platforms which are differs on a hardware level (e.g. mobiles, desktops, computing nets, brain chips etc), and a lot of low-level OSes on it. We need a kind of an API-buffer like .NET for portability of a software. So the point of application of kernel development will shift to development of a kernel of that API-buffer, IMHO. Low-level doesn't mean completely unportable/hardware-level. Just very low abstraction level, just like C. High level by contrast is very high abstraction level. hardware or ultra-low-level = asm / port-poking / use the source low-level = C / exokernel / decent config files mid-level = C++ / linux megamonolith / wimpshit high-level = Haskell / high level services on top of a low-level or mid-level kernel ... or Haskell :) / just doing the right thing Or something like that. Obviously the level depends on the perspective. -- Tuomo
Re: 2.7 (=~e)
On 2008-02-07, Roy Lanek [EMAIL PROTECTED] wrote: 2002-02-07 - Last release of Ion1 (it never had ds/rc/stable) 2004-02-07 - First stable release of Ion2 2008-02-07 - First stable release of Ion3 2016-02-07 - ? Well-well, Euler aside it's entertaining to see that this stable release of Ion occurs simultaneously with the begin of the year of the ... rat [mouse] :) Other coincidences include the death of one empire and the birth of another http://en.wikipedia.org/wiki/February_7 1990-02-07 - Collapse of the Soviet Union: The Central Committee of the Soviet Communist Party agrees to give up its monopoly on power. 1992-02-07 - The Maastricht Treaty is signed, leading to the creation of the European Union. -- Tuomo
Re: 2.7 (=~e)
On Thu, Feb 7, 2008 at 12:40 AM, Tuomo Valkonen [EMAIL PROTECTED] wrote: 2002-02-07 - Last release of Ion1 (it never had ds/rc/stable) 2004-02-07 - First stable release of Ion2 2008-02-07 - First stable release of Ion3 2016-02-07 - ? (Well, I doubt there's a semi-usable non-fascist platform left by then. So much does the present state of FOSS and the course it is taking suck. Although, with enough manpower, it might be possible to write a full OS in eight years. So who's signing up?-) Thank you Tuomo, I've just finished compiling and installing the stable release and nothing broke ;) I'll wait patiently for the 2016 release. Thanks again. Regards, - Jorge
Re: 2.7 (=~e)
2002-02-07 - Last release of Ion1 (it never had ds/rc/stable) 2004-02-07 - First stable release of Ion2 2008-02-07 - First stable release of Ion3 2016-02-07 - ? Well-well, Euler aside it's entertaining to see that this stable release of Ion occurs simultaneously with the begin of the year of the ... rat [mouse] :) Other coincidences include the death of one empire and the birth of another http://en.wikipedia.org/wiki/February_7 1990-02-07 - Collapse of the Soviet Union: The Central Committee of the Soviet Communist Party agrees to give up its monopoly on power. 1992-02-07 - The Maastricht Treaty is signed, leading to the creation of the European Union. It's not the same kind of coincidences. The Chinese new year doesn't occur at the same date modulo one year ... examples: Chinese new year dates 2005 - Feb. 9 2006 - Jan. 29 2007 - Feb. 18 2008 - Feb. 7 2009 - Jan. 26 2010 - Feb. 14 2011 - Feb. 3 2012 - Jan. 23 while on both 1990-02-07 and 1992-02-07 there was no Ion yet. By the way, to use wikipedia.org on geopolitics in general, and on the former Soviet Union in particular, is like to use the Vatican as reference for telling on ...?! the 'position of the lotus'; Microsoft on Ion; and Wander [Switzerland] of the chocolate beverage Ovomaltine on the Russian vodka Stolichnaya. Moreover: good luck--but hey: good riddance--to call the *creation* of the EU [perhaps incorporated Europe?] the birth of an empire. Cheers, /Roy -- S anjing menggonggong, kafilah tetap berlalu S . s l a c k w a r e SS the dogs are barking, the caravan moves on S + linux SS [illustrates useless protest, critic, or S sarcasm]
Re: 2.7 (=~e)
On 2008-02-07, Roy Lanek [EMAIL PROTECTED] wrote: By the way, to use wikipedia.org on geopolitics in general, and on the former Soviet Union in particular, is like to use the Vatican as reference for telling on ...?! the 'position of the lotus'; Microsoft on Ion; and Wander [Switzerland] of the chocolate beverage Ovomaltine on the Russian vodka Stolichnaya. Trusting the actual content of wikipedia... *shudder*. But there's some hope that they can get the date of an actual event correct. (At least the Wikipedia pages on those subjects agreed with the February_7 listing, which is better than things often are.) Moreover: good luck--but hey: good riddance--to call the *creation* of the EU [perhaps incorporated Europe?] the birth of an empire. Much lesser things are called empires. -- Tuomo
Re: 2.7 (=~e)
On 2008-02-07, Samuel Baldwin [EMAIL PROTECTED] wrote: What about the other kernel tasks? Just handled by other processes in userspace? Mostly, yes. Scheduler may need to be in the kernel. Dunno how it is in existing exokernels, but they do not e.g. include message- passing as microkernels too. That's handled by user side through the kernel-provided memory management. File systems are obviously in user space.. and programs can simply directly allocate disk pages from the kernel, if they don't care to use a file system service. (Over reboots they somehow have to remember their root pages, however. This is actually related to the orthogonal persistence of EROS.) That'd be very interesting and very cool. Abstraction is very very good. I wouldn't imagine writing an OS that wouldn't include device abstraction (for drives, at the very least). Actually, I see the lightweight exokernel as a somewhat of a return to the golden age of DOS. Device drivers can be abstracted as libraries too, when the device doesn't have to be shared, and any program can use the library. The kernel just takes care that no two processes use the device's memory space simultaneously. Now, obviously a sound server that mixes multiple streams is a useful one, as is a display multiplexer, but you don't particularly need a specific low-level driver service, but rather drivers within such much higher level services. Basically a bit like the X server presently is actually, but hopefully without its reliability problems.. (also to consider how to do DRI shit nicely while not giving any bloated and unreliable program full control of such a critical resource). -- Tuomo
Re: 2.7 (=~e)
On 2008-02-07, Samuel Baldwin [EMAIL PROTECTED] wrote: I say we start with Plan 9 From Bell Labs and work from there. They have some useful ideas, but the system stinks too much of obsolete and unix... and rats. Everything's a file... great, but could we move past text files with a proprietary syntax, and having to parse them with quick and dirty hacks? How about a more efficient standard structural _binary_ format? For all the pipes too? And the shell, kind of like Microsoft PowerShell, but better? (Instead of piping objects with a display routine among other things, piping structural data with specified stylesheet for display kind of like XML files, but without the inefficient text encoding of XML.) As for the kernel... how about an exokernel? (Or at least what I've understood it to be: basically the kernel provides only memory management, with disk pages handled analoguously like memory pages, abstracting away the actual devices. Even a lot of the memory management is on user-side, with the kernel just verifying claims, or so.) As for security, how about an object capability system (see: EROS, Coytos, CapROS) in user space outside the exokernel? And the user interface beyond the command line? Vis. And so on. I have and there must be more ideas along similar lines, and if one really started spending time thinking about it and unifying them, one might be able to come up with a very nice, clean and flexible design, intead of a random clusterfuck. -- Tuomo
Re: 2.7 (=~e)
2008/2/7, Tuomo Valkonen [EMAIL PROTECTED]: They have some useful ideas, but the system stinks too much of obsolete and unix... and rats. The stench most of us live in. But very true. Everything's a file... great, but could we move past text files with a proprietary syntax, and having to parse them with quick and dirty hacks? How about a more efficient standard structural _binary_ format? For all the pipes too? And the shell, kind of like Microsoft PowerShell, but better? (Instead of piping objects with a display routine among other things, piping structural data with specified stylesheet for display kind of like XML files, but without the inefficient text encoding of XML.) A very interesting idea.. Can't say I've touched powershell. I think idea of a XML like stylesheet for output is a good one. I'd be very interesting to see this shell. As for the kernel... how about an exokernel? (Or at least what I've understood it to be: basically the kernel provides only memory management, with disk pages handled analoguously like memory pages, abstracting away the actual devices. Even a lot of the memory management is on user-side, with the kernel just verifying claims, or so.) As for security, how about an object capability system (see: EROS, Coytos, CapROS) in user space outside the exokernel? What about the other kernel tasks? Just handled by other processes in userspace? That'd be very interesting and very cool. Abstraction is very very good. I wouldn't imagine writing an OS that wouldn't include device abstraction (for drives, at the very least). And the user interface beyond the command line? Vis. Of course we'd probably need much better user input devices. Something like a dataglove would be fantastic. And so on. I have and there must be more ideas along similar lines, and if one really started spending time thinking about it and unifying them, one might be able to come up with a very nice, clean and flexible design, intead of a random clusterfuck. Well, you can't NOT have a random clusterfuck with most OSS shit. (/me points at PHP). Not that I don't like OSS, actually, but still. -- Samuel 'Shardz' Baldwin Shardz's Igloo: shardz.homelinux.net // Down at the moment Registered GNU/Linux User #410639
Re: 2.7 (=~e)
On Thu, Feb 07, 2008 at 06:40:07AM +, Tuomo Valkonen wrote: 2002-02-07 - Last release of Ion1 (it never had ds/rc/stable) 2004-02-07 - First stable release of Ion2 2008-02-07 - First stable release of Ion3 2016-02-07 - ? (Well, I doubt there's a semi-usable non-fascist platform left by then. So much does the present state of FOSS and the course it is taking suck. Although, with enough manpower, it might be possible to write a full OS in eight years. So who's signing up?-) Here's an honest question: what language do people think the next operating system, the one that Ion users are most likely to write, will be written in? C is the default choice, but I wouldn't be surprised if it was something else... I don't have a guess, myself. I have no experience yet. What I would like to see, however, is a new language designed for the new task of writing a modern operating system. But even then, what features would this language have? If only I was wealthy, or could magically procure grants for myself. I'd love to research these questions. -- Bryan Richter aka chreekat
Re: 2.7 (=~e)
On 2008-02-07, Bryan Richter [EMAIL PROTECTED] wrote: Here's an honest question: what language do people think the next operating system, the one that Ion users are most likely to write, will be written in? C is the default choice, but I wouldn't be surprised if it was something else... C.. and then some. There's just no way around it: for any serious work you want C. Or maybe some other relatively simple language close to the hardware, with better safety... and tagged unions. (What was this one C derivative?) But the benefits of such an alternative (except for tagged unions) are not so great, because you only want to write relatively simple things in C/it. You don't want to write much abstractions in C. You do low level gruntwork of core libraries in C, provide a very simple API, and use whatever language you want with better abstractions and better safety (hence typically no dynamically-typed scripting languages, but rather e.g. Haskell), to access the services provided by the C core libraries. This is easy because the API is simple (instead of OO bloat). Non-performance critical libraries could also be written in other languages (such as Haskell), and they could provide a simple C API, but conflicting runtimes present a problem. Many languages (including Haskell, java, etc.) want to be operating systems themselves these days. Instead of using the operating system's namespace to locate their libraries, they want to impose their own module and package namespaces and hierarchies. Instead of exposing the operating system's libraries and services, and letting the program author choose either some real platform or a compatibility layer (platform), they want you to use their own compatibility layer. Megalomania pure and simple. And in exchange cross-language compatibility is reduced. For that you either you either have to write for the C runtime (i.e. the OS), or you need something like CLR (common language runtime). I think the C option could promote better API practises instead of OO-bloat. You _do_ often want to write higher-level APIs suited to the practises and mechanisms of any particular language, instead of enforcing an uniform one. Those exposing a simple easy wrappable API not dependent on the idiosyncracies of any particular language or design methodology (such as OO-bloat), should work best. -- Tuomo
Re: 2.7 (=~e)
On 2008-02-08, Tuomo Valkonen [EMAIL PROTECTED] wrote: exokernel.. C.. To summarise: Return the low-level. Remove the mid-level. Add the high-level. -- Tuomo
