Merge commit 'pipapo/master'
This commit is contained in:
commit
cc2705ec31
4 changed files with 82 additions and 8 deletions
|
|
@ -7,6 +7,6 @@
|
|||
|
||||
# see wiki/index.html#GitNotes%20GitAliases for information
|
||||
|
||||
git sign "$(git-symbolic-ref HEAD | cut -d/ -f 3-)_signature"
|
||||
git publish
|
||||
|
||||
git tag -s -f -m "signature generated by $(git config user.email)" "$(git config user.email)/$(git-symbolic-ref HEAD | cut -d/ -f 3-)_signature"
|
||||
git push --all public
|
||||
git push public "refs/tags/$(git config user.email)/*"
|
||||
|
|
|
|||
|
|
@ -2095,10 +2095,26 @@ see : <<tag RSSFeed>> for the full list.
|
|||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Scheduler" modifier="CehTeh" modified="200706271505" created="200706220108" changecount="2">
|
||||
<div title="Scheduler" modifier="CehTeh" modified="200708101610" created="200706220108" changecount="7">
|
||||
<pre>Scheduling is done with two priority queues, one for high priority jobs and one for low priority jobs. These priority queues are ordered by absolute time values (and a job identifier, details will be worked out at implementation time).
|
||||
|
||||
There is also a variable defining how to handle too-late schedules (proceed, abort) for each scheduled job. </pre>
|
||||
there are following (non exhaustive) kinds of jobs:
|
||||
* start job
|
||||
* cancel job, if not finished (abort when out of time)
|
||||
* unschedule job
|
||||
|
||||
Jobs implement a kind of future, datastructures which block a querier until data is available.
|
||||
|
||||
The Job scheduler runs singlethreaded. Its only task is to schedule and delegate jobs to worker threads, by itself it will never do any extensive processing!
|
||||
|
||||
Each job has an option what to do when its times expires (abort, proceed).
|
||||
|
||||
The high priority queue is ordered by the __start__ time T, when the job has to be started (plus some hystersis H). A high priority job becomes scheduled beginning with time T but no later than T+H.
|
||||
|
||||
The low priority queue is ordered by __end__ time T, when the job has to be finished (minus a spawn S). Low priority jobs are started as soon as system load permits, the high priority queue is empty (for some usec in future, lets say 100) and the time is earlier than ~T-S. When a job is expired, it is removed from the queue, when it is already running it is handled as defined in its expire policy.
|
||||
|
||||
Canceling and expireing jobs gets noted in Statistics to adjust performance and timings for optimal performance.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="SideBarOptions" modifier="CehTeh" created="200706200047" changecount="1">
|
||||
<pre><<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">></pre>
|
||||
|
|
|
|||
|
|
@ -795,10 +795,11 @@ This distributed wiki might be used instead the pipapo.org wiki, investigate tha
|
|||
Wiki works. It is simple to use and just flexible enough to handle the task. I don't go to install any other software for such tasks on my server. While the design progresses I'd propose to move our work into git repositories and eventually phase this wiki pages out anyways. I'd rather like to start out distributed/git right away .. but git gives us only a fine storage layer, for a design process we need some good presentation layer (later when using git and starting the implementation everyones favorite editor serves for that) I have no better ideas yet to solve the presentation problem other than using this wiki (or maybe Bouml).
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Cinelerra3Wiki" modifier="Ichthyostega" modified="200708051525" created="200706172308" tags="portal" changecount="21">
|
||||
<div title="Cinelerra3Wiki" modifier="CehTeh" modified="200708101843" created="200706172308" tags="portal" changecount="22">
|
||||
<pre>This 'index.html' becomes the entry point of some tiddlywikis managed under git. There is a 'empty.html' in the same folder serving as template for generating new wikis. Please refrain from editing it.
|
||||
|
||||
* I started a GitNotes where we will collect some information about git, howto and special setups
|
||||
* since we prefer gpg signed tags in git and not each developer knows gpg well here is a Micro-GPG-HowTo
|
||||
* we maintain (semi-) final design docs in DesignDocumentation
|
||||
|
||||
Please end your tiddlers in a newline, this makes merging in git easier since the /pre tag used in tiddlywiki will become on a single line.
|
||||
|
|
@ -1335,6 +1336,63 @@ We are in need of a new development model which is acceptable by all involved pe
|
|||
|
||||
<style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>My TiddlyWiki</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div></pre>
|
||||
</div>
|
||||
<div title="Micro-GPG-HowTo" modifier="CehTeh" modified="200708101901" created="200708101900" changecount="2">
|
||||
<pre>I (cehteh) just paste my configs and give very few hints here, refer to the gpg manpage, the gpg documentation, google or ask on IRC for details. Maybe you improve this.
|
||||
|
||||
First of all you need to install gpg and generate your keypair if you don't have done that already. generating keys is done with {{{gpg --gen-key}}} refer to the manpage for details.
|
||||
|
||||
Be very careful that your private key has a **GOOD** passphrase and be kept secret.
|
||||
|
||||
Configuration files are in {{{~/.gnupg}}}
|
||||
|
||||
Here are the things I have in my {{{~/.gnupg/gpg.conf}}} (there are a lot of comments too, which I leave out here, instead I add some notes as comments)
|
||||
{{{
|
||||
no-greeting
|
||||
|
||||
# enter your keyid AC4F4FF4 is mine!
|
||||
default-key AC4F4FF4
|
||||
|
||||
force-v3-sigs
|
||||
|
||||
compress-algo 1
|
||||
|
||||
# you can add alternative keyservers
|
||||
keyserver hkp://subkeys.pgp.net
|
||||
#keyserver blackhole.pca.dfn.de
|
||||
|
||||
# to let gpg automatically download public keys from the net, makes usage much easier
|
||||
keyserver-options auto-key-retrieve
|
||||
|
||||
# using a gpg agent makes usage easier too, but you should only use it on a personal computer
|
||||
use-agent
|
||||
}}}
|
||||
|
||||
|
||||
when you want to use the gpg agent you need to add following line to your {{{~/.bash_profile}}} to start the agent on login:
|
||||
{{{
|
||||
eval $(gpg-agent --daemon)
|
||||
}}}
|
||||
|
||||
|
||||
further you need to add following lines to your {{{~/.bash_logout}}} to stop the agent when logging off:
|
||||
{{{
|
||||
if test "$GPG_AGENT_INFO"; then
|
||||
kill -TERM $(echo $GPG_AGENT_INFO | sed -s 's/.*:\(.*\):.*/\1/')
|
||||
fi
|
||||
}}}
|
||||
|
||||
further the gpg agent needs some configuration in {{{~/.gnupg/gpg-agent.conf}}}:
|
||||
{{{
|
||||
pinentry-program /usr/bin/pinentry-gtk-2
|
||||
no-grab
|
||||
default-cache-ttl 1209600
|
||||
max-cache-ttl 1209600
|
||||
}}}
|
||||
|
||||
Note that I am using very long timeouts, refer to the manual about its implications or leave the defaults.
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="PageTemplate" modifier="Ichthyostega" modified="200706260504" created="200701131624" tags="MPTWTheme excludeMissing" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110330" changecount="1">
|
||||
<pre><!--{{{-->
|
||||
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
|
||||
|
|
|
|||
|
|
@ -646,7 +646,7 @@ Error: #f88</pre>
|
|||
<div title="DefaultTiddlers" modifier="CehTeh" modified="200707102306" created="200707102301" changecount="2">
|
||||
<pre>[[SupportLibrary]]</pre>
|
||||
</div>
|
||||
<div title="ErrorHandling" modifier="MichaelPloujnikov" modified="200707160333" created="200707152252" tags="excludeMissing" changecount="4">
|
||||
<div title="ErrorHandling" modifier="CehTeh" modified="200708101307" created="200707152252" tags="excludeMissing" changecount="5">
|
||||
<pre>! Proposal:
|
||||
We need some centralized way to handle errors and doing hard aborts.
|
||||
|
||||
|
|
@ -660,7 +660,7 @@ My following proposal defines a very simplistic way to define unique errors whic
|
|||
|
||||
|
||||
!!! detailed semantics (proposal):
|
||||
a TLS pointer is allocated to keep a thread local error state. NULL means SUCCEESS, no error pending.
|
||||
a TLS pointer is allocated to keep a thread local error state. NULL means SUCCESS, no error pending.
|
||||
|
||||
API:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue