Looking for Linux distro developers, testers

[Calum]

This idea is better than all of you put together.

fuck you too!

i suppose this is your idea of the sort of thing people say to convince others to help them?

[Orethrius]

fuck you too!

i suppose this is your idea of the sort of thing people say to convince others to help them?

*laughs*

Welcome back, Calum, where ya been?  

[Calum]

on holiday playing music actually!

but i do like to pop in here every now and again to keep up with what's going on! :-D

[WMD]

Bad news:
http://www.activestate.com/Products/Komodo/

Somebody has already taken the name Komodo and associated it with a $300 price tag.  And their logo is awesome, even if they don't display it properly on the website.

This has been around for ages, actually, and even featured on Slashdot.  I wonder why solo never picked up on that.

[ksym]

Me and murdock have been working on a project for quite awhile (since before I left MES in fact) dealing with creating a modern .NET operating system around the base GNU/Linux toolchain and standard libraries. If you're a developer who knows C# or a .NET language and are interested in the project, we'd be very interested in facilitating your tinkering.

Testers as well, because the first test release is around the corner

Website for the project / the company centered around the project: http://www.komodoware.com/

(eh, its a long shot there are any devs at MES but who knows nowadays)

Are you gonna separate base-system from the other applications?

One idea would be that no software should be allowed to install under /usr: all should go either to /opt or /usr/local ...

That .NET integration sound cool tho. Maybe the best idea anybody has had for ages ...

But please change the name! Komodo sounds like some japanese child's toy or sumthin' ;P

[solo]

I was aware of Komodo, right after we picked the name and we have changed the name several times already. I don't think it's a concern really because thats a developer environment for scripting languages and we're an operating system. Even if they complain we may be able to make them happy with a link on our site depending on their viewpoint...

That's really why I didn't change it: because our products aren't in the same market. Here's ActiveState's Komodo trademark text (US Trademark 78047640):

C 009. US 021 023 026 036 038. G & S: software that is downloadable and available on CD-ROM for use as a graphical user interface for developing and deploying software scripts, components, and applications. FIRST USE: 20000524. FIRST USE IN COMMERCE: 20000524

Our development environment for the Komodo operating system is not part of the base Komodo operating system and is as of yet unnamed. I'm sure I'll find a shnazzy name that does not resemble Komodo at all

Of course if they do have a problem they can send me an email and we'll quickly begin thinking up a new name.

[solo]

This sounds like exactly the type of thing I have been waiting to happen/planning. That is great news.

Thanks, glad to see there are others

I will take part as much as possible, I know C#, just not very well. I could get back into it for something this awesome.

Keep learning it and my AIM is nextwavesolo, email xfurious2gmail.com. There is a *lot* of stuff to do using C#. Our Emotion toolkit for one.

Are you gonna separate base-system from the other applications?

Yes, Komodo is set up like this already. You mean putting user-installed applications
under one area where administrator users are god, and having the system software in a seperate tree where root is god and no one else has write access. Standard komodo has /Software for user software and /System/Software for system software. also /Users/Fury/Software and /Network/Software. The structure is based on Apple's filesystem design but the layout (as in the names which represent "Software" and "System" and "Prefs") is all switchable so that we can create a few different layout definitions for normal Linux, Windows, Komodo, OS X, OS 9 etc. Whatever Emotion supports.

One idea would be that no software should be allowed to install under /usr: all should go either to /opt or /usr/local ...

Yes see above, we've changed the layout to be more modern but the concepts are retained. Except more like no software in /bin, /lib and the software in /usr is a group of packages called bundles.

That .NET integration sound cool tho. Maybe the best idea anybody has had for ages ...

I think Mono and .NET on Linux is going to be the final hand up Microsoft's ass. They've been full of momentum for moving toward managed computing and continue when they trot towards Longhorn, and if they continue, they won't be able to escape the cross-platform implications of it. And even if they do through some non-interoperability or legal situation we still have the Mono codebase which could be changed so as to not cause problems patent/IP-wise.

Beyond the crack-in-the-nuts for Microsoft, we've gained a beautifully modern cross-platform runtime that will give us the interoperability that Linux needs. In my opinion I don't think Linux will survive without either Mono or some other major change in GNU/Linux itself to solve ABI problems. The fact that open source C libraries must deal with ABIs in the first place is unbefitting for it. Why, because it's open source and with open source things are more public and change is more common. With a platform that allows us to make these changes we don't have to hold  ourselves back as much as we did before. I mean things still need to be compatible but the extra fuzziness helps the pieces fit better.

But please change the name! Komodo sounds like some japanese child's toy or sumthin' ;P

If it's really necessary, maybe we'll do a name contest or something

[ksym]

Yes, Komodo is set up like this already. You mean putting user-installed applications
under one area where administrator users are god, and having the system software in a seperate tree where root is god and no one else has write access. Standard komodo has /Software for user software and /System/Software for system software. also /Users/Fury/Software and /Network/Software. The structure is based on Apple's filesystem design but the layout (as in the names which represent "Software" and "System" and "Prefs") is all switchable so that we can create a few different layout definitions for normal Linux, Windows, Komodo, OS X, OS 9 etc. Whatever Emotion supports.


Yes see above, we've changed the layout to be more modern but the concepts are retained. Except more like no software in /bin, /lib and the software in /usr is a group of packages called bundles.

Excellent!

This kind of system design should help us more perceptive OpenSource users/developers to stick fucked up legacy-unix design methods up GNU/Linux fanatics' asses.

Been waitin' for this kinda thing to happen for a long time now

I think Mono and .NET on Linux is going to be the final hand up Microsoft's ass. They've been full of momentum for moving toward managed computing and continue when they trot towards Longhorn, and if they continue, they won't be able to escape the cross-platform implications of it. And even if they do through some non-interoperability or legal situation we still have the Mono codebase which could be changed so as to not cause problems patent/IP-wise.

We'll see how it goes ...

I am kinda cynical though. If Komodoware is to succeed in the enterprise, you guys need a good userbase to embrace your "prodigy creation" ... and even if Komodo-runtime gains some fame, Microsoft will just ignore it and shove their standards up the developers' rectals with their megabillion budget. Kinda scary ...

I just hope Microsoft makes a critical mistake in the future, so that other (free) .NET/MONO projects could get their piece of the dotnet-cake.

Beyond the crack-in-the-nuts for Microsoft, we've gained a beautifully modern cross-platform runtime that will give us the interoperability that Linux needs. In my opinion I don't think Linux will survive without either Mono or some other major change in GNU/Linux itself to solve ABI problems. The fact that open source C libraries must deal with ABIs in the first place is unbefitting for it. Why, because it's open source and with open source things are more public and change is more common. With a platform that allows us to make these changes we don't have to hold ourselves back as much as we did before. I mean things still need to be compatible but the extra fuzziness helps the pieces fit better.

Agreed. Though i remind you that most GNU/Linux users don't just "give a fuck" when talking about ABI interoperability, since they just install their apps from some monolithic collection of precompiled/pre-ported packages designed for the One-And-The-Only distro they support.

This "blindness" is why I really hate when some lazy ass users join the GNU/Linux community just to use the system, at the same time blaming Linux being too "restrictive" or "incomplete" if they can't just install stuff by clicking setup.exe ... I wish all the new users joining "our cause" would be hard-boiled hackers, willing to spend sleepless nights by implementing some missing features or creating new solutions to common problems (like you guys created Komodo runtime).

If it's really necessary, maybe we'll do a name contest or something

Ooh, that would be so lovely

Hey i got a proposition for the runtime component collection:
instead of Komodo you could use the word "Monolith".
Mono = like the Mono runtime which is the base
and Monolith is a stylised short form for "monolithic" which means something "whole" and "well organized" (if i recall right).

Hmm, maybe this kinda name would be too hackerish ... heh

Anyway if ya do the name contest, I'll put this proposition there

And now some (stupid/noobish) questions:
How much slower are the Mono-executables compared to binaries compiled as native binaries?

I know that the half-binaries produced with mono/.NET-compiler can be pre-compiled to be native binaries, but does this process speed up the executables enough, so that one could implement kick ass games with the Mono framework (for example)?

Are mono-executables/libraries automatically runtime-relocatable? eg. the developer could call something like the Win32 getModuleDirectory() to get the executables/librarys runtime location in order to load all static data?

[Jenda]

[comment=linguistic&uninvolved][rant]
mono - one
lithos - stone
A monolith is a single-stone monument erect by an ancient civilisation. Like the ones on Easter Island. Monolith at dictionary.com
[/comment][/rant]

[Kintaro]

Generally Mono and .NET binaries run pretty fast once everything has cached and compiled. It certainly is slower than a native binary and starting up, however it blows Java out of the water.

[Refalm]

Generally Mono and .NET binaries run pretty fast once everything has cached and compiled. It certainly is slower than a native binary and starting up, however it blows Java out of the water.

The whole idea behind .NET is stolen from Sun JAVA.

However, I must agree that .NET is faster than JAVA. JAVA is pretty much succesful, even though it still slow to this date.

The only thing making it faster is the fact that more people have 1 GB RAM in their computers these days.

[Kintaro]

A lot of ideas adopted and innovated in Java were used in .NET and the C# programming language, however the C# programming language and the way MSIL works has innovations that make it far better than Java.

[solo]

Excellent!

This kind of system design should help us more perceptive OpenSource users/developers to stick fucked up legacy-unix design methods up GNU/Linux fanatics' asses.

Sure...

Been waitin' for this kinda thing to happen for a long time now

Well thanks, hope you end up helping us out

We'll see how it goes ...

