Older blog entries for lkcl (starting at number 373)

sentikathar (or whatever your name is!) thank you for bringing this article to fork or not to fork to my attention.

it repeats exactly what has been blindingly obvious to me for several years, which, whenever i mention it i am hounded out of forums, including having the so-called samba team leaders make a fascist decision to treat any attempts of communication to samba.org as "net abuse", including another fascist decision by the exim.org list maintainers to unsubscribe me without consultation - the list goes on.

i particularly want to highlight a couple of sections for people, which emphasise the main points of my talk at UKUUG in 2006:

I believe that the fundamental advantage of free software in the next decade will be in the growing ability of any single free software project to be multiple things to multiple users simultaneously.

This will translate into the fact that, in the next ten years, technology and social processes will evolve, so that forking is increasingly less of a bad thing.

Free software development methodology will become less dependent on a single project and begin to emphasize parallel development within an ecosystem of related projects.

and this, from the summary - my favourite:

It's becoming increasingly difficult to reproduce these large projects. While reproducing entire project is impossible for small groups of hackers, it is often not even possible for small groups to even track and maintain a fork of a large project over time.

it emphasises the RESPONSIBILITY and the DUTY that free software developers have. we are GUARDIANS OF KNOWLEDGE - for the WORLD.

if you cannot accept that responsibility, to provide all things to all people, FUCK OFF AND GIVE IT TO SOMEONE WHO CAN

many people read this more than they do the articles. so i'll cut/paste the comment here:

Godel Escher Bach, Page 656, posted 17 Mar 2007 at 12:21 UTC by lkcl » (Master)

"When it is hard to build a template because the preprocessor finds too much diversity, that should serve as a clue that concepts on a higher level of abstraction are involved that the preprocessor knows nothing about"

this is an absolutely brilliant lesson to know about programming: first understand your concept. then model it. then use that model to improve your understanding. lather, rinse, repeat until success or bankrupt.

all of which illustrates why proprietary software will always fail to satisfy.

i'm interested to find out more about this kumagames - whether they understand the concept of free software, correctly, or whether the word "free" has only one meaning.

guys: hellooo, if you're reading this, please do tell us more in your blog about what you believe "free" to mean, because "free software" has a very specific definition (see gnu.org)

it DOESN'T mean "shareware".

for example - can i get the source code of your games and compile it for linux, and play online?

because if so, GREAT, i have a MASSIVE potential customer base for you, if the source code of your program is preinstalled on some machines i'm helping to get distributed.

(p.s. - those machines have a zero to negative chance of having windows installed on them: the BIOS actually prevents the windows operating system from being installed. i'll say that again. the BIOS prevents the windows operating system from being installed)

    fTabs = TabPanel()
    fTabs.add(HTML("pane1"), "firsttab")
    fTabs.add(HTML("<b>pane2</b>"), "secondtab")
    fTabs.add(HTML("<h1>pane3</h1>"), "thirdtab")
    fTabs.selectTab(0)

i'd _kinda_ expect Tabbed Panels to be part of ruby on rails _already_.

i'm sure ruby is great - but the best thing that ruby could have is a port of GWK / pyjamas.

faw: 50 minutes a loonnng time on a video :) [does anyone who's seen it have a summary? is there a transcript? does _google_ do transcripts of videos - _that_ would be useful...]

there are certain rules required to ensure successful projects (that are nothing to do with "technical"):

1) REWARD people for good behaviour

2) PUNISH people for detrimental behaviour

3) DEFINE what good and bad behaviour is, well in advance.

these are _basic_ rules to do with group management, and a number of free software projects assume that everyone will "get along nicely".

the ubuntu development ethics is possibly the best i've yet encountered: it definitely defines 3) in a very good way, which is almost nothing to do with "technical" it's about people.

what happened to me with samba was a complete nightmare, which a lot of people have difficulty believing or accepting.

not only was there no definition of good or bad behaviour spelled out (therefore nothing to which anyone could point or adhere), but also there was no punishment of the so-called samba team leaders for detrimental behaviour (and they were so nasty towards me that people have difficulty believing that they could be capable of it, they are so "respected" by others), and on top of THAT, there was no reward (remember the linux IPOs? i got NOTHING, despite being in america at the time and was therefore eligible to receive shares) i got nothing from the so-called samba team leaders and nothing from anyone or any linux company benefitting greatly from my work.

however.

in addition to these simple rules 1,2,3, there is some basic communications infrastructure rules that can enormously help a group. these rules are IMPORTANT TO FOLLOW, as they stop information from being lost:

1) DO NOT use mailing lists as the primary communications method. in fact, DO NOT use email AT ALL as the primary communications method. ONLY use email as a one-way 'notification' mechanism to people to check OTHER methods to look at information, on-line.

2) subdivide everything into announce-public, developer-announce-private, developer-private and user-public.

3) use forums - subdivide according to 2) above and make sure that email-notification is switched on by default

4) use wikis - again, subdivide according to 2) and if possible, _again_ make email-notifications switched on by default.

5) provide IRC channels, again, subdivide according to 2), make sure that there is a channel-bot that logs everything again, keeping the logs subdivided according to 2)

6) make sure that there are search mechanisms, again, subdivided according to 2) on everything.

7) make sure that there's a good bugtracker: again, subdivide according to 2), and make sure that email notification is switched on by default.

