Slashdot Mirror

Is anyone else wondering why someone would be trying to break into the development server of the Debian distribution?

Maybe someone is trying to "own" every Debian-based machine by slipping their own "minor bug" into it undetected.

This is where distributed, public-key-signed version control (like in monotone) would save the day. No one would be able to sneak something into the version-control archive because all change packets are uniquely identified and signed with a developer's public key.

http://www.venge.net/monotone/

I've been in your shoes for fifteen years now. I originally learned programming to play on the Commodore 64, but really took it up when I was a SysOp of a BBS (WWIV 4.2 at the time, tons of mods out there, some of them quite good). I started writing my own utilities and tweaking mods to suit my own liking. Believe it or not, but I still have most of the code from back then. It has shuffled through a dozen various machines and hard drive upgrades. I've learned a few semi-obvious things about keeping track of things over that time. Some code/projects will be lost. This is just the way things go. If you don't take really good care of your data, it will disappear into the ether. But honestly, that's the way it should be. My first program used printf() and hard-coded ANSI sequences. It is completely useless anymore and deserves to be lost in time. However, to keep track of the stuff you do think may be useful as more than a learning experience, I would recommend a few things. Keep Backups. This isn't just like using a Version Control System (VCS), this is more basic. You will become bored with projects and many of them will end up shelved somewhere on your hard drive. If you do want to keep them, make at least two backups. Your projects won't be very big, so you can probably fit several hundred on a single CD. Make two, in case one flakes on you. I also keep my projects on a couple of machines (Again, they're usually tiny, so there isn't a hard drive space hit). Also, having your original source code rather than an odd archive makes importing into a new VCS really easy. Remember that it takes work to replace code that's lost. You can't just re-download it from somewhere. Learn good coding practices. Believe me, they are worth your weight in gold. There is nothing worse than getting lost in your own code weeks/months/years after the fact because you couldn't indent properly, or wrote overly complex run-on functions. Also, good coding practices will really help if you want to adapt some piece of code into a new project. Keep your interfaces clean and document them. Clean, documented interfaces make for better code re-use and unless you go nuts with the documentation, it won't add more than 5% to your coding time. Your coding methodologies will change as your skills improve, but learning to write decent code early will usually mean more of your code will work in the future. Use a VCS. People have recommended CVS and SVN, but I would actually recommend Monotone. I discovered it when Linus was kicked off BitKeaper, and for small projects I really think it's ideal (It may even work well for large projects, but I haven't asked the OpenEmbedded guys how it's working out for them). It doesn't have the same problems I've seen with CVS and SVN (Namely files being locked and different concurrent versions of files breaking the code check-in). It doesn't require a server to be setup (Though it has a server function if you feel so inclined); it keeps everything in a single-file-database where ever you decide to put the file (You may want to keep all your databases in one location for easy backup, or have each database be in the directory tree of the project; whatever you want). It runs on Windows, Mac, and Linux, and they can all talk together if you do decide to setup a central server. One down side is that it's still relatively fluid, meaning that they change things that aren't backward-compatible. That being said, I've had some databases from Monotone 0.18 and now that I'm using 0.25 (Three non-compatible changes later), they still work. Regardless of which one you choose, learn to use it. And for the love of all that's holy add comments when you check-in code! Even short notes about what you were working on can spark your memory if/when you revisit a project, especially if you're in deep geek mode and your brain is moving at escape velocity.

We are happy to use Linux and generate some revenue from it (try to, anyway). We use a monotone install with our added crap on top. We keep a clean separation of what's opensource and need to provide source for... if asked:

• GPL: The linux kernel, Linux drivers we write (the odd USB driver built using the USB skeleton driver), everything in the linux distro.
• Special provision for busybox which are happy to abide by their license. Don't and you'll end-up in their Hall of Shame. Not worth the aggro.
• LGPL: Everything LGPL we need to compile against, is compiled as shared objects. No static linking!
• Closed source... a couple of our daemons which do all the work. This is our code. Maybe we'll open it some day, maybe not.
• Giving back. Revenue so far is not worth talking about, but we contributed bug fixes and enhancements back to the community. Some bits and bobs people could find some use for, we put on sourceforge.

The simple rules of opensource: Abide by the licenses and try to contribute back if you can. Do that and it'll translate into real karma in the next life... and maybe into some profit, one hopes!

Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.

It's too bad they didn't chose something more advanced like Vesta, or Codeville, or monotone, or Darcs.

Actually monotone works on windows as both client and server.

Is git so fundamentally different from every other SCM out there...

No. A lot of git's concepts are taken from monotone. It's basically monotone without the sanity-checking and without the SCM built on top of it.

Perhaps this is old news, but it is worth repeating...

Monotone's change log

Sun Apr 10 17:49:25 PDT 2005

0.18 release. performance improvements, features, and bug fixes.
This release is dedicated to Shweta Narayan.