I am kinda cynical though. If Komodoware is to succeed in the enterprise, you guys need a good userbase to embrace your "prodigy creation" ... and even if Komodo-runtime gains some fame, Microsoft will just ignore it and shove their standards up the developers' rectals with their megabillion budget. Kinda scary ...

Microsoft is gonna be gone, if not by the hands of us, then by the hands of Apple, who is only getting more powerful.

I just hope Microsoft makes a critical mistake in the future, so that other (free) .NET/MONO projects could get their piece of the dotnet-cake.

What I'm saying is Microsoft already made the critical mistake. They already gave us a way to get a piece of the dotnet cake. Even if they introduce new APIs (they are with Longhorn) we will still make an open version now that Microsoft gave us the base platform. These Longhorn Linux APIs don't have to be centralized: they can be optional and available when needed by a Longhorn .NET app is run on Linux.

Agreed. Though i remind you that most GNU/Linux users don't just "give a fuck" when talking about ABI interoperability, since they just install their apps from some monolithic collection of precompiled/pre-ported packages designed for the One-And-The-Only distro they support.

Good for them! I hope that works out for them. Perhaps they'll send me a post card if everything goes well?

This "blindness" is why I really hate when some lazy ass users join the GNU/Linux community just to use the system, at the same time blaming Linux being too "restrictive" or "incomplete" if they can't just install stuff by clicking setup.exe ... I wish all the new users joining "our cause" would be hard-boiled hackers, willing to spend sleepless nights by implementing some missing features or creating new solutions to common problems (like you guys created Komodo runtime).

Well thanks for the kind words, and your right about Linux users who complain about that stuff, they should try one of the more risque distributions (like Komodo or GoboLinux)

Ooh, that would be so lovely

Hey i got a proposition for the runtime component collection:
instead of Komodo you could use the word "Monolith".
Mono = like the Mono runtime which is the base
and Monolith is a stylised short form for "monolithic" which means something "whole" and "well organized" (if i recall right).

Not a bad idea, but Emotion should run on several .NET runtimes including Mono and MS.NET.

Hmm, maybe this kinda name would be too hackerish ... heh
Anyway if ya do the name contest, I'll put this proposition there

Yeah idk, people use monolith to describe slow outdated code a lot. Definitely submit it if we have a contest though.

And now some (stupid/noobish) questions:
How much slower are the Mono-executables compared to binaries compiled as native binaries?

[fury@komodo KomodoSource]$ ./SpeedTest   # thats GCC-compiled native ELF
46566 operations in one second
[fury@komodo KomodoSource]$ ./SpeedTest.exe   # thats C# compiled CIL code
285138 operations in one second.
[fury@komodo KomodoSource]$

Yeah with this test, Mono seems to perform better than GCC! Lol, no that was just the first result I got. Funny though. It's more like 600k for GCC and 300k for Mono. Of course that's just one test though. The speed of CLI executables will only get faster
as the code generated by Mono's JIT compiler gets better. That's the part that converts CLI code into native code and runs it. Mono does not interpret it's executables by default, but interpreting is aavailable with the "mint" program (dunno how it's useful though)

The C code for the test:

#include
#include

int main()
{
   time_t start = 0;
   time_t end = 0;
   int result = 0;
   
   start = end = time(NULL);
   int x = 1;
   
   while (end == start) {
      int i = x * x;
      x *= 2;
      ++result;
      end = time(NULL);
   }
   
   printf("%d operations in one second\n", result);
}

The C# code for the test:
using System;

public class Whatever {
   public static int Main()
   {
      DateTime start = DateTime.Now;
      int result = 0;
      int i = 1;
      while (start + new TimeSpan(0, 0, 1) > DateTime.Now) {
         int x = i * i;
         i *= 2;
         ++result;
      }
      Console.WriteLine(result + " operations in one second.");
      
      return 0;
   }
}

I know that the half-binaries produced with mono/.NET-compiler can be pre-compiled to be native binaries, but does this process speed up the executables enough, so that one could implement kick ass games with the Mono framework (for example)?

They aren't half-binaries, they are completely CLI bytecode (platform-independent). One executable will work with all platforms. Kick ass games: Yes, this is already possible, the speed of executables is fairly good and the Tao APIs provide .NET bindings for OpenGL, OpenAL, SDL, DevIL, Cg shaders, etc.

Are mono-executables/libraries automatically runtime-relocatable? eg. the developer could call something like the Win32 getModuleDirectory() to get the executables/librarys runtime location in order to load all static data?

[/QUOTE]

Yes the libraries and files are relocatable, and yes you can easily access the paths regarding your application (like where it lives, etc). Libraries which are referenced by assemblies (.NET lingo for executables) are searched for by Mono, and use the MONO_PATH variable for that

[Kintaro]

I have been looking through the Emotion source code and I like what I see. I will try building it soon.

[solo]

Great, I'm excited to hear people are looking through it! I'll update it soon: the code is getting multiple graphics backends right now.