8) i'll say it again: ON ABSOLUTELY NO ACCOUNT should you use email as the primary communications mechanism. DO NOT, i repeat, DO NOT do it.

email as a communications mechanism is a complete failure.

only people who have extremely good memories and are not overloaded with work or spam are capable of successfully utilising email for communications of complex issues.

and software development rates in my book as possibly the most complex undertaking that humanity is currently capable of.

hm. that looks like another advogato article, to me :)

slamb: you know what? i LOVE being wrong on details: it gives people a chance to educate me :)

xinit servers. dont' buy from xinit.com unless they get their act together! here's why

couple of things: i promised i'd find out about the name of that thing for semantic web: it's called the zachman framework.

the ayurvedic scriptures are a simple and fundamental understanding and expression of quantum mechanics: they outline simple things like the principle of observer, observed and the process of observation which, in language (simple sentence construction), is "subject", "object" and "predicate". the cat (subject) sat (predicate) on the mat (object).

it goes further - a hell of a lot further - but the zachman framework and this ridiculously-named "web 2.0" rubbish are the beginnings of an information era, where the ancient ayurvedic scriptures are once again coming round / being reinvented / being rediscovered.

the internet is pushing knowledge boundaries and tools to contain and structure knowledge and information. google is a good example of that - but google is beginning to creak at the edges of its success, and is being constrained by the limitations of the framework in which it is forced to work: Cancerism (more commonly known as capitalism).

anyway. the who what why when how of the zachman framework maps roughly onto concepts like subject, object, predicate, etc. which are also part of the ancient ayurvedic scriptures which are also part of quantum mechanics.

so it's not rocket science.

message passing

pphaneuf - you're looking for an atomic operation to communicate information. the only atomic operation in POSIX is the file "move" operation.

i believe that the operation you are looking for in a kernel, however, is message passing. it's a fundamental operation that doesn't exist in the linux kernel, because the linux kernel developers are too stupid to appreciate its benefit, despite tannenbaum telling people for what... thirty years, now?

what particularly pisses me off about this one is that the work has been _done_ already - by the university of karlsruhe and the university of southern australia.

they keep their work up-to-date with the latest linux offering.

all that's needed is for their work to be adopted into the linux kernel as a compile-time option.

and, the thing is: it would dramatically influence - for the better - the direction and development of the linux kernel.

but, because of linus' pig-headed lack of intelligence and lack of desire to learn or compromise, we have to wait until a bus runs him over before anything can be done.

anyway.

yes, pierre: your idea has great merit, and it is the solution that gets used often. particularly because you don't have to have threads: you can use processes, you can use a single process and implement a state machine to subdivide the work, it's all the same.

other than, by using threads, then every single libc function call has to now call locking around data structures, on your behalf, which, if you used _processes_, you would end up implementing (by hand) a much _better_ and more efficient use of shared memory for intercommunication than the extremely coarse-grained (but hidden) use of shared memory in libc when threads are used.

and, other than, a state machine of course is a bit of a pain as you have to subdivide the work yourself, manually, but, in some instances, a state machine (simplest way: "callbacks") is the only way.

you only have to look at the mess that is the asyncdns library to realise _that_ one.

company: i've been trying to drum this in to free software people for several years now - like, about... five or six.

a free software project, with free software source code, a nice free software infrastructure, a nice free software source repository, is absolutely xxxxing useless if you don't know what you are doing.

we're going _well_ beyond the realm where "show me the code" actually means anything, which is why it pisses me off so much.

your explanation - which points out the inadequacies of specifications not covering everything that's needed: information is missing.

and you need time times intelligence times information, in order to have an effective implementation and also to be able to _improve_ an implementation.

(i'm sure that there's a quantum mechanics equation for that, somewhere).

and, whilst we have lots of _rights_ to implement (free software licenses etc. which protect the implementation) we _don't_ necessarily have lots of information or intelligence or time...

no, any old machine with 128mb of RAM _won't_ do. the startup time on the AMD Geode 500mhz GX and 600mhz LX CPUs is 11 seconds because the memory is 64-bit DDR 300 and 400 mhz respectively.

compare that to older 133mhz SDRAM of "any old machine" and it's 3 times faster. i have a 500mhz Via ETEN cpu which uses the older 133mhz SDRAM and it runs like a DOG.

you almost don't need any L2 cache, and if you used that blindingly quick DDR2 memory that was the same speed as the CPU, then actually you would have a faster processor if you didn't have ANY cache.

quad:

there is a well-known (except i can't remember the name!) semantic classification system which goes on "when what why who where"?

then you provide hierarchical views, provide tags and tag groups.

then you apply intelligence (either through bayesian or through many monkeys) tagging.

_then_ you qualify the tags themselves (!) and make _those_ simply part of the information infrastructure.

so, one of the sources is "tags from bayesian filtering" which were added today, for the purpose of finding some spam... that gives you the "when what where who why".

i'll try to find the name of the classification system.

ok well at least i found this:

http://www.statsoft.com/textbook/stclatre.html

The moral of this story of the power and pitfalls of classification trees is that classification trees are only as good as the choice of analysis option used to produce them. For finding models that predict well, there is no substitute for a thorough understanding of the nature of the relationships between the predictor and dependent variables.