Operating Systems > Linux and UNIX
Looking for Linux distro developers, testers
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:
--- Quote ---
This sounds like exactly the type of thing I have been waiting to happen/planning. That is great news.
--- End quote ---
Thanks, glad to see there are others
--- Quote ---
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.
--- End quote ---
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.
--- Quote ---
Are you gonna separate base-system from the other applications?
--- End quote ---
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.
--- Quote ---
One idea would be that no software should be allowed to install under /usr: all should go either to /opt or /usr/local ...
--- End quote ---
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.
--- Quote ---
That .NET integration sound cool tho. Maybe the best idea anybody has had for ages ...
--- End quote ---
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.
--- Quote ---
But please change the name! Komodo sounds like some japanese child's toy or sumthin' ;P
--- End quote ---
If it's really necessary, maybe we'll do a name contest or something
ksym:
--- Quote from: solo ---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.
--- End quote ---
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 :)
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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).
--- Quote ---If it's really necessary, maybe we'll do a name contest or something
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version