| 1 |
Hello Enrico, |
| 2 |
|
| 3 |
I did read with interest the informations about Briegel, and the |
| 4 |
oss-qm idea. I also looked into the PDF. |
| 5 |
|
| 6 |
I like the argumentation and the overall idea of such a repository. |
| 7 |
Maybe it will work. |
| 8 |
|
| 9 |
I fear there are some drawbacks. In my estimation you can compare |
| 10 |
patches to closed sources to some degree. Even if they are pro forma |
| 11 |
open source they are mainly usefull for the very distribution. In this |
| 12 |
sense they are the propriatary work and the capital of each distro. So |
| 13 |
I guess it will be difficult to convince them to store their patches |
| 14 |
into a common QM repository. Forks of a distro would become much more |
| 15 |
easy and like more successful. |
| 16 |
|
| 17 |
However it's worth I try. OpenSource works and nobody would have |
| 18 |
predicted that 40 years ago. |
| 19 |
|
| 20 |
> You never really needed Java, but proper build systems. What we |
| 21 |
> could gain here is saving a lot of distro-specific extra works if |
| 22 |
> some distro like Gentoo directly works on different targets |
| 23 |
> environments. |
| 24 |
|
| 25 |
That's true as far as we speak of unixoid environments. To port |
| 26 |
programs to other environments requires more efforts than just a |
| 27 |
proper build system. The original idea of Java was, to bring a |
| 28 |
standard layer into any environment, that would remove the need of |
| 29 |
ports. |
| 30 |
|
| 31 |
> The interesting point in Java is that it is an (well, was) an |
| 32 |
> very cleanly defined virtual machine (even virtual processor) |
| 33 |
|
| 34 |
One interesting point is, that it is was very successfull, but on |
| 35 |
completly different fields than origninally targeted. Most Java |
| 36 |
doesn't run platform independent programs, but runs servers, that |
| 37 |
don't need to be platform independent at all. |
| 38 |
|
| 39 |
> environment which can be emulated on virtually any known machine |
| 40 |
> (assuming it has enough resources). That could also work with |
| 41 |
> plain C, if the basic APIs are stricly and cleanly defined. |
| 42 |
> (see Plan9 vs. plan9port). |
| 43 |
|
| 44 |
Java was also designed to facilitate programming comparing C. Still |
| 45 |
Java itself isn't the last clue. Take the horrible way to copy a |
| 46 |
simple array. The fewer programming in C facilitates matters. It still |
| 47 |
makes sense in the Unix environment, but rather for historical |
| 48 |
dependencies and performance than for simplicity. |
| 49 |
|
| 50 |
> |
| 51 |
> Let me add a third candidate: Briegel. It's based on crosscompiling |
| 52 |
> from ground up. It's not really a distro, but more a generic build |
| 53 |
> system, as a basic building block for distro generation. But beware |
| 54 |
> that it's based on very different concepts than traditional distro |
| 55 |
> build systems. |
| 56 |
|
| 57 |
That is very interesing. Briegel is indeed related to what I currently |
| 58 |
do. I have a special usecase in mind. I only want to do the basics as |
| 59 |
far as necessary, because a portable Posix environment is still |
| 60 |
missing yet, then turn back to my original idea. |
| 61 |
|
| 62 |
Briegel is strongly focused on the technolgical basics, without |
| 63 |
talking of all possible usecases. At least mine was not addressed. :-) |
| 64 |
|
| 65 |
Still Briegel looks like a one-man-show while there are already |
| 66 |
communities behind the Cygwin and the Gentoo candidate. |
| 67 |
|
| 68 |
What is your strategia to build up a community? |
| 69 |
|
| 70 |
Al |
Archives