[00:00.000 --> 00:13.760]  Hello everybody, welcome back to the Stack Overflow podcast, a place to talk all things
[00:13.760 --> 00:16.000]  software and technology.
[00:16.000 --> 00:21.280]  I'm your host Ben Popper, world's worst coder, joined as I often am by my colleague and collaborator
[00:21.280 --> 00:25.760]  Ryan Thor Donovan, editor of our blog and our newsletter.
[00:25.760 --> 00:29.800]  Ryan, you helped to set up today's episode, so refresh me here.
[00:29.800 --> 00:32.040]  Who's our guest and what are we going to be chit-chatting about?
[00:32.040 --> 00:35.480]  So it's Pierre Etienne Meunier.
[00:35.480 --> 00:42.960]  He reached out because of this version control article I wrote, and he's creator, I believe,
[00:42.960 --> 00:49.720]  of Pijoul, which was briefly mentioned in the article, didn't hear much about it, but
[00:49.720 --> 00:53.640]  somebody was interested in that it used patch algebra.
[00:53.640 --> 00:54.640]  Cool.
[00:54.640 --> 00:57.920]  This was in the article about you're not using Git, but why?
[00:57.960 --> 00:59.760]  Is this where we're getting back to?
[00:59.760 --> 01:03.840]  Yeah, it's the version controls that people use other than Git.
[01:03.840 --> 01:04.840]  Okay, gotcha.
[01:04.840 --> 01:08.080]  Well, then without further ado, Pierre, welcome to the program.
[01:08.080 --> 01:10.080]  Well, thanks for having me.
[01:10.080 --> 01:17.440]  Yeah, I did read the article and I was super interested in all the options and alternatives.
[01:17.440 --> 01:24.040]  The fact that Pijoul was just briefly mentioned was like, okay, yeah, they probably haven't
[01:24.040 --> 01:25.840]  heard much of it.
[01:26.800 --> 01:31.320]  This is based on a previous version control system called Darks.
[01:31.320 --> 01:36.560]  Some of the ideas come from Darks, but at some point we were using Darks, like me and
[01:36.560 --> 01:42.040]  a colleague, Florent Becker, we're using Darks to write on paper about something completely
[01:42.040 --> 01:47.360]  unrelated, like the tilings and geometry in computer science.
[01:47.360 --> 01:53.920]  After work, we went out for a beer and started discussing version control, and Florent told
[01:53.960 --> 02:01.400]  me that, well, as one of the last remaining maintainers of Darks, he could tell me that
[02:01.400 --> 02:06.800]  the algorithm was not proper, it wasn't an actual algorithm, there was a bunch of holes
[02:06.800 --> 02:14.440]  in it, and this explains why it was so slow in dealing with conflicts.
[02:14.440 --> 02:18.280]  And so we started chatting about, oh, look, we're computer scientists, and so our job
[02:18.280 --> 02:23.160]  is to design algorithms and study their complexity, so, well, this is a job for us.
[02:23.160 --> 02:28.440]  We're also working on a model of distributed computing, so this was like, okay, this is
[02:28.440 --> 02:32.760]  exactly the kind of stuff we should be interested in.
[02:32.760 --> 02:39.200]  This is one of our chances to have an impact on something, and so there we started working
[02:39.200 --> 02:45.160]  on some bibliography first, we found some arguments about using category theory to solve
[02:45.160 --> 02:51.040]  the problem, and then we started working on that and writing code and code and more code
[02:51.120 --> 02:57.120]  and debugging, and it turned out to be a much bigger project than we first imagined.
[02:57.120 --> 03:02.120]  And so when I saw Ryan mention Darks, and yeah, well, there's this new thing coming
[03:02.120 --> 03:08.120]  out, maybe someday, but it doesn't look finished yet and something, I reached out and was like,
[03:08.120 --> 03:13.240]  oh, yeah, but, well, you're interested in version control, and probably there's something
[03:13.240 --> 03:15.320]  we could chat about together.
[03:15.320 --> 03:19.280]  Yeah, you sit down for a beer, you start talking version control, and things always go a bit
[03:19.280 --> 03:22.240]  farther than you expected, I think that sounds about right.
[03:22.240 --> 03:26.000]  Pierre, can you give people just a super short synopsis?
[03:26.000 --> 03:29.600]  We started out talking about you already as an engineer and stuff like that, but how did
[03:29.600 --> 03:30.960]  you get into this field?
[03:30.960 --> 03:34.760]  What got you started down this path to the point where you're sitting around a bar coming
[03:34.760 --> 03:36.360]  up with your own version control system?
[03:36.360 --> 03:39.720]  How did you get educated in this world and enter into software development?
[03:39.720 --> 03:46.560]  I'm not educated at all, really not, I don't know anything about software engineering,
[03:46.560 --> 03:55.120]  I'm not an engineer myself, so I started coding when I was a bit young, I guess, on an old
[03:55.120 --> 04:00.800]  computer that my uncle left when he went out for some trouble.
[04:00.800 --> 04:08.360]  I think I was like 12 back then, and then I've been coding on and off, and then started
[04:08.360 --> 04:14.720]  studying mathematics and physics, got into logics, theory improving, that kind of stuff,
[04:14.960 --> 04:21.720]  and where I'm from, there's one thing that is studied in France, which I don't think
[04:21.720 --> 04:25.040]  anywhere else in the world, and that's the Old Camel language.
[04:25.040 --> 04:32.200]  The Old Camel language is when you grow up as a French man and go to university to study
[04:32.200 --> 04:38.200]  general science, like the first two years of basic mathematics, science, physics, and
[04:38.200 --> 04:44.200]  all that, you get told that, well, this Old Camel thing, that's really something French
[04:44.240 --> 04:48.440]  and it's really something we should be proud of, because there's this legend of computing,
[04:48.440 --> 04:52.760]  Xavier Leroy, he did everything there, and he was the first to show the world that you
[04:52.760 --> 04:58.040]  can design a functional programming language that's at the same time really fast.
[04:58.040 --> 05:03.400]  But then I was interested in that and wanted to study computer science, did a PhD in computer
[05:03.400 --> 05:11.000]  science, like theoretical computer science, but then I ended up working on a theoretical
[05:11.000 --> 05:15.560]  computer science. What people call here fundamental computer science doesn't mean it's
[05:15.560 --> 05:21.000]  particularly important or useful, it just means it's like the basic things, the foundational,
[05:21.000 --> 05:27.000]  like probably foundational is a better name for that. So yeah, that's how I got started.
[05:27.000 --> 05:32.920]  So, you know, in researching the article, I started off way back in the day on Visual
[05:32.920 --> 05:39.480]  Source Safe, and it seemed like there were natural developments, but Visual interested
[05:39.480 --> 05:43.960]  me because it uses patch algebra, right? Can you talk about what that is?
[05:44.600 --> 05:51.720]  Yeah. So patch algebra is a completely different way of talking about version control,
[05:52.360 --> 05:57.560]  of thinking about version control. Why? Well, because instead of controlling versions,
[05:57.560 --> 06:02.360]  you're actually controlling changes. That's completely different. It's actually the dual
[06:02.360 --> 06:09.160]  of versions is changes. So instead of just saying, well, this version came after that version,
[06:09.560 --> 06:18.600]  which is something that's about CVS, RCS, SBN, Git, Mercurial, Fossil, and whatnot, like all
[06:18.600 --> 06:24.760]  this family of systems. So they keep controlling versions, they keep insisting on the version
[06:24.760 --> 06:31.800]  and the snapshots that come one after the other. In contrast to that, most of the research about
[06:32.360 --> 06:37.240]  parallel computing, about distributed data structures, focuses on changes.
[06:38.040 --> 06:43.800]  So a change is, for example, well, I introduced the line here and deleted the line there. I
[06:43.800 --> 06:49.880]  renamed the file from X to Z. I deleted that file, for example. I introduced a new file.
[06:51.000 --> 06:57.240]  I solved the conflict. That's also super important. And in contrast to talking only
[06:57.240 --> 07:05.000]  about snapshots and versions, this gives you much higher flexibility because all systems that deal
[07:05.000 --> 07:12.760]  with versions actually show versions or commits or snapshots as changes. If you look at a commit
[07:12.760 --> 07:17.720]  on GitHub, for example, you will never see the actual commit, as in you will never see the actual
[07:17.720 --> 07:23.720]  full entire version. What GitHub will show you when you ask about the commit is what it changed
[07:23.720 --> 07:29.000]  compared to its parents. So actually, there's a fundamental mismatch in the way people think
[07:29.000 --> 07:35.160]  about version control when they use Git. They think, well, everything they see is changes or
[07:35.160 --> 07:40.520]  differences. And then everything they need to reason about when they actually use the tool
[07:40.520 --> 07:48.040]  is versions. So how can you reason about that? Well, we found ways around it, right? We have all
[07:48.040 --> 07:55.640]  these workflows and Git gurus that will tell you what you should and should not do and all that.
[07:55.640 --> 08:01.240]  You have good practices and all these things. But fundamentally, what these good practices aim at
[08:01.240 --> 08:06.600]  is getting around this fundamental mismatch between thinking about having to think about
[08:06.600 --> 08:13.800]  something you never see. So what patches and change algebra gives you is that now you can reason about
[08:13.800 --> 08:19.240]  things. So you can say, well, these two patches are independent, so I can reorder them in history.
[08:19.880 --> 08:27.560]  This sounds like a completely useless and unimportant operation, but it's not. What that
[08:27.560 --> 08:34.280]  means is you can actually, for example, you can take a bug fix from a remote and
[08:34.280 --> 08:39.880]  cherry pick it into your branch without any consequences. You will just cherry pick the
[08:39.880 --> 08:45.080]  bug fix and that's it. And it will just work. You won't have to worry about having to merge that
[08:45.080 --> 08:50.120]  branch in the future. You won't have to worry about any of that. And if that bug fix turns out
[08:50.120 --> 08:56.280]  to be bad and turns out to be inefficient, for example, and you've continued working,
[08:56.280 --> 09:01.720]  well, you can still go back and remove just that bug fix without touching any of your further work.
[09:02.360 --> 09:07.800]  So this gives you this flexibility that people actually want to reason about. So when you're
[09:07.800 --> 09:13.640]  using Git, you're constantly rebasing and merging and cherry picking. And there's also all these
[09:13.640 --> 09:19.400]  commands to deal with conflicts, which Git doesn't really model. There's no conflict in
[09:19.400 --> 09:25.320]  commits. Conflicts are just failures to merge and they're never stored in commits. They're
[09:25.320 --> 09:30.600]  just stored in the working company. And so when you fix a conflict, Git doesn't know about it.
[09:30.600 --> 09:35.400]  It just knows that, oh, here's the fixed version. So this means that if you have to fix the same
[09:35.400 --> 09:40.120]  conflict again in the future, well, Git doesn't know about it. It just knows that, well, there
[09:40.120 --> 09:44.920]  was this conflict or there was these two versions that the user tried to merge. And then there was
[09:44.920 --> 09:49.000]  this version with the conflicts fixed, but it doesn't know how you fixed the conflict.
[09:49.000 --> 09:54.920]  So your conflicts might reappear and you might have to solve them again, or you might even have
[09:54.920 --> 09:59.800]  conflicts that just appear out of the loop. And then you don't know what these conflicts are about
[09:59.800 --> 10:05.240]  and you still have to solve them. And in contrast to them, having this ability to reorder your
[10:05.240 --> 10:11.560]  changes gives you a possibility to just remove one side of the conflict without touching the other
[10:12.200 --> 10:18.360]  or model precisely what happens when you change things. It also forces you to look at all the
[10:18.360 --> 10:23.880]  cases. When you look at all the cases of a merge, you're like, okay, what are all the cases of a
[10:23.880 --> 10:28.920]  conflict? Well, for example, if two people introduce a file with the same name in parallel, it's a
[10:28.920 --> 10:35.880]  conflict. If I change a function's name and if Alice changes a function's name and Bob at the
[10:35.880 --> 10:40.280]  same time in parallel calls that function, what should happen? Is that a conflict? Well,
[10:40.280 --> 10:47.960]  Girola actually doesn't model that, but it does model a large number of cases of conflicts. And
[10:47.960 --> 10:54.440]  so this is much easier. It will probably save a lot of expensive and ingenious time.
[10:54.600 --> 11:02.520]  Listen to season two of Crossing the Enterprise Chasm, hosted by Work OS founder, Michael
[11:02.520 --> 11:07.560]  Greenwich. Learn how top startups move up market and start selling to enterprises with features
[11:07.560 --> 11:13.880]  like single sign-on, directory sync, audit logs, and more. Visit workos.com slash podcast,
[11:13.880 --> 11:16.360]  make your app enterprise ready today.
[11:16.360 --> 11:25.560]  Yeah, in my experience, the merge conflicts are very manual. So it takes a lot of time to actually
[11:25.560 --> 11:31.400]  resolve them. Does visual and the patch algebra, does that help reduce the manual load?
[11:31.400 --> 11:36.920]  Yeah, absolutely. So first of all, you have much less conflicts. Why? Well, because all these
[11:36.920 --> 11:41.960]  artificial conflicts that gets just invents out of nothing, just because you didn't follow the
[11:41.960 --> 11:47.160]  good practices, for example, or you have long lived branches for some reason, because your
[11:47.160 --> 11:54.680]  job requirements won't need that. So you won't have all these conflicts. So there is a lot less
[11:54.680 --> 12:00.760]  manual work to do first, because there is less problems to fix. And then when you're in the
[12:00.760 --> 12:07.960]  process of solving the conflicts, what happens in Girola is that we keep track in the data structure
[12:07.960 --> 12:15.080]  used to merge the batches. We keep track of who introduced which bytes. It's down to the byte level.
[12:15.080 --> 12:21.880]  It's still super efficient, but we know exactly who introduced which bytes in which batch.
[12:21.880 --> 12:27.640]  We can tell, okay, this byte comes from that batch. And so this is a really useful tool to,
[12:27.640 --> 12:31.880]  you know, if you want to solve conflicts, because you can, while you're solving a conflict,
[12:31.880 --> 12:38.120]  you can know exactly what the sides of the conflict are, and this how to solve them much
[12:38.120 --> 12:44.040]  well, in my experience, at least how to solve conflicts much, much easier. So I think this is
[12:44.040 --> 12:51.320]  going to save a lot of time. I was going back in our history of podcasts we recorded, and I
[12:51.320 --> 12:56.840]  remember now we sat down with Arthur Breitman, who is also educated in France to talk about Tezos
[12:56.840 --> 13:03.800]  and the blockchain, and why he loves OCaml. So you're right. For every child who was educated
[13:03.800 --> 13:07.720]  in that, something interesting came out of it. A source of national pride and some interesting
[13:07.720 --> 13:12.760]  ideas about functional programming. Well, the initial version of Rust was also really OCaml.
[13:12.760 --> 13:18.760]  See? Today I learned. So one of the interesting splits I found in the version control article was
[13:19.320 --> 13:26.680]  between folks who deal with mostly code and their source control, and places like
[13:26.680 --> 13:33.160]  video game companies that have large binaries. Does patch algebra apply to the binary files as well?
[13:34.040 --> 13:39.240]  Absolutely. Because when you're describing changes, when you're describing what happens
[13:39.240 --> 13:47.000]  in the change, you might say things like, oh, Alice today introduced that file. She added the
[13:47.000 --> 13:55.400]  file to the repository, and the file is like two gigabytes in size. And so there's the actual two
[13:55.400 --> 14:00.760]  gigabytes, which Git might store, for example. Well, you better use aliphats if you do that.
[14:00.760 --> 14:07.400]  But in a classic version control, you might just add the file to SVN, for example. You might just
[14:07.400 --> 14:13.480]  upload the file, and that's it. When you're describing changes, so you can try to do that
[14:13.480 --> 14:18.840]  in darks, but I don't recommend it for performance reasons. But in people, what you'll tell actually,
[14:18.840 --> 14:24.440]  you'll be like, okay, here's a change. Alice introduced two gigabytes. That's what I just
[14:24.440 --> 14:30.680]  said is very short. And it's just like one file, and the information is really tiny. It's just like
[14:30.680 --> 14:34.840]  logarithmic in the actual two gigabytes. And then there's the two gigabytes themselves.
[14:35.640 --> 14:41.240]  And the thing is, using patches, you can separate the contents of the patches from what the patch
[14:41.240 --> 14:46.360]  did. So by modeling the actual operation, you can be like, okay, I can apply this patch without
[14:46.360 --> 14:52.120]  knowing what's in the file. I can just say that I added two gigabytes without telling you what the
[14:52.120 --> 14:59.880]  two gigabytes are. So this sounds like, okay, how can this be useful? Well, if Alice goes on and
[14:59.880 --> 15:07.000]  writes multiple versions of the two gigabyte file, she might just go on and do that, upload a few
[15:07.000 --> 15:11.880]  versions. And then when you want to know what the contents of the file, you don't have to download
[15:11.880 --> 15:15.960]  directly, you just have to download. Well, Alice added two gigabytes here, then she modified the
[15:15.960 --> 15:22.040]  file, added another gigabytes, then she compressed off and did something. And then like there's
[15:22.040 --> 15:28.040]  another three gigabytes patch. But then you don't have to download any of that, just have to download
[15:28.040 --> 15:36.600]  the information that Alice did some stuff. And then after the fact that you applied all of Alice's
[15:36.600 --> 15:41.400]  changes, you can just say, okay, here are the two, like the remaining parts of the file that are
[15:41.400 --> 15:47.400]  still alive after all these patches are those bytes. And that now I just have to download
[15:47.400 --> 15:53.560]  those bytes. So maybe I'll just end up downloading one full version of the file or two gigabytes,
[15:53.560 --> 15:57.640]  but I won't download the entire history, going through all the versions one by one.
[15:58.600 --> 16:04.920]  So like, I believe I've never tested that at scale on an actual video game project. But I
[16:04.920 --> 16:11.160]  believe that this has the potential to save a lot of bandwidth and make things a lot easier
[16:11.160 --> 16:15.640]  for video game studios. And actually, I have a project going going on with the authors of
[16:16.440 --> 16:23.720]  Godot, the open open source video game studio, like a video game editor. So we'll see what
[16:23.720 --> 16:31.000]  goes out of that. But we're totally aligned in what we want to do. We're like fully open source.
[16:31.080 --> 16:36.360]  So there's something exciting and new going on in the video game industry.
[16:37.320 --> 16:40.280]  I think Godot is really bringing in a lot of fresh air.
[16:40.840 --> 16:47.960]  Yeah, I mean, the fully open source projects are very popular. If you have a bug you want to fix,
[16:47.960 --> 16:53.720]  you can just go fix it. And it's been fascinating to see sort of the race going on these days between
[16:53.720 --> 16:59.560]  the closed corporate world that's developing cutting edge AI, and all of the places like
[16:59.560 --> 17:04.440]  hugging face and stable diffusion and you know, others that are trying to keep pace with them in
[17:04.440 --> 17:08.520]  an open source way and with a kind of a community of contributors. So very cool.
[17:08.520 --> 17:15.320]  Yeah. So we were talking about it doesn't create versions. It seems to me that the version system
[17:15.320 --> 17:21.720]  is sort of a legacy from when we actually burn disks or released binaries to download and install.
[17:22.280 --> 17:28.760]  With your background in distributed computing, do you think that this can be a better way to
[17:29.560 --> 17:32.520]  update and maintain all the distributed systems we have now?
[17:33.080 --> 17:41.960]  Yeah, I hope so at least. So one really cool example I can give is NixOS. So NixOS is not really
[17:41.960 --> 17:47.480]  a Linux distribution. It's actually a language with a massive standard library containing a lot of
[17:47.480 --> 17:54.360]  packages. And you can use this language to build your own system. So that's the promise of NixOS.
[17:55.000 --> 18:01.800]  And so while doing so, for example, if you're maintaining machines in the cloud, you probably
[18:01.800 --> 18:09.400]  want to build an image and use like one custom version of what's called NixPickages, standard
[18:09.400 --> 18:16.040]  library of NixOS. And so you want to customize this in one way or another and then release some
[18:16.040 --> 18:23.480]  of your patches to the official central repository for NixPickages, but then keep some of the others
[18:23.480 --> 18:29.080]  for yourself. So you want these multiple ingits. You would do that by having lots of different
[18:29.080 --> 18:37.160]  branches or feature branches, which you can push to the central repository. Then you would work on
[18:38.360 --> 18:45.320]  another branch, which would be the merge of all those patches plus the changes that occur in the
[18:45.320 --> 18:49.960]  NixPickages central repository. Then this quickly becomes a nightmare to maintain because you have
[18:49.960 --> 18:55.000]  to keep rebasing your changes on top of each other and on top of what happens in NixPickages.
[18:55.000 --> 19:01.800]  Then when your changes get merged in NixPickages, you get conflicts. And so you have to go back to
[19:01.800 --> 19:10.040]  some old comments, which might not even exist. So I believe that maintaining multiple versions or
[19:10.040 --> 19:17.560]  multiple fixes at the same time to one tool can be much, much, much easier using tools like Yehud.
[19:17.640 --> 19:24.040]  So there's one announcement I can make. This is something I've been working on for a while.
[19:24.680 --> 19:30.840]  So Pierrot has its own sort of like GitHub thing for Pierrot, which is called The Nest.
[19:31.480 --> 19:37.960]  And so far it's been not super successful, neither commercially nor, I should say,
[19:38.680 --> 19:45.240]  industrially because it doesn't scale very well. It's been through a data center fire,
[19:45.240 --> 19:52.680]  if you remember, two years ago in Strasbourg in the OVH fire. And so it's using a replicated
[19:52.680 --> 19:57.800]  architecture, but it's not very satisfactory. It's written in Rust. It operates in three different
[19:57.800 --> 20:03.240]  data centers, but it's not easy to maintain. So I've been working on a new serverless infrastructure
[20:03.240 --> 20:09.240]  for that, Function as a Service. So Function as a Service providers don't give you an actual disk
[20:09.240 --> 20:16.040]  on which you could run Yehud, but I've been able to fake Yehud repositories using Cloudfair's
[20:16.040 --> 20:24.360]  KUV, for example. And so this gives infinite scalability and an excellent reliability. So
[20:25.160 --> 20:32.040]  I'm working on that. My prototype is very close to being ready. So I hope I'll be able to release
[20:32.040 --> 20:36.120]  that in a few days, or in the worst case, a few weeks.
[20:40.680 --> 20:44.280]  All right, everybody. It is that time of the show. We want to shout out someone who came
[20:44.280 --> 20:48.280]  on and helped save a little knowledge from the dustbin of history, answered a question.
[20:49.400 --> 20:59.640]  Today, the lifeboat was awarded to Ratchet, R-A-C-H-I-T, passing objects between fragments.
[20:59.640 --> 21:02.360]  That's the question. It's not really a phrase. It's a question. They're using the built-in
[21:02.360 --> 21:06.280]  navigator drawer. They've got fragment menus, and they want to communicate over those fragments,
[21:06.280 --> 21:11.640]  passing data from one to another. This is about Android fragments. So if you ever wanted to pass
[21:11.640 --> 21:16.440]  objects between Android fragments, get that data moving around, we have an answer for you. And
[21:16.440 --> 21:20.040]  thanks to Ratchet and congrats on your lifeboat badge. Appreciate you sharing some knowledge on
[21:20.040 --> 21:25.880]  Stack Overflow. All right, everybody. Thanks for listening. I am Ben Popper, Director of Content
[21:25.880 --> 21:30.280]  here at Stack Overflow. You can always find me on Twitter, at Ben Popper. You can always reach us
[21:30.280 --> 21:34.680]  with questions or suggestions, podcast at stackoverflow.com. If you'd like to show,
[21:34.680 --> 21:41.960]  leave us a rating and a review. It really helps. And thanks for listening. I'm Ryan Donovan. I edit
[21:41.960 --> 21:47.560]  the blog here at Stack Overflow. It's located at stackoverflow.blog. And if you want to reach out
[21:47.560 --> 21:53.720]  to me, you can find me on Twitter at Arthur Donovan. Well, I'm Pierre-Étienne Meunier,
[21:54.440 --> 22:01.000]  and you can browse pirou.com or .org if you want to know more about this project
[22:01.640 --> 22:06.920]  and send a message to pe.pjoul.org. All right, everybody. Thanks for listening,
[22:06.920 --> 22:18.280]  and we will talk to you soon.

