Re: sustainable development

Am Samstag, 15. August 2009 02:34:58 schrieb steve paesani:
> I think the micorkernel is neat and may work on it
> however I would like to use a 'dev'comp' license that affords
> that the software's development costs be compensated through
> sales. 

Please have a look at the success of LimeWire: 
- http://limewire.org
- http://limewire.com

They sell a completely GPL licensed Gnutella p2p program, and they make really 
good money off it. 

The means they use is to provide a Pro version which offers improved 
performance by some changes which everyone could do himself in the sources. 

But because it is much more convenient to simply pay a small fee to get the 
changes that to do them or find a changed program (and be sure it's safe), 
people buy the Pro version.  

To duplicate that success you could, for example, regularly create tested 
snapshots and sell these (along with the corresponding sources).  

Also people might buy packaged disks and similar. 

Naturally others could then just resell your snapshots (but since your 
packaged parts are physical, they can't be copied easily), and include your 
work in the main distribution, but as long as you keep creating new and 
improved snapshots, you can become a reference source of specialized versions. 

Re: sustainable development

Hi Steve Paesani, 

Am Donnerstag, 10. September 2009 03:04:13 schrieb steve paesani:
> I have a real need to express my ideas about what is ethical and what is
> not.And I can guarantee that I am not joking around.

Neither am I and the FSF doesn't joke around either. 

> The question is clear: Where does the FSF stand on software developers
>  being paid to work?

Simple: Developers should be paid for doing ethical work. For example about 
half the Linux kernel hackers are being paid for their ethical work. 

> Here is another clear question: Does the FSF purport or not porport slave
> labor?

That question is rethorical and useless. You can read the answer from my 
answer to your next question. 

> Here is yet another: Do those who run the FSF believe in and promote
> slavery?

No. They don't believe in slavery, neither the slavery of the developer, nor 
the slavery of the user. 

Unfree software strips the user of his right to control his own computer, so 
it is a shackle which takes freedom away from him. 

If you have to steal peoples freedom for being paid, your work is unethical. 

Re: sustainable development

Re: sustainable development

Am Donnerstag, 10. September 2009 21:42:17 schrieb steve paesani:
> Arne,
> 
> are you one of the original Hurd developers?

No. 

Wishes, 
Arne

--- --- --- --- --- --- --- --- --- 
Unpolitisch sein
heißt politisch sein, 
ohne es zu merken. 
- Arne (http://draketo.de)
--- --- --- --- --- --- --- --- --- 

Broken dream of mine :(

Well, It was sometime ago when Jonathan Shapiro started working on
Coyotos and there was some discussion on mailing lists that Coyotos
may be the next generation microkernel for Hurd. I kept an eye on the
development of Coyoptos and saw that their expectations for Coyotos
forced them to create a new language BitC;
http://www.bitc-lang.org/index.html  which of course, I really liked
and quite impressed with their efforts. A thought struck my mind that
I can use BitC to rewrite Hurd.

I wanted to work on a language which is not designed for PDP-11 but
for modern 32bit hardware. Hardware has come a long way from PDP-11 to
AMD Phenom Gen II but the software is not. So I was very happy on
seeing a technically sane language which included elements from
function programming. Many people will claim that I can think of C++
but personally I am not much of a fan of C++ (I am a fan of Lisp).

Now, I passionately wanted to use a GNU system but after 25 years the
Hurd is still in its nascent stage and now since Shapiro has joined
M$, he has stopped working on Coytoso anymore:
http://www.coyotos.org/pipermail/bitc-dev/2009-April/001784.html .
Seems like Coyotos shares the same future (never to be finished) as of
Hurd.

 How many of you think that using C is still a good idea ?  There is
one concept in Lisp. When we want to do something then we can bend the
language according to our design and that is possible because Lisp is
the programmable programming language. But I can not use Lisp to write
an OS, so BitC was my hope. I think a project as complex as Hurd needs
to use a language that is specifically designed for that project, that
can work according to the basic design of the OS not the other way
around. Do you think using C fits that criteria for Hurd ?

I have this question on my mind from last 5 years, so today without
any fear of flames and of jokes I, with much courage, have posted
this. What is your view on my reasoning ?

--

-- 
http://uttre.wordpress.com/2008/05/14/the-lost-love-of-mine/

Re: Broken dream of mine :(

El Mon, Sep 14, 2009 at 03:30:08PM +0530, arnuld uttre ens deleità amb les següents paraules:
>  How many of you think that using C is still a good idea ?  There is
> one concept in Lisp. When we want to do something then we can bend the
> language according to our design and that is possible because Lisp is
> the programmable programming language. But I can not use Lisp to write
> an OS, so BitC was my hope. I think a project as complex as Hurd needs
> to use a language that is specifically designed for that project, that
> can work according to the basic design of the OS not the other way
> around. Do you think using C fits that criteria for Hurd ?

First, I'd like to separate the whole sw stack in a few layers:
    - hw interactions (aka low-level code typically programmed in asm in C-based
      projects)
    - kernel code (first-class system-wide abstractions)
    - system code (services/abstractions hurd builds on top of any kernel it is
      using as a substrate)
    - other software (mainly user applications and daemons)

So now, my question would be which features you don't like of a specific
language (C in this case), and in the context of which "layer"?

Not that I'm very knowleadgeable in BitC (I'd say I have no knowledge at all),
but I'm curious of which are the itches you want to scratch, and more important,
which are they tradeoffs.

Of course, analyzing the tradeoffs would require an agreement on a list of
quantifiable features and their relative weight.

Read you,
    Lluis

--

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: Broken dream of mine :(

Hi,

On Mon, Sep 14, 2009 at 03:30:08PM +0530, arnuld uttre wrote:
> I wanted to work on a language which is not designed for PDP-11 but
> for modern 32bit hardware.

It is a common mistake to think that "this is old, and therefore good".
However, you seem to make the other mistake that "this is new, and
therefore better".  Both are not true.  Old things may be good, and new
things may be better.

> Hardware has come a long way from PDP-11 to AMD Phenom Gen II but the
> software is not.

In fact, it has evolved, which is a pity.  The 80x86 is one of the worst
architectures I know, definitely much worse than for example arm or
mips.  However, many people have done a lot of work to optimize it, and
that resulted in something which isn't as bad as it started with, and
they did indeed manage to outperform better designs by brute force (at
the cost of excessive power usage, but that isn't a problem everywhere).
Still I believe it would have been much nicer if the starting point
would have been a good architecture.

Anyway, it historically makes sense that a language evolves with
hardware.  And C, even if it still has the same name, has evolved a bit
as well.  The real evolution is of course in the step to C++, where it
really becomes a different language (if you want to use it that way).

> I think a project as complex as Hurd needs to use a language that is
> specifically designed for that project, that can work according to the
> basic design of the OS not the other way around.

I disagree that a complex project must have its own language.  It must
have a language which is suitable for the problem that is to be solved,
but that doesn't mean the language needs to be designed.  A language is
a way of thinking.  It is likely that there already exists a language
which fits the way you think about your projects.  It most likely is the
language you most use.  It may be a good idea to try a different one.
But to design a new language in order to better solve a problem, IMO
that can only succesfully work for a genious.  For normal people,
designing a language is a task in itself, and it takes many programs,
among which several large ones, to complete that task.  Only then is it
"the perfect language" for some tasks.  I'm sure you agree the Hurd
doesn't need another time consuming task at the moment. 

>  How many of you think that using C is still a good idea ?
...
> Do you think using C fits that criteria for Hurd ?

I have written a toy kernel for x86 some time ago, in the spirit of
discussions I had on this list with Shapiro and others.  That kernel was
written in C.  It worked, and I am still quite happy about it.  If
others would have joined, it might have become a serious kernel, maybe
even the basis for the Hurd.

However, nobody did, and I moved on as well.  Recently, I started
writing a new kernel[0], for a mips-based mini-pc, mostly with the same
ideas, but now in C++[1].  Of course I'm not using any libraries, so no
new, virtual member functions, exceptions, or any other fancy things.
But I do sort my code in classes with normal member functions and
namespaces, and I do use default function arguments and a few templates
(but not the STL, because it uses new).

This is so much better.  In C, I'm happy when things are possible, and I
try to make them work with not too much strange constructs for the
application programmer (preprocessor macros can be used very creatively,
I'm sure you know), often at the cost of strange and unreadable
constructs in header files, leading to uncomprehensible warnings (this
also happens in some places in the Linux kernel btw).  In C++ things can
almost everywhere be done with native methods, which leads to much
cleaner (but not slower) code.  This is not only true in the header
files, but also in the kernel source itself, and in the "applications"
I've written (which are mostly device drivers).

Of course Richard Stallman is a known hater of C++.  He has a point that
everybody knows C, so using that makes the code readable for everyone.
However, our main interest is not that everyone can read our code.
While that counts for bonus points, the main point is that we can read
(and write) the code ourselves, and that we can efficiently create
things in it.  IMO his love for C is unreasonable.  C may still be
useful in some places, but not in big projects.  With my kernels, I
personally found out that even when you think that C is a suitable
language for doing something, it may still be much easier in C++ (and
probably in another higher-level language as well, but I do share his
concerns about Java and C#, so I would never recommend those).

For me the Hurd is currently sleeping.  When it wakes up, I'll probably
contribute again, and I certainly wouldn't mind if it would be in C++.
At the moment, I'm working on kernel stuff anyway (I just like that).
And of course I do it completely my way when I don't need to cooperate
with others. 

I have a question for you as well: why are you asking?  Are you just
amazed that people still want to use ancient tools for modern projects?
Or are you considering to contibute to it yourself?[2]  Or do you have
some other reason?

Thanks,
Bas

[0] http://projects.qi-hardware.com/index.php/p/iris/
[1] Actually, I'm using my own preprocessor to make certain Python
    constructs work.  But all the thinking is in C++.
[2] If you want to contibute to a kernel in a higher-level language, you
    are welcome to help me with Iris[0].   I suppose you're not, as
    you wrote that you're not a C++ person, but I couldn't resist to
    suggest it. 

Re: Broken dream of mine :(

Hello

2009/9/15 Bas Wijnen <shevek <at> fmf.nl>:
> Hi,
>
> On Mon, Sep 14, 2009 at 03:30:08PM +0530, arnuld uttre wrote:
>> I wanted to work on a language which is not designed for PDP-11 but
>> for modern 32bit hardware.

I don't know where people get the hate against PDP-11. I suspect most
even haven't seen one.

>
>>  How many of you think that using C is still a good idea ?
> ...
>> Do you think using C fits that criteria for Hurd ?
>
> I have written a toy kernel for x86 some time ago, in the spirit of
> discussions I had on this list with Shapiro and others.  That kernel was
> written in C.  It worked, and I am still quite happy about it.  If
> others would have joined, it might have become a serious kernel, maybe
> even the basis for the Hurd.
>
> However, nobody did, and I moved on as well.  Recently, I started
> writing a new kernel[0], for a mips-based mini-pc, mostly with the same
> ideas, but now in C++[1].  Of course I'm not using any libraries, so no
> new, virtual member functions, exceptions, or any other fancy things.
> But I do sort my code in classes with normal member functions and
> namespaces, and I do use default function arguments and a few templates
> (but not the STL, because it uses new).
>

When you announced that you are writing this kernel you said something
along the lines that it will be a sort of proof-of-concept
implementation of some not-yet-finished ideas.

I was somewhat curious about the results because the kernel was
supposed to have a resource management which was based on ideas that I
could not imagine working. I did not notice any announcement of
progress or other output so there we are.

Thanks

Michal

Re: Broken dream of mine :(

On Tue, Sep 15, 2009 at 08:19:19PM +0200, Michal Suchanek wrote:
> 2009/9/15 Bas Wijnen <shevek <at> fmf.nl>:
> > I have written a toy kernel for x86 some time ago, in the spirit of
> > discussions I had on this list with Shapiro and others.  That kernel was
> > written in C.  It worked, and I am still quite happy about it.  If
> > others would have joined, it might have become a serious kernel, maybe
> > even the basis for the Hurd.
> >
> > However, nobody did, and I moved on as well.  Recently, I started
> > writing a new kernel[0], for a mips-based mini-pc, mostly with the same
> > ideas, but now in C++[1].  Of course I'm not using any libraries, so no
> > new, virtual member functions, exceptions, or any other fancy things.
> > But I do sort my code in classes with normal member functions and
> > namespaces, and I do use default function arguments and a few templates
> > (but not the STL, because it uses new).
> >
> 
> When you announced that you are writing this kernel you said something
> along the lines that it will be a sort of proof-of-concept
> implementation of some not-yet-finished ideas.

It was.  That was the toy kernel I was talking about.   If one or two
people would have really liked it and helped me improve it, it might
have become more than a toy.

However, I currently prefer to focus on Iris, because with her target
hardware, it is more likely that people will actually want to use it.  I
don't see any way to get people to change their desktop system.  After
all, a new system will for quite some time have problems such as missing
drivers.

> I was somewhat curious about the results because the kernel was
> supposed to have a resource management which was based on ideas that I
> could not imagine working.

Well, it can run nethack.   That does mean it is almost completely
functional.  What do you mean by "not working"?  That is doesn't run, or
that it is extremely slow?  I didn't do any benchmarks, and obviously
nethack isn't a heavy application, so not having performance issues
there doesn't mean anything.  Also, as I wrote in the announcement, I
didn't even try to make my libc fast; it was only intended to make
nethack run so I could see (and show) that the kernel worked.

> I did not notice any announcement of progress or other output so there
> we are.

There wasn't any announcement, because there was no progress.   Well,
not with that kernel anyway.  There is progress with Iris now, which is
for several reasons a nicer project, the change of language being one of
them.  I do think it is a better kernel because I wrote the other one
first, though.  So my work on that was not wasted.[1] 

Thanks,
Bas

[1] Not that I make programs for the result.  It's too much work for
that.  I do it for the process.  Which IMO is the only good reason to do
it.  And if you really need something that doesn't exist, but that
hardly ever happens to programmers, and it never happens to people who
don't know what is possible. 

Broken dream of mine :(

On Mon, Sep 14, 2009 at 8:00 PM, arnuld uttre <arnuld.mizong <at> gmail.com> wrote:
>
> Well, It was sometime ago when Jonathan Shapiro started working on
> Coyotos and there was some discussion on mailing lists that Coyotos
> may be the next generation microkernel for Hurd.

Even for some time before Coyotos was no longer actively developed,
it was effectively abandoned by the primary architects of the hurd, due
to its support of the so-called non-trivial confinement.

>
> I kept an eye on the
> development of Coyoptos and saw that their expectations for Coyotos
> forced them to create a new language BitC;
> http://www.bitc-lang.org/ which of course, I really liked
> and quite impressed with their efforts. A thought struck my mind that
> I can use BitC to rewrite Hurd.

I'm not sure what to say but that you are welcome to try :)

The significance of BitC was that certain security properties could be proven
easier than using proof systems on top of C; a kernel, drivers, and
core servers that have the reliability and security features you are interested
in may be possible, but you are right that it would really be a rewrite.
Unfortunately, there are no great crowds of programmers ready to rewrite
the equivalent of a monolithic Unix kernel on demand.

I think there are a lot of people still interested in a Coyotos
future, but there is
no direction to follow, and nobody writing code that I am aware of. As with
any free software, people will go where the activity is. If someone
started doing
something with Coyotos, well, maybe.

>
> Now, I passionately wanted to use a GNU system but after 25 years the
> Hurd is still in its nascent stage and now since Shapiro has joined
> M$, he has stopped working on Coytoso anymore:
> http://www.coyotos.org/pipermail/bitc-dev/2009-April/001784.html .
> Seems like Coyotos shares the same future (never to be finished) as of
> Hurd.
>

Shap has left behind a fairly complete specification for Coyotos - it's not
like the work the interested parties did over those seven (?) years just
disappeared. And you already have GNU :)

William Leslie