Slashdot Mirror

feature:
http://sourcefrog.net/weblog/software/linux-kernel/free-mem.html

use vmstat

On a related note:

http://sourcefrog.net/projects/meantime/

Actually, it all depends on the workload. Some would say that Processes are a Unix hack, because they didn't think about threads.

Actually, not so much. Saying you "didn't think about threads" is like arguing that you went with protected multi-tasking OS and "didn't think about DOS". Adding memory protection and compartmentalisation is the only difference between a thread and a "process". In most cases, you just don't care anyway ... all you want is to not block, and threads are the worst fix for that problem.

Lisp needs a new incompatible dialect like it needs another hole in its foot. The problem with more widespread adoption of lisp is the lack of a good, free, widely standardized implementation. Practically every Lisp text begins with an apology for the fact that your implementation probably won't work exactly the same as the one the author used.

But then Paul knows far more about the problem than I do, and if it turns out he's right I'll be delighted.

I've become a recent fan of Martin Pool, and I've been keeping tabs on his work with Bazaar-NG, his next generation version of Bazaar, as a distributed free source code control system, for Ubuntu. It's early in development yet, but if there's one thing I've learned from Martin Pool, is he does great work! Keep tabs on him. :)

Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:

john@somewhere$ cd ~/myproject
john@somewhere$ darcs init

You now have a Darcs repository! Let's do something with it:

john@somewhere$ darcs add -r *
john@somewhere$ darcs record -am "Initial import."
Finished recording patch 'Initial import.'

Now your repository contains all your files. Let's look at the changelog:

john@somewhere$ darcs changes
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:

jane@elsewhere$ darcs get john@somewhere:~/myproject
Copying patches...
.
Finished getting.

We now have a repository on Jane's box. Let's make a modification:

jane@elsewhere$ echo "#include <foo.h>" >>foo.c
jane@elsewhere$ darcs whatsnew --summary
M ./foo.c +1
jane@elsewhere$ darcs whatsnew
{
hunk ./foo.c 2
+#include <foo.h>
}

This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)

Now let's commit and push the changes back to John's repository:

jane@elsewhere$ darcs record -am "Added a missing include."
jane@elsewhere$ darcs push -a
[...]
Finished applying...

Now we can go back to John's machine and look:

john@somewhere$ darcs changes
Thu Nov 25 06:26:10 CET 2004 janedoe@example.com
* Added missing include.

Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

(Note how Darcs generates a GNU-style changelog for you automatically.)

Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.

Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.

Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.

This system has several extremely useful effects:

• Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own righ

I don't know if Vesta is much of a contender. It looks like it's hard to adopt for projects that are not totally prepared to buy into its way of doing everything.

A more interesting new open project is Darcs: much simpler than BitKeeper or Arch, but nearly as powerful (at least for small-medium projects.)

More info

It's already been pulled apart here.

I don't think Brown deserves to be taken seriously.

• The paper is poorly written, full of contradictions and gramatical errors. If their essay were a program, it would not even compile, let alone work.
• Nearly every paragraph makes an unsubstantiated assertion. Brown seems to feel that just inserting "it is clear that", "ironically", "clearly", or "it is widely known" is an adequate substitute for cited evidence. Ironically, it clearly is not.
• Brown clearly does not understand the terms he uses, such as "copyright", "public domain" or "open source". He does not seem to understand that copyright protects representations, not ideas. In several places he seems to think that open source is in the public domain.
• Quotes such as "sometimes theft is necessary" as are attributed to the open source community without any evidence they were ever uttered by anyone.
• Experts are asked misleading or hypothetical questions to elicit quotes that are used out of context. I think AdTI is not honest enough to ask straight questions because the answers would not suit them.
• Brown says he can't believe that Linus wrote Linux, because... welll, he just can't believe it. Nothing more. He does not cite even a single line of Linux source that was copied from any other system, despite that all the data needed to check this is available to him. If he found even one line, his paper might be credible. But he does not.
• When sources are cited, Brown grossly misinterprets the data: diagrams that do not show code descent are interpreted as showing code descent.
• If Microsoft paid AdTI to write this, they didn't get much for their money.
• AdTI would like universities to release their work under something like the MIT licence, rather than the GPL or proprietary licences. At least this is not obviously silly, though as usual they just state it without making a meaningful case.
• Perhaps worst of all, the authors did not even speak to Linus before publishing these fabulous \ allegations against him.

...whereas Enderle's about a minus 7 and Didio's about a -3i. And yes, I do mean "i" in the mathematical sense, since Planet Laura seems to have left the solar system. Not sure how to rate Daniel Lyons, his bias is obvious and unforgiving but mild and he hasn't said much lately. Maybe a -4.

There's an abandoned project called SnapFS that worked as an extension of the ext3 filesystem, but it seems long dead. There's more mention of it here as well.

Hmmm...doing some Googling, I found this page that may have a useable download, but it's in alpha form.

It also looks like you can use LVM to create snapshots as well. I'll have to look at that more myself.

Whenever a file is to be modified, and its contents must be preserved in a snapshot, SnapFS creates a new inode in the filesystem to hold the snapshot version. An extended attribute which points to the snapshot inode is then attached to the visible version of the file. The actual blocks of the file are shared between the current file and the snapshot until they are changed; at that point the SnapFS "copy on write" mechanism makes copies of the affected blocks . Snapshots are thus relatively efficient in their use of storage, especially in situations where only parts of files are changed. For example, a snapshot of that huge web server log file, which is only appended to, does not duplicate the log entries that are shared between the current and archived versions.