- most operations sped up by a factor of 2 or better; many sped up by up several orders of magnitude.
- special thanks to Matt Johnston , Derek Scherger (derek@echologic.com), Linus Torvalds (torvalds@osdl.org).

What would put Monotone and Bazaar in a class above Subversion?

I'm not trying to back Subversion here, it's just that I'm slightly familiar with it and am interested in knowing what limitations it might impose that these other systems might not.

What features are needed/why BK is so great is a long topic, but being fully decentralized and being able to run over email are some of the major features.

Being able to run over email is an interesting feature... one I'm not sure I understand the need for, if you have to have a fully-featured client to do merges and the like anyway. I guess it's so you don't need to assume network availability ? What does that mean, 'run over email'... it sounds a bit like a method of 'client-independant server API', why provide that functionality over mail and not in some other manner as well?

Is there a forum or something somewhere that this whole 'What features are needed and why" discussion can be examined ? What Linux kernel development list(s) should I be looking at if I'm interested ?

Larry McVoy says in the interview that one problem with reverse-engineering BK is "Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it."

This would make me feel so good about using BK for my commercial project. Apparently, if anyone corrupts their own personal changeset store, the whole system is screwed.

Note that Monotone is another very similar to Darcs but with more features. I don't know about the performance of either.

Somehow Arch was immediately mentioned on the original thread about Linus's intent to switch away from BitKeeper, but somehow only Subversion has been mentioned on this one. Arch was created specifically with the goal of replacing BitKeeper as the SCM for the Linux kernel source, as it says on their web page:

It is somewhat well known, these days, that some of the core developers of the Linux kernel are using a revision control system which is not free software. There is a need to create a free software alternative to that system and to do so is one of the goals of the arch project

Linus is looking into Monotone as you can see here.

Might want to start figuring out how to migrate to that, instead of pestering him about subversion.

A friend of Larry McVoy's (yes, I'm told he has those) once told me that "Everyone I know who has had anything to do with Larry has eventually either been sued or threatened with a lawsuit by him." By contrast, while Monotone is arguably not yet ready for prime time, Graydon Hoare is a smart, nice, reasonable person who I trust to do the right thing. Thank goodness BitKeeper is out of the picture: maybe now kernel developers like myself who wouldn't touch BK with a 10 foot pole can soon sync their source with Linus' repositories.

I suggest anyone who's looking for "something better than CVS" to take a tour through the monotone documentation.

These docs are just excellent (reading is believing!) and provide a great intro to the monotone src control system. Monotone is decentral (a bit like bitkeeper), keeps the repository in a single file (yay!), does 3-way merges and, on top, the syntax appears to be bearable!
Try darcs or arch for a day and you'll understand why I had to make that last part bold...

I'm giving it a testride right now and according to this rumor Linus has it on his radar, too...

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

In the postscript to his announcement on moving away from BitKeeper, Linus rules out Subversion and states that Monotone "seems to be the most viable alternative".

Until I read that I had never heard of Monotone.

At the end he says monotone seems like the best replacement.

The question is where to go now? My preference would be GNU Arch, as it's more decentralized.

Hi Bruce,

You want to keep an eye on Monotone. Recently, it has gone through a redesign specifically aimed at making it changeset-oriented, with a view to replacing BitKeeper. It has a ways to go, but the project is active and the work is professional. Arch and Subversion are both worthy and usable systems right now, and many projects are already working happily with one or the other.

Regards,

Daniel

Nice list. An interesting project you didn't mention is monotone.

Okay... but here's my point: Every single example that shows how elegant Haskell and OCaml are uses lists. The 4-line Quicksort example for Haskell uses lists. All of the code that demonstrates easy reuse of functions and functions taken as arguments uses lists (like how easy it is to implement quite complicated algorithms using only map and filter, for example).

Or perhaps more correctly, "every single example that you've seen". For a real quick one, look at Jason Hickey's Intro to OCaml (pdf) and have a quick peek at his Red/Black tree implementation. Or even cooler (if you're into that sort of thing) is the ever famous One Day Compilers talk.

But what you're saying in #1 above is that in "production," speed-sensitive code, no one is using lists... this would mean that no one is using map, filter, or any other pieces of reusable primitive code. So, they are instead all using mutable data structures... I.e., they are programming with side-effects and loops (random access instead of recursion, even when ever element of an array/list needs to be accessed/processed).

No. What he's saying in that you should use the best data structure for the job. Your best bet would have been to use the Hashtbl module from the standard library, or if you wanted to stay in the purely applicative, the Map module (also in the standard library) would have been loads faster...

You are aware that there are more purely functional data structures (pdf) (OCaml implementations) than the list, don't you?

So... maybe you can re-write higher-order memoization code using more efficient data structures? I would love to see that code, and I'm sure the OCaml community would benefit from having that in their toolbox.

Here's a pretty neat example that uses arrays in a naive way, but you could certainly use, say, a map instead... And I'm pretty sure the OCaml community (by which I mean the people who would have helped you improve your code had you asked them) know about things like this.

