Show HN: BitKeeper – Enterprise-ready version control, now open-source

In more ways than you'd know. They're already pre-backdoored like almost all other chips for debugging purposes in what's called Design for Test or scan chains or scan probes or something. Much hardware hacking involves getting to those suckers to see what chip is doing.

Now, for remote attacks, you can embed RF circuitry in them that listens to any of that. You can embed circuits that receive incoming command, then dump its SRAM contents. You might modify the I/O circuitry to recognize a trapdoor command that runs incoming data as privileged instructions. You can put a microcontroller in there connected to PCI to do the same for host PC attacks. I know, that would be first option but I was having too much fun with RTL and transistor level. :)

You make that sound easy. The POWER and SPARC T/M chips are amazing. Yet, Intel Xeon still dominates to point that they can charge less and invest more. That's with one hell of a head start from Sun and IBM. The other's... Alpha, MIPS, and PA-RISC... folded in server markets with Itanium soon to follow.

You can't just compete directly in that market: you have to convince them yours is worth buying for less performance at higher price and watts. Itanium tried with reliability & security advantages. Failed. Fortunately, Dover is about to try with RISC-V combined with SAFE architecture (crash-safe.org) for embedded stuff. We'll see what happens there.

No, they are magic: arbitrary hardware designs run without the cost of chip fabrication. Two non-profit FPGA's, one for performance at 28nm & one for embedded at 28SLPnm, would totally address the custom hardware and subversion problem given we could just keep checking on that one. The PPC cores and soon Intel Xeons already show what a good CPU plus FPGA accleration w/ local memory can do for applications.

Yeah, buddy, they're like magic hardware. Even if they aren't ASIC-competitive for the best ASIC's. Still magic with a market share and diverse applications that shows it. :)

> I think people have a way too high tolerance for this kind of crap.

I agree.

The core problem with Git is that it was designed to serve the needs of the Linux kernel developers. Very, very, very few projects have SCM problems of similar complexity, so why do so many people try to use a tool that solves problems they don't have? Much of that internal complexity extends up into the Git interface, so you're paying for complexity you don't need.

Others in this thread have praised hg and bzr for their relative simplicity for a DVCS. I'd also like to point out Fossil.

In the normal course of daily use, Fossil as simple to use as svn.

About the only time where Fossil is more complex is the clone step before checking out a version from a remote repository.

Other than that, the daily use of Fossil is very nearly command-for-command the same as with svn. Sometimes the subcommands are different (e.g. fossil finfo instead of svn status for per-file info in the current checkout) but muscle memory works that out fairly quickly.

Most of that simplicity comes down to Fossil's autosync feature, which means that local checkout changes are automatically propagated back to the server you cloned from, so Fossil doesn't normally have separate checkin and push steps, as with Git. But if you want a 2-step commit, Fossil will let you turn off autosync.

(But you shouldn't. Local-only checkins with rare pushes is a manifestation of "the guy in the room" problem which we were warned against back in 1971 by Gerald Weinberg. Thus, Fossil fosters teamwork with better defaults than Git.)

Branching is a lot saner in Fossil than svn:

1. Fossil branches automatically include all files in a particular revision, whereas svn's branches are built on top of the per-file copy operation, so you could have a branch containing only one file. This is one of those kinds of flexibility that ends up causing problems, because you can end up with branches that don't parallel one another, making patches and merges difficult. Fossil strongly encourages you to keep related branches parallel. Automatic merges tend to succeed more often in Fossil than svn as a result.

2. Fossil has a built-in web UI with a graphical timeline, so you can see the structure of your branches. You have to install a separate GUI tool to get that with most other VCSes. The fact that you can always get a graphical view of things means that if you ever get confused about the state of a Fossil checkout tree, you'll likely spend less time confused, because you're likely also using its fully-integrated web UI.

3. Whereas svn makes you branch before you start work on a change, Fossil lets you put that off until you're ready to commit. It's at that point that you're ready to decide, "Does this change make sense on the current branch, or do I need a new one?"

Fossil's handling of branches is also a lot simpler than Git's, primarily because the local Fossil repository clone is separate from the checkout tree. Thus, it is easy to have multiple Fossil checkouts from a given local repo clone, whereas the standard Git workflow is to switch among branches in a single tree, making branch switches inexpensive.

(And yes, I'm aware that there is a way to have one local Git checkout refer to another so you can have multiple branches checked out locally without two complete repo clones. The point is that Git has yet again added unnecessary complexity to something that should be simple.)

We would love that. Contact dev@bitkeeper.org if you have any questions/issues.