Older blog entries for Malkuse (starting at number 3)

Signed up as a contributor for the OpenOffice project. Let's kick some font selection butt!!

Saw this comment on /. about the Sun/IBM/HP et.c Gnome effort:

Several Troubling Questions (Score:2, Interesting)
by Riplakish on Monday August 14, @10:05AM EDT (#116)
(User #213391 Info)

In no particular order:

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.

harebra / Malk

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.

Considering the Towards the Anti-Mac article:

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?