[00:00.000 --> 00:06.960]  small projects, one or two or three people using it, but we don't have a big user community like
[00:06.960 --> 00:15.920]  you have with Git. So what makes Fossil better suited for something like NetBSD in this case?
[00:15.920 --> 00:21.760]  You mentioned it's so huge, right? And in fact, I've worked in NetBSD before and I can attest that
[00:21.760 --> 00:28.240]  is pretty big. Just a little log on there. It just never ends, right?
[00:30.240 --> 00:37.600]  Is there a specific way you would kind of port the history from CVS over to Fossil or
[00:38.160 --> 00:46.800]  how would that work? You wrote some scripts that take a CVS repository and export it into Fossil
[00:46.800 --> 00:53.840]  directly. And the TickleTK project used those scripts that you wrote in order to do their import.
[00:54.560 --> 01:00.800]  And so that works. It's available. Use the search engine to look for it. It's not on our website.
[01:00.800 --> 01:05.360]  I think, no, we might have a link to it on our website. And that works well.
[01:07.760 --> 01:14.880]  The thing is, right, the NetBSD repo is just really incredibly massive. When you do a checkout,
[01:14.880 --> 01:22.240]  it has to create 100,000 new files. And every time you do a commit, it has to check the
[01:22.240 --> 01:30.880]  timestamps on all 100,000 files. And that takes time. So commit takes several seconds to happen
[01:30.880 --> 01:37.120]  rather than being instantaneous. So there's a lot of reasons why you might be disappointed
[01:37.120 --> 01:44.080]  with the performance on a Fossil on a project that big. But for reasonable size projects of
[01:44.080 --> 01:50.480]  a few thousand files and only, say, 15 years of development history as opposed to 30,
[01:51.840 --> 01:57.920]  it works great. And it's fast and instantaneous and doesn't give any trouble. To be fair,
[01:57.920 --> 02:03.680]  we really appreciate Jörg's efforts because he's really stressed Fossil. And we've made a
[02:03.680 --> 02:08.400]  lot of significant performance improvements in Fossil based on their experiences with NetBSD.
[02:08.960 --> 02:14.960]  A mere 15 years, huh? It's just a tiny little project.
[02:15.600 --> 02:21.040]  Right. Well, SQLite is 15 years old. So that's sort of our goal. We want to support
[02:21.040 --> 02:30.800]  15-year-old projects. So is there any other way somebody might find their way to start working
[02:30.800 --> 02:37.680]  for you guys? Like actually working as one of your developers there? Yeah. For Fossil, with SQLite,
[02:37.680 --> 02:45.360]  we're very particular about who joins the ranks of committers. There's a very small number of
[02:45.360 --> 02:53.440]  committers in SQLite. But for Fossil, it's wide open. It's a BSD style license. So we do ask that
[02:53.440 --> 03:00.560]  people sign a copyright release that dedicates their contributions or releases their contributions
[03:00.560 --> 03:06.400]  to the code under the same BSD license as the rest of the code. But once we have that copyright
[03:06.400 --> 03:13.600]  release here on file in my fire safe, which is just back over there, we have hundreds of committers
[03:13.600 --> 03:19.680]  to Fossil. Only about a dozen or so of those are active, but we welcome anybody who wants to
[03:19.680 --> 03:26.160]  contribute. It's really easy to contribute. It's all ANSI-C code. ANSI-C and SQLite. Oh, did I
[03:26.160 --> 03:35.600]  mention that the repository in Fossil is an SQLite database instead of in, say, Git or
[03:35.600 --> 03:43.520]  Mercurial where the repository is a pile of files database. So we've got the power of a relational
[03:43.520 --> 03:49.440]  database behind Fossil. And that allows us to do a lot more interesting reporting.
[03:51.200 --> 03:56.720]  And also, but it's also an interesting thing that, so the SQLite source code is kept in Fossil.
[03:57.760 --> 04:05.040]  And Fossil uses SQLite as its repository format. So your listeners can ponder that
[04:05.040 --> 04:16.400]  recursion in their spare time. So was there any specific need to go with ANSI-C versus,
[04:16.400 --> 04:25.440]  let's say, something like C++? Well, no, I started in ANSI-C because Fossil was sort of a follow-on
[04:25.440 --> 04:35.440]  to CVS track. And CVS track started in like 2002. And back then, C++ was not nearly as pervasive
[04:35.440 --> 04:40.720]  it is now. And so we just, we kept going in that tradition. I actually, when I was prototyping
[04:41.440 --> 04:47.440]  Fossil, I worked in scripting language. I worked in Tickle because typically,
[04:48.080 --> 04:54.000]  I see a tenfold productivity enhancement in a scripting language like Tickle or Python or Perl.
[04:56.080 --> 05:03.280]  But in my experiments, I wasn't seeing that with my Fossil prototypes. And so I just switched over
[05:03.280 --> 05:09.840]  to ANSI-C because that allowed me to compile it down into a standalone binary that didn't depend
[05:09.840 --> 05:15.920]  on having an interpreter installed and so forth. And people asked me, well, why is that the case?
[05:15.920 --> 05:22.800]  And I originally finally came to realize that in Fossil, the scripting language is SQL.
[05:23.760 --> 05:28.880]  So we have SQL that does a lot of the heavy lifting of digging things out of the repository.
[05:29.840 --> 05:36.160]  And that works well. And then we also have just plain old ANSI-C to do the low-level bit twiddling
[05:36.160 --> 05:42.960]  that you have to do for delta compression and computing diffs and all these kinds of things
[05:44.080 --> 05:49.200]  that also go into a version control system. So we kind of get the best of both worlds.
[05:49.200 --> 05:53.920]  You've got the full power of SQL to do the really complex things. And then you've got
[05:55.360 --> 06:02.400]  plain old ANSI-C to do the low-level moving bits. And that's actually worked out very well.
[06:02.400 --> 06:10.880]  It was surprising, but it's a good combination. The benefits to the user are that you do get
[06:10.880 --> 06:19.840]  this standalone binary. It's a true cross-platform thing. Now, I know Macurial is another
[06:19.840 --> 06:26.400]  distributed version control system that's written in Python. And they say, well, we're cross-platform
[06:26.400 --> 06:32.880]  because Python is cross-platform. I'm going to argue that Macurial is single platform. Their
[06:32.880 --> 06:39.360]  platform is Python. And you just happen to have Python virtual machines that run on most computers.
[06:41.040 --> 06:48.960]  Whereas Fossil truly is cross-platform, you can compile it in binaries for Linux,
[06:48.960 --> 06:58.480]  BSDs, Mac, Windows, whatever you're running on. We even have Fossil binaries on Android if you want
[06:58.480 --> 07:08.720]  to store a repository on your phone. That's great. So for somebody like me, I mostly use
[07:08.720 --> 07:15.040]  Git a lot. I kind of worked into it from working in the Linux kernel for a few years.
[07:17.920 --> 07:23.040]  Let's say if I wanted to change over to Fossil and I want to get started with it right now,
[07:23.040 --> 07:30.640]  would I find every single thing I have in Git over in Fossil? Can I do pools? Can I do pushes?
[07:33.040 --> 07:34.880]  Do I have a staging area, stuff like that?
[07:35.840 --> 07:42.080]  Yeah. Most everything you have in Git is also available in Fossil. So if you wanted to just
[07:42.080 --> 07:48.800]  play with it, what you would do is just download a pre-compiled binary off the website, put it in
[07:48.800 --> 07:56.000]  your path somewhere, and then do a fast export from one of your existing Git repositories and
[07:56.000 --> 08:04.160]  pipe that into Fossil. And I think the command is import minus minus Git or something like that.
[08:04.160 --> 08:08.960]  And that'll build you a Fossil repository that has everything that your old Git repository has
[08:08.960 --> 08:16.400]  in it. And then once you have that, you type Fossil UI the name of the repository, and that
[08:16.400 --> 08:26.240]  will bring up your preferred web browser, giving you a GitHub-like website that contains your
[08:26.240 --> 08:31.440]  repository. And then you can just explore and play around with it that way. Now Fossil has all the
[08:31.440 --> 08:42.320]  same features that Git has, mostly. It doesn't have a staging area. We consider that an advantage,
[08:42.320 --> 08:48.160]  not a disadvantage. Most people we talk to find the staging area in Git to be very confusing.
[08:49.440 --> 08:55.760]  Certainly newcomers to Git find that very confusing. I know that power users can do some
[08:55.760 --> 09:01.360]  really interesting things with the staging area, but we have all the usual things like a stash,
[09:03.440 --> 09:06.960]  all the usual commands. The commands are slightly different, but all the same things are there,
[09:06.960 --> 09:22.400]  push and pull, clone. What else do you normally? Oh, diff, of course. But Fossil goes beyond Git
[09:22.400 --> 09:26.560]  and gives you a lot of the features that you get with GitHub. Like I mentioned, if you do Fossil
[09:26.560 --> 09:33.440]  space UI, it starts up a little web browser or web server there and also automatically kicks off your
[09:34.960 --> 09:40.800]  preferred web browser and points it at that web server and allows you to surf around the project
[09:41.680 --> 09:48.880]  and look at old versions and look at diffs. It gives you a nice timeline down of all of your changes.
[09:49.280 --> 09:57.280]  You can click on any two check-ins on this timeline and it'll immediately give you a diff
[09:57.280 --> 10:03.840]  between those two check-ins, even if they're in different branches. You can browse backwards
[10:03.840 --> 10:09.360]  in time going back to the beginning. I encourage people who are interested to visit the Fossil
[10:09.920 --> 10:20.400]  website because the Fossil website is really just a running instance of Fossil on the self-hosting
[10:20.400 --> 10:27.600]  Fossil repository. If you click around on there and see what the capabilities are and if you like it,
[10:27.600 --> 10:35.680]  you can clone the self-hosting Fossil repository. When you do that, you don't just get the source
[10:35.680 --> 10:43.600]  code to Fossil, you get the entire Fossil website. That's pretty awesome actually. We have a question
[10:43.600 --> 10:47.360]  actually from the chat room. I want to read this right where it works, whoever he really is or she
[10:47.360 --> 10:52.400]  really is. How are the individual revisions identified? Is it some sort of hash or something
[10:52.400 --> 11:02.480]  like the other DVCS's do? It's the SHA-1 hash, the same as Monotone and Mercurial and Git. It's the
[11:02.480 --> 11:09.520]  SHA-1 hash, exactly. Now any prefix of that hash will do. Any unique prefix will also serve and
[11:09.520 --> 11:15.920]  you can also, if you want to go to a particular check-in, you can put tags on check-ins and
[11:15.920 --> 11:23.040]  tags push and pull. You can also specify that you want to go to a particular branch and just
[11:23.040 --> 11:27.360]  give the branch name and it'll go to the latest version of that branch. Branch names are global
[11:27.360 --> 11:37.680]  in Fossil, unlike in Git. With Git, the branch names are local. Every individual has their own
[11:37.680 --> 11:47.680]  branch names. Your head branch is different from somebody else's, but with Fossil, the branch names
[11:47.680 --> 11:52.160]  are global. It's part of the global namespace. When two people are collaborating, they can
[11:52.880 --> 11:58.000]  use a branch name and say, hey, go to this branch and they know they're both talking about the same
[11:58.000 --> 12:02.480]  thing. Awesome, awesome. And just to clarify something we talked about earlier and touched on
[12:02.480 --> 12:09.200]  and actually the chat room brought up again, Fossil includes the built-in wiki, the built-in
[12:09.200 --> 12:16.960]  bug tracker. Are those also operating in a distributed means as well? Can I be able to update
[12:16.960 --> 12:26.480]  the wiki and how it all merges back together? What happens to conflicts then? With the wiki,
[12:28.160 --> 12:37.040]  right now it's set up to take the last edit wins. The data structure is capable of doing
[12:37.040 --> 12:42.080]  complete merges and it keeps the complete history. If you were on an airplane and you made an edit
[12:42.080 --> 12:47.280]  and then somebody else made an edit and then when you merged, your edit didn't appear because
[12:47.280 --> 12:51.840]  somebody else had overwritten it, then you could resolve that conflict manually.
[12:52.560 --> 12:55.840]  The data structure supports some kind of automatic merging of wiki.
[12:58.000 --> 13:02.400]  Just never have gotten around to implementing that in the user interface because it's never come up.
[13:05.360 --> 13:10.720]  But no, the tickets automatically, they merge things together automatically because every
[13:10.720 --> 13:16.880]  time somebody enters a change to a ticket that's time stamped and when it's computing the state of
[13:16.880 --> 13:23.040]  a trouble ticket or bug report, it just takes all of the changes in timestamp order and so you can
[13:23.040 --> 13:27.600]  enter changes while you're on a plane at 30,000 feet and then when you land push that up and
[13:27.600 --> 13:32.080]  other changes have come in subsequent to that, they will get merged in automatically when it
[13:32.080 --> 13:39.760]  recomputes. So yes, the wiki and the ticketing and the blog features are all distributed the same as
[13:39.760 --> 13:47.680]  the source code is. What was the rest of the question? I'm sorry. I think you pretty much
[13:47.680 --> 13:53.120]  covered that. So I'm also curious though, you mentioned earlier that you're using essentially
[13:53.120 --> 13:57.600]  SQL as a scripting language. Does that mean I can write push hooks and things like that at SQL?
[13:58.720 --> 14:04.400]  You can actually. Well, not directly. We have a
[14:04.400 --> 14:12.800]  a language built in that's sort of a cut down version of Tickle which we call TH1
[14:13.600 --> 14:19.680]  and or you can opt a compile time to have full blown tickle scripting in there and
[14:20.560 --> 14:27.120]  and then with that you can set push and pull hooks which can invoke SQL to query the database
[14:27.120 --> 14:32.800]  all you want to or you can just bring up the SQL database in third party applications and query
[14:33.360 --> 14:37.360]  things that are in the repository that way and do interesting reports like that.
[14:39.680 --> 14:46.400]  That sounds really cool and so is there much of the internal code of fossil written in SQL
[14:46.400 --> 14:53.280]  or is it all written in C? Well the internal code is written in C but it does a lot of SQL calls
[14:53.920 --> 15:01.520]  and so that takes that greatly reduces the size of the code base because all of the heavy lifting
[15:01.520 --> 15:12.160]  is in SQL. Actually the number of lines of source code in fossil and in git is roughly the same
[15:12.160 --> 15:17.680]  last time I checked but when I figured that I'm also including all of the source code that
[15:17.680 --> 15:26.720]  implements SQLite which is there's a copy in the fossil source tree so if you discount the fossil
[15:26.880 --> 15:33.440]  the SQLite source code the fossil source code is much smaller than git because it doesn't have to
[15:33.440 --> 15:41.040]  have all the C code to dig down through the pile of files database that git uses instead it uses
[15:41.680 --> 15:48.000]  a short little five or ten or twenty line queries to extract the information that it needs
[15:48.880 --> 15:55.680]  and this allows it to do a lot of queries that you can't really do in git in the sense that
[15:56.960 --> 16:04.400]  we can query you know show me all check in activity that occurred during the month of
[16:05.120 --> 16:13.360]  February in 2011 and it'll give you a timeline of just that interval whereas with git if you
[16:13.360 --> 16:19.520]  want to see a history of check ins you have to start with a particular branch now and then work
[16:19.520 --> 16:28.080]  your way backwards in time to 2011 because that's the way the it's structured on disk
[16:28.960 --> 16:34.160]  they actually have to walk their their check entry all the way back to wherever you want to look and
[16:34.160 --> 16:39.760]  and figure that way whereas because we're in an SQL database we have indices that will do that for
[16:39.760 --> 16:45.920]  us automatically if I like fossil better than I like git which I'm still not convinced of yet
[16:45.920 --> 16:49.040]  but I'll give you a chance to convince me a little bit more in a few minutes but
[16:49.040 --> 16:56.000]  but is there a way for me to do like what git does with svn where I can have a local git repo
[16:56.000 --> 17:01.280]  that's actually pushing and pulling to svn could I do the same with fossil and git or is it only a
[17:01.280 --> 17:14.240]  one-way import no um uh well with svn uh we there's a guy um uh name uh um he's over in
[17:14.240 --> 17:19.600]  Jerusalem his name is Baruch Bernstein I think who's working on some really cool svn import
[17:19.600 --> 17:27.200]  export capability as we speak it's in a branch but uh uh no it's it's kind of a one-way thing
[17:27.200 --> 17:34.880]  right now you um you can import and export to git but there's not a way to really keep them
[17:35.840 --> 17:42.880]  in sync very well there is a um you know actually there is a an organization that has a git mirror
[17:42.880 --> 17:49.280]  of the SQLite source tree on their site I'll have to send you that link I don't have it committed
[17:49.280 --> 17:54.640]  to memory but they have a git mirror of SQLite and they're doing that somehow so they're probably
[17:54.640 --> 18:02.560]  doing pulls and then pushing them with the fast import fast export protocol of git and moving them
[18:02.560 --> 18:06.720]  straight over and that's a great way to compare the capabilities of the two systems you can go
[18:06.720 --> 18:12.160]  and visit their website and and and look what they're doing with that the SQLite source tree
[18:12.160 --> 18:18.400]  and then visit the the official SQLite source tree which is running fossil and compare the
[18:18.400 --> 18:23.360]  capabilities of the two systems that way that would be an interesting uh an interesting
[18:23.360 --> 18:27.920]  comparison actually and something you brought up a few minutes ago you said you have a copy of
[18:27.920 --> 18:34.000]  SQLite in the fossil source tree does that mean you're maintaining SQLite in the fossil source
[18:34.000 --> 18:39.520]  tree now or are you constantly copying over the released versions back to fossil oh I'm we're
[18:39.600 --> 18:46.960]  constantly copying over the tip of trunk from SQLite into fossil we use fossil as a test platform
[18:46.960 --> 18:54.480]  for SQLite or one of many test platforms so the version of SQLite that's in the version of fossil
[18:54.480 --> 19:04.080]  that's on the official websites now is from two days ago it's a an alpha copy of SQLite 388
[19:04.880 --> 19:11.920]  and uh that's a great way to really stress uh SQLite in a real world application in advance
[19:11.920 --> 19:17.520]  of a release you know how difficult it is to get people to beta test software I mean
[19:20.240 --> 19:24.400]  it's like pulling teeth nobody wants to do it everybody wants an official release
[19:24.400 --> 19:29.040]  how do you get people to test it so that you find the problems before released
[19:29.600 --> 19:34.880]  uh because nobody will and then you push out a release and suddenly oh well you broke my
[19:34.880 --> 19:43.920]  application well how would we know so and so self-hosting uh do you ever have issues of
[19:43.920 --> 19:52.560]  maybe fossil breaking its own repository um every now and then we'll have um we'll we'll you know
[19:53.600 --> 19:58.640]  we'll be using fossil we'll find a performance inefficiency in SQLite that way which is a great
[19:58.640 --> 20:02.960]  way to find them and fix them before they get out in an official release you know you mentioned
[20:02.960 --> 20:11.520]  that a couple years ago uh we did have a repository go corrupt on us it was the official fossil
[20:11.520 --> 20:18.400]  repository the self-hosting repository got a corrupt database and I said oh no what is
[20:18.400 --> 20:27.280]  this about so we went and we looked and um it turns out that um s-tunnel which we're using for
[20:27.280 --> 20:38.320]  to implement uh HTTPS uh was launching the fossil cgi leaving the uh the standard error
[20:38.320 --> 20:43.440]  file descriptor file descriptor number two it wasn't it was leaving it closed and so then um
[20:44.960 --> 20:51.280]  fossil would crank up SQLite and SQLite would then open its database using the first available
[20:51.280 --> 20:57.680]  file descriptor which was now file descriptor number two and then there was some bug in
[20:57.680 --> 21:03.200]  fossil and hit an assert and the assert then wrote the assert error message out on
[21:03.920 --> 21:10.880]  file descriptor number two which was now pointing into the middle of the repository database and so
[21:10.880 --> 21:16.560]  you know we looked at the corrupt database and saw an assert failed message in the middle of
[21:16.560 --> 21:22.160]  this binary and so okay we know the problem now so we used that as an opportunity to it wasn't
[21:22.160 --> 21:26.960]  really a bug in SQLite I guess you could say it was a bug in fossil it shouldn't have hit the assert
[21:26.960 --> 21:34.000]  but still but we used it as an opportunity to improve SQLite SQLite is now careful to never
[21:34.800 --> 21:40.000]  open a database file with a file descriptor less than three
[21:40.880 --> 21:41.520]  um
[21:43.760 --> 21:49.440]  that'd be one way to solve that yeah okay so I'm a heavy git user I've been involved with git since
[21:49.440 --> 21:54.240]  the first month of the project uh been a contributor on one level or another on the mailing list for
[21:54.240 --> 22:00.160]  years and and I still use it for every project I can choose give me give me three reasons
[22:00.880 --> 22:07.040]  that uh I should change from git to fossil well you know if you're happy with git I'm happy for
[22:07.040 --> 22:13.360]  you to keep using it honestly I mean really I wrote SQLite I mean I wrote fossil for SQLite
[22:13.360 --> 22:19.840]  and if you find it useful that's great uh but I mean some people some people like I say there are
[22:19.840 --> 22:27.120]  you run across people who for some reason or another just can't seem to get along if you're
[22:27.120 --> 22:33.440]  part of the fun pun with git it just doesn't work for them I I know that you had to have run across
[22:33.440 --> 22:38.560]  these people randall oh many yes and and what we find is that a lot of these people
[22:40.400 --> 22:45.680]  they work better with fossil but now even if you're really happy with git and I'm glad that it's
[22:45.680 --> 22:52.800]  working well for you I truly am I want you to take some time to look at fossil for a lot of the ideas
[22:52.800 --> 22:58.160]  that are there because of a lot of the ideas that I have in fossil are not in git but I think that
[22:58.160 --> 23:05.280]  git needs to steal them I need fossil is is bsd code git is gpl so you can just import the code
[23:05.280 --> 23:13.600]  directly um steal my code steal my ideas and use them and make git a better product um
[23:15.440 --> 23:19.920]  like what what would you what would you take from fossil in the git all right so fossil has this
[23:20.560 --> 23:29.680]  all command you can say fossil all sync and fossil remembers all of the repositories that you have
[23:30.240 --> 23:36.960]  on your login and and I typically have dozens or hundreds of active projects going on in fossil
[23:36.960 --> 23:42.080]  and say you're on a lap or say I'm working on my my my ubuntu desktop right here which is where
[23:42.080 --> 23:46.880]  I normally work and I'm getting ready to go on a trip and use this laptop that I'm talking to you on
[23:47.760 --> 23:53.600]  over on my desktop I'll take fossil all push and that pushes all the repositories up to various
[23:53.600 --> 24:00.000]  servers I have and then I go to my laptop and say fossil all pull and that pulls them all down
[24:00.000 --> 24:06.400]  automatically all in one command and so then I go I get on the airplane I'm working I'm remote I make
[24:06.400 --> 24:11.200]  some changes I get back to my office fossil all push it pushes them back up to the servers and
[24:11.200 --> 24:15.200]  then I fossil all pull over on my desktop and everything's automatically synchronized I don't
[24:15.200 --> 24:19.360]  have to go through and do this separately for every single repository that I'm working with
[24:20.000 --> 24:27.360]  or at the end of the day I can say fossil all changes and that shows me all of the uncommitted
[24:27.360 --> 24:33.680]  changes that I have on every single project that I'm working on and oh I forgot to do the commit on
[24:33.680 --> 24:37.920]  this thing I was doing over here on this other project and it shows me right away so just the
[24:37.920 --> 24:44.320]  all command is something that you could very quickly and easily add to git that would that
[24:44.320 --> 24:53.280]  would enhance its value as sounds great sounds great yes yes go ahead we're almost out of time
[24:53.280 --> 24:56.080]  so I want to make sure we get we had a couple more really interesting questions I want to make
[24:56.080 --> 25:03.200]  sure we get asked before we uh before we run out of time uh so uh is there is there is there is
[25:03.200 --> 25:07.760]  fossil already pre-built in the standard package servers like for debian and red hat and stuff or
[25:07.760 --> 25:14.000]  can I can I just say apt get fossil and have it or and if not how do we get it I think there is
[25:14.400 --> 25:19.760]  I think they are app they are pre-built in some of them they're older releases look just go to the
[25:19.760 --> 25:27.360]  go to the fossil website and there's pre-built binaries for linux openbsd windows mac and and
[25:27.360 --> 25:32.960]  there's a source tarball there just download it the source tarball and type um you know configure
[25:32.960 --> 25:38.160]  make and it just builds um and and just get the latest and and that's the easiest thing to do it's
[25:38.160 --> 25:43.520]  a it's a standalone binary it's very easy to install you just take this this one executable
[25:43.520 --> 25:49.120]  and you put it on your path somewhere and it's installed it's not like get where you have how
[25:49.120 --> 25:56.080]  many different executables is it now rental like 60 60 I think pretty close to that yeah and uh
[25:56.720 --> 26:01.760]  okay lots of dependencies I mean fossil works in a changer jail all by itself there there are no
[26:01.760 --> 26:08.240]  external dependencies well you know assuming you compile with minus minus um static but uh yeah it
[26:08.240 --> 26:12.560]  it doesn't have any dependencies it it has everything you need so it's easy to install
[26:13.120 --> 26:16.720]  that's wonderful and the other thing also Guillermo keeps whispering whispering in my ear
[26:16.720 --> 26:21.120]  is there anything the equivalent of github as a hosted service if I don't want to actually
[26:21.120 --> 26:27.040]  run it locally as a server yeah well first of all fossil makes it really easy to set up your own
[26:27.040 --> 26:32.480]  little github service if you have a web server already going just it's a two line cgi script
[26:32.480 --> 26:38.880]  but there is a a site out there called chisel ch I'll have to spell it for you I'll have to look
[26:38.880 --> 26:44.400]  at the spelling for you and get it to you chisel.com that provides free hosting of fossil
[26:44.400 --> 26:48.640]  repositories and there's they've got hundreds and hundreds of fossil repositories there
[26:48.640 --> 26:53.520]  that people have put up well we could keep talking for another hour there's so many other things I
[26:53.520 --> 26:57.280]  want to ask you but is there anything we haven't covered you want to make sure our audience is
[26:57.280 --> 27:04.480]  aware of before we have to wrap up uh no I my point about you know the the git users just look
[27:04.480 --> 27:09.600]  at it and get the ideas and steal my code really I've got no vested interest in this I wrote
[27:09.600 --> 27:14.160]  fossil specifically for sqli and if it's never used for anything else other than that it has
[27:14.160 --> 27:18.560]  served its purpose but if people can get some ideas and improve git from it I think that would be great
[27:18.560 --> 27:25.200]  or maybe this is a better solution for you just give it a try sounds wonderful and I have to ask
[27:25.200 --> 27:29.040]  my two standard questions because otherwise my audience will yell at me they'll send me email
[27:29.040 --> 27:32.720]  tomorrow saying why did you ask the two standard questions so what's your favorite scripting
[27:32.720 --> 27:38.080]  language I actually may even know this but go ahead well uh I'll have to say tickle tk because
[27:39.280 --> 27:45.200]  yeah yeah definitely definitely and and it's quite nice that you said tk because I think tk
[27:45.200 --> 27:51.280]  and what was the other thing the thing that uh can can um automatically script something uh run
[27:51.280 --> 28:00.480]  commands and uh uh don lodge expect tickle no expect yes expect and tk put tickle on the map
[28:00.560 --> 28:04.320]  I think without those two things we might not have ever heard of tickle so uh glad that both
[28:04.320 --> 28:10.560]  of those exist and uh your favorite text editor oh I I wrote my own of course
[28:12.720 --> 28:16.560]  it's the emacs bindings emacs bindings is typically what I do yeah
[28:18.240 --> 28:21.360]  dr hip is there anything you haven't written of your own that
[28:21.360 --> 28:29.520]  and forked in your own thing yeah a few things I really um I really need to write a good email
[28:29.520 --> 28:37.040]  server I haven't gotten to that yet and then we'll bring you back eight years from now you'll talk
[28:37.040 --> 28:44.320]  about this new there you have your own copy of linux you got a forked version of that too or
[28:44.320 --> 28:49.680]  I used to do that I used to build my own hardware and and compile my own kernels and and all of
[28:49.680 --> 28:55.120]  that but I've gotten lazy as I've gotten older and and and I I I buy pre-built machines that
[28:55.120 --> 28:59.920]  come with Ubuntu pre-installed and they arrive with the root password taped to the box and I
[28:59.920 --> 29:06.720]  just plug them in and use them so is the is the password uh root by any chance no
[29:10.160 --> 29:14.080]  I'm surprised you don't have your own version of the raspberry pi or the arduino now too
[29:14.880 --> 29:21.680]  well I know I don't have my origin I do use um I do use um uh a beagle board over here
[29:21.680 --> 29:27.840]  for testing sqlite on arm but um no I haven't built my own
[29:30.400 --> 29:33.840]  well it's been a real pleasure having you back on the show we'll bring you back about every
[29:33.840 --> 29:39.040]  eight years and talk about whatever you've done next this has been a pleasure sir thank you for
[29:39.040 --> 29:44.480]  being on the show it's good talking to you very good that was uh Richard Hipp the
[29:44.480 --> 29:51.440]  reinventer of the world uh what do you think there Guillermo well any man that writes his own
[29:51.440 --> 29:59.840]  text editor is you know right up there yeah yeah he's he's a he's a very interesting guy
[30:00.800 --> 30:05.760]  yes yes I'm very happy to have him back um so fossil is interesting I might actually have to
[30:05.760 --> 30:09.120]  check this out I don't uh you know like I said I'm a pretty heavy git user but
[30:09.680 --> 30:14.240]  fossil may have some really interesting things that might work for some of the people who from
[30:14.240 --> 30:19.600]  git sometimes gets a little complex I know that I've gone into um many many organizations as a
[30:19.600 --> 30:26.240]  consultant and if they're using git there's almost always like about one new piece of mail
[30:26.240 --> 30:31.360]  every week in the sort of the developer mailing list that says hey guess what git can do this too
[30:31.360 --> 30:35.760]  and it's always surprising how many things I'm even learning from the exchanges going on there
[30:35.760 --> 30:41.040]  and I'm usually also the source of some of those as well um but it sounds like fossil is is good
[30:41.040 --> 30:48.000]  for what it's designed for and I do also appreciate the uh the built-in wiki and web server and um
[30:48.960 --> 30:53.920]  the uh the bug tracker because I know that integrating those at some of the locations
[30:53.920 --> 30:59.840]  I've been at has just been insane with git uh so I may actually uh see if there's opportunities
[30:59.840 --> 31:05.840]  in the upcoming for for fossil to be deployed um you know I'm hoping that there's a mac port of
[31:05.840 --> 31:10.000]  it automatically or just you know an import install or whatever but if not it sounds like
[31:10.000 --> 31:16.400]  it's just a simple source file or two to compile down and uh we'll see how that all works anything
[31:16.400 --> 31:24.320]  else uh interesting there well um I I'm probably gonna uh give it a you know good old try because
[31:24.400 --> 31:28.880]  I as you mentioned before having a bug tracker and everything else with uh
[31:29.520 --> 31:35.360]  with a git is very very hard to you know actually get it working correctly and then you have to do
[31:35.360 --> 31:40.800]  all these you know special uh special commands like git push for something master branch or
[31:40.800 --> 31:46.480]  whatever and yeah it just gets really silly at times so I'm probably just gonna give it a uh
[31:46.480 --> 31:50.880]  you know the old college try and see if that if that actually uh you know fits for any of my
[31:50.880 --> 31:56.640]  projects yeah sounds great sounds great well great so um we don't have a lot of the upcoming
[31:56.640 --> 32:01.520]  guest list I have sent out I think something like 30 pieces of email try to fill q1 already
[32:01.520 --> 32:05.680]  we do have a couple of people who are almost certainly going to happen and one of them may
[32:05.680 --> 32:13.040]  even be next week um the marpa project which is a fascinating project to me uh marpa is a pearl
[32:13.040 --> 32:20.080]  implementation of the pearl plus c implementation of the early parsley e a r l e y not just early
[32:20.080 --> 32:24.800]  in the morning well that's just this early in the morning right now um the early parser is a
[32:24.800 --> 32:31.040]  fascinating one in that it can deal with ambiguous grammars giving you all possible parsings if it
[32:31.040 --> 32:35.520]  ends up being ambiguous at the end it sort of parses them all the possible limitations or
[32:35.520 --> 32:41.440]  possible parsings at once so my friend jeffrey kegler took this and built a pearl implementation
[32:41.440 --> 32:46.080]  of that but one of the two things that uh or there's two things that early didn't do very well and
[32:46.080 --> 32:50.080]  that was left recursion I believe we're right recursion the left recursion I think it is
[32:50.080 --> 32:55.280]  and empty production rules on the right so uh jeffrey figured out a way using somebody else's
[32:55.280 --> 33:00.960]  paper we're talking about uh the early parser implemented that in pearl so we now have the
[33:00.960 --> 33:07.520]  fastest most comprehensive parser and lecture system available in the world is now written
[33:07.520 --> 33:12.800]  in pearl and I wish other people would copy it so I could use another languages but uh uh
[33:12.880 --> 33:17.120]  jeffrey himself is not coming on but he's his head spokesman for the marpa project is coming on to
[33:17.120 --> 33:21.520]  talk and I believe that's going to be next week uh the docker people have talked have emailed me
[33:21.520 --> 33:26.880]  again and said we will have docker on the show uh so I'm hoping that that's going to be coming up
[33:26.880 --> 33:31.360]  in the next couple weeks as well we're just waiting for uh yeah right we're just waiting for uh uh him
[33:31.360 --> 33:36.080]  to uh to get the date knocked down again a lot of other people on the short list a lot of emails
[33:36.080 --> 33:39.520]  flew out and because it's during holidays and people don't respond very quickly in the holidays
[33:39.520 --> 33:44.240]  but if you go to twitter tv slash floss which is the home page for the show you'll see our big list
[33:44.240 --> 33:50.080]  link from there um and if there's some project that you want on this show and it's not listed
[33:50.080 --> 33:54.640]  there please have the project leader email me merlin at stonehenge.com and I will try to get
[33:54.640 --> 33:59.600]  them on as quick as possible lots of empty slots in this part of the uh the year right now so um
[34:00.240 --> 34:04.800]  we have a live chat with a couple questions from there that's at live.twit.tv at 8 30 a.m pacific
[34:04.800 --> 34:10.240]  time on wednesdays mostly occasionally type tape out of other sequence but mostly it's coming on
[34:10.240 --> 34:13.520]  there and so if you come there you can watch the show while it's being taped live see the behind
[34:13.520 --> 34:18.240]  the scenes stuff and also get your questions brought in to the show uh like just as if you
[34:18.240 --> 34:23.840]  were sitting here on one of our mics very cool uh you can follow me merlin m-e-r-l-y-n on twitter
[34:23.840 --> 34:28.960]  i'm also on google plus as randall l schwarz i post there frequently about things including my
[34:28.960 --> 34:34.400]  new way of eating my low carb high fat ketogenic dieting lots of comments about that um
[34:34.960 --> 34:39.600]  i just want to say new year's eve at the brick house if you didn't see it i think almost all of
[34:39.600 --> 34:45.120]  it was recorded and it's now up on the uh this live stream not the live stream what they call it
[34:45.120 --> 34:52.800]  the uh the live specials feed on the twit network go check that out uh i did a few things i did a
[34:52.800 --> 35:00.400]  nice round table with um renee richie uh the windows guy uh and i think well so many other
[35:00.400 --> 35:04.320]  four of us i can't remember what i don't watch their show sorry sorry guys i don't watch your
[35:04.320 --> 35:09.440]  shows i think you watch mine though so hi there but i'm sorry i can't remember his name um that
[35:09.440 --> 35:14.480]  was like a good 30 minute discussion we got into things like um like the recent security breaches
[35:14.480 --> 35:18.560]  and edward snowed and a bunch of other really good stuff i'm kind of hoping we can do that probably
[35:18.560 --> 35:21.760]  you know every six months or maybe every three months or something i'd be really oh steve
[35:21.760 --> 35:26.000]  gibson right that's right sorry thanks thanks chat room yes steve gibson sorry i completely
[35:26.000 --> 35:31.360]  i completely forget my arch nemesis occasionally so um it's uh paul thoreau and renee richie there
[35:31.360 --> 35:34.640]  we go that was the other three people besides me uh hopefully we get that little round table
[35:34.640 --> 35:40.080]  going again uh and uh erin and nukem and i did some stuff on uh gadgets there joeyno uh that
[35:40.080 --> 35:46.720]  he has and raspberry pie um i also trolled the uh the audience we didn't have anybody for the
[35:46.720 --> 35:53.760]  hour that kazakhstan had their um had their uh their uh new year's eve and so i got them to play
[35:53.760 --> 36:01.520]  the uh borat uh kazakhstan anthem for that hour so that was great yes so we got that we got that
[36:01.520 --> 36:05.600]  to happen that was that was my troll for the day and i actually popped my head in a few other things
[36:05.600 --> 36:11.280]  as well so it was it was a lot of fun i managed to make it 14 hours uh leo did a full 24 hours
[36:11.280 --> 36:18.800]  leo got his head shaven he got a tattoo of a twit logo on his on his tiny there uh it was just great
[36:18.800 --> 36:22.480]  and most of that like i said is in the stream already so you can watch that uh in the uh in
[36:22.480 --> 36:27.760]  the playback uh i'm going to be in cuba in a few weeks uh so i won't be hosting the show i've got
[36:27.760 --> 36:32.720]  a suitable guest host as i often do when i have to go away um and i'm also for those of you in
[36:32.720 --> 36:38.640]  the la area i will be at scale in february at the hilton hotel i think it's february 22nd through
[36:38.640 --> 36:45.600]  24th or something like that um so it'll be great um oh wait no jeff charvis uh not uh not the other
[36:45.600 --> 36:49.680]  guys jeff charvis was it not paul farrell right yes that's right jeff charvis uh who actually got
[36:49.680 --> 36:55.600]  his head or in his beard shaven uh there was various goals for raising money for the unicef
[36:55.600 --> 37:00.480]  and uh and as the goals kept getting hit weirder things kept happening during the day so if he
[37:00.480 --> 37:04.000]  i can say if you haven't checked that out go check that out a lot of fun i hope i can do it next year
[37:04.000 --> 37:07.040]  um that's all i want to plug right now anything you want to plug your germo
[37:07.680 --> 37:14.560]  uh well i guess uh people can find me and um on twitter that's uh at g a g a m a r a l
[37:14.640 --> 37:19.040]  never write my own name but at least not spell it and uh i'm gonna restart my
[37:19.040 --> 37:25.200]  youtube channel uh this week now that i'm out of college that means extra time so uh expect
[37:25.200 --> 37:31.840]  podcasts and expect uh some uh videos out there soon that's pretty much it i didn't do anything
[37:31.840 --> 37:38.480]  fancy in new years besides you know eat and drink or anything and you'll be at scale right
[37:38.480 --> 37:45.040]  don't usually yeah yeah i'll be at scale i i was supposed to uh submit a talk but i never actually
[37:45.040 --> 37:50.560]  got i got to it but i'll be there you know just mingling around and saying hi to people so i'll
[37:50.560 --> 37:54.720]  be around yeah well you know we do have an inside connection to there so maybe you can still submit
[37:54.720 --> 38:01.920]  the talk late and still get it on oh maybe i'll see we'll get gareth back on and he'll just
[38:01.920 --> 38:06.080]  automatically approve your talk whatever it is so uh but a great show unfortunately we're out of
[38:06.080 --> 38:17.200]  time so we'll see you all again next week on floss weekly