I don't think I spread any falsehoods. I mean, my experiment was real, and the results are real, and the code is there for people to inspect and try on their own. I also talked in my /. post about OCaml code that is isomorphic to C being fast, but functional code perhaps not being fast.

Yes. And we inspected it, found it to be poorly written, and told you so. The "falsehood" here is that you claim that code written in a functional style is slow, when you really should have said "my code written in a naively functional style is slow". If I fill my gas tank with water, my car sure is slower than walking, therefore all cars are slower than walking... right?

Trust me... I am *dying* to use OCaml or Haskell for real-world programming. I have spent the past month or so exploring these languages and trying to apply them to real programming problems. Especially when shootout results showed that OCaml was sometimes faster than C, and when I discovered that OCaml was much faster than Hasell, I was really starting to think that OCaml was a possibility.

I put a link to tho OCaml mailing lists above. Use it. Ask questions of the list (you may want to start with the beginner's list). They can help you learn the language faster and better than google will.

However, the ONLY reason why I would want to use OCaml is to take advantage of the expressiveness of pure functional programmin

Maybe even arch.

try it here

To sum up, clearcase is very good but very expensive. I have been searching for a version control system for my private use, and I have not found anything where branching, merging and labeling is as easy as in clearcase (if possible at all!).

Granted I have used clearcase for years now and know it quite well. But many of the other version control system at best provides shadows of what I want and expect a version control system to do. The last system i looked into was monotone and as far as I can see it only supports merging from the head (LATEST in clearcase). When it cannot merge from an non-head element it is useless for me.

What I really, really, really want to do is the following:

Put the Linux kernel source into version control. The main, "official" version from Linus I would put on a branch named "linus". Then I would subbranch this with other branches, for instance "fedora" for the kernel provided from Fedora, "planetccrma" for the kernel provided by Planet CCRMA, and probably some other branches for things like swsusp.

When checking in a new official kernel I want to attach a label, say "LINUX_2_6_9". I then want to be able to use this label as a reference when merging. The swsusp project is fully up to date with regards to kernel versions, but say that the last patch from then only was for kernel version 2.6.5. I then want to be able to subbranch the swsusp branch with "myswsusp" and try to merge from LINUX_2_6_9. Of course the version control system should find out which version is the common parent, remember if any merges has been done previously and assist as much as possible in a 3-way merge.

If any of you readers have a suggestion for a free system capable of such a scenario, please make yourself heard. I know I have looked into Arch a very long time ago, I guess I will look into it again now.

I thought monotone, codeville, and darcs all used the distributed repository model as well as arch & bk. They may be a little further behind in terms of features or surrounding tools, but each one does have some interesting theory/philosophy of version control behind it.

And darcs is written in haskell, so it wins points for enjoying the soundness and showing once again that pure FP can be and is used in the "real world"...

I wouldn't discount any of them yet, but I agree that the subversion fanboys are pretty damn irritating, trying to get every project to switch away from CVS now, when it would clearly be better to wait and see how some of the more revolutionary free systems evolve.

However, anything is better than clearcase...

Arch is not the only one, monotone is another, cleaner tool.

The monotone project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.

Twonz is a secure way of generating a new password for each site: the password is based on an SHA-1 hash of the site's name and a single passphrase used for all sites. So you need only remember a single passphrase (twonz calls it a 'pad'), but each site gets a different password and you can't work out one site's password from another. It's a shame this is not built in to a web browser, it is much saner than Mozilla's password manager.

If RMS wants to rant about revision control systems, he'll need to say that CVS needs to be replaced with a more functional alternative (Subversion, perhaps), not BK.

Or Monotone, perhaps.

Monotone is a new revision control system being developed by Graydon Hoare at RedHat. It's notable for having cryptographic hashs and signatures implemented through the entire system.. each delta in the archive has a signature associated with it, as does each bit of information about the delta.

I'm not sure how well such a system would perform, but there's no sneaking data into a system like that without subverting (sorry) someone's private GPG key.

If all the machines _are_ identical and have a common filesystem, then it might be a bit quicker to use something simple like Doozer or PVM-enabled GNU make. But if compile time is dominated by just crunching the code then it might not make too much difference.

• I'd like the app itself to be password-protected, although that's not terribly necessary
• I'd like to make sure that the transformation to get the final password is, indeed, a one-way transform. That way, given one password and the name of the box, you can't reverse engineer the "master" password.
• It'd be nice to choose between a list of algorithms used to generate the master password, and to be able to tweak the algorithms for your own personal use.

I found a project called Twonz that does something like that. You input a "base" password, and then the name of the host, or IP, or whatever, and it computes what the actual password would be. It looks a bit incomplete for a scalable solution; as I mentioned, I'd like to have the app itself be password protected, and have the ability to mess around with the generation algorithm, but the basic bit is there . . .

Just an idea, anyway. :)