1) Is this the death knell of KDE?
2) Is this a move by the big corporate tech companies to
'Bogart' the Linux marketplace?
3) Is this really good for the open-source movement?

Granted, KDE can always exist, but this would probably make
GNOME the 'de facto' standard linux desktop. I can't help
but think that these major players won't undermine the
open-source philosophy by usurping the responsibilty of the
direction that
GNOME takes. This could lead to the companies directing the
development of GNOME not in the best interests of the
community, but in there own fiscal interests. Remember,
these companies don't give a rat's ass about open-source,
but rather
how can they make a buck from it. I guarantee this is just a
business move to try and topple Microsoft. These companies
would be Microsoft if they could. Does anyone want this to
become the NEW Microsoft?

"Shop Smart. Shop S-Mart."

Item 3: Good for the open-source movement?

It increasingly seems to me that in the future, the open
source movement and community will be led and built mostly
by big corpos. Sure, we are the community today, but
tomorrow we will only be a (probably named) fraction of it.
It isn't more than reasonable that the service businesses of
tomorrow (product businesses today) will be the ones who
maintain the frameworks (open sourced code) they depend on
for their livelyhood.
We should value this short window in history where we are
still a community of personal beings. Tomorrow we - the
personal beings - will have been replaced by anonymous
coporate project leaders. We will be able to look back on
this passage in time and proudly state that it was truly
good years for personal fulfillment and visionary work that
single individuals could pull off.

The only reason I do my own scheduling in user space is
because I need to control execution time slices. Thus, if
there was a way to set the time slice for a LinuxThread,
then I could just write a nice wrapper lib where MyThreads
would be mapped one-on-one to LinuxThreads. And ofcourse
figure out an efficient means to controll the slices with
respect to process nesting hierarchies.
However, setting time slices for processes/threads is not
possible with Linux. The time slice "belonging" to a process
is just the side effect of the priority based scheduling
mecanism. Some other path has to be explored.

Tadaa!
It is not currently possible for one thread to yield
directly to another thread. I.e. a thread can only yield to
the system, which will pick the next thread as it sees fit.
However, yielding directly to another thread wouldn't really
mess up anything if the scheduler was kept unaware of this
"directed yield". Any time left of the slice would be used
by the second thread, but the first one would still "pay"
for it. Preemprion would work as if the first thread was
still running. Such a yielding scheme could be used to do
some really cool libs for process modelling :-)
Take a look at the report "CPU Inheritance Scheduling"
released by the Fluke project. The idea is fleshed out
pretty nicely there.

Possible trouble
Making a forced context switch a la
setcontext(ucontext_t*) must somehow make sure that
not only the NPC and SP + registers are switched. Threads do
afterall have individual signal masks and so on. There seems
to be an inherent conflict in doing a directed yield without
bringing in system scheduling and at the same time making
sure all
parts of the new thread are activated properly.
It shouldn't be too bloody difficult though. It's my wild
guess that there is something in the kernel which could
aptly be called a "context switching atom". The scheduler
utilizes this atom to go from kernel space into user space
when the next-to-run process is chosen. If this atom was
made usable from user space via a system call then any
process/thread could yield its time to anyone who is known
to need it better than the yielder. One could think of it as
a way to safely managing CPU resources "better" than the
system already does.

Radagast made a follow up and adressed ncm about a
possible pseudo-english parsing shell. There is a fatal
inherent flaw to such a shell, but it also made an old idea
of
mine resurface. Thus:

The Flaw
The name says it all: "pseudo-english". Obviously you'd want
pseudo-german as well. Even considering a pseudo-japanese
one is daunting to say the least. Porting such a shell to
the different semantic structures (or tendencies towards
such structures) of different natural languages is not
practical.

The Remedy
Lets imagine some kind of scratchboard where you could mix
representations of various acts (picked from tables divided
according to the nature of the various tasks). Just like
using redirection or variables in a shell script, the user
would connect the representations using arrows. Thus forming
a directed graph -- possibly a cyclic one with conditions
for termination.
The acts would require the user to fill in parameters (in
popups or whatever) just like a shell command does.
When a graph is constructed it could be saved as a new act,
thus adding to the table of pickable acts.
Acts (or graphs of acts) could then be used as traditional
scripts that the user executes manually or assigns to
cron-like or event-driven agents. The acts could however
also be used interactively by simply executing some act and
adding subsequent ones as necessary. Backtracking would be
possible since a session with history would exist naturally
in form of the directed graph formed by the acts.
Finally, only the program managing the sets of acts (and the
popups for various acts) would require translation between
different natural languages. The acts themselves or the
machinery underneath would require no knowledge of
natural(-like) language to function.
The construction of original acts would still require
skill in
putting together shell scripts, but it wouldn't be a
prerequisite for using existing ones.

How about that?

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.