7 ms·

Most of the stuff in the article I already know but it's still nice to have a document that you can point folks to who aren't familiar with these things. I thin

• bryanrasmussen 6y ago
  if the same guy made the last OS and the last VCS, that would be some achievement.
  • sammorrowdrums 6y ago
    If anything I'm not sure Linus is held in enough esteem outside of tech circles. I wish all the time that more of the people I know outside of software could benefit from something like Git. It's unbelievable how powerful a tool it is, and when I watch people doing awkward and error prone simultaneous-editing and remote synching etc, it just doesn't compare. But then git is too abstract for many. Your files are a representation of a state of combined changes, the files themselves are not the owners of their content. I even had to have a huge debate with a developer once about how storing a git repo in Dropbox folder so they could have same exact state across two machines was a terrible idea, and already solved with Git itself... And then how few people also know how many places the Linux kernel or derivatives live, or even that many things they use are running something based on Linux. What an incomprehensibly huge achievement on both counts! [Edit] typo
    • globular-toast 6y ago
      Git is at a vastly different level of abstraction than most of the population are used to (or capable of). When Linus made git, concepts like references, pointers, indirection, graphs, hashing, indexing etc. were already as obvious to him as the sky being above the ground. Even some programmers struggle to operate at this level. It does hurt to see non-technical people inventing their own terrible VCSs, though ("Copy of Important Document 2020-11-21 (2) (Updated PB).docx")
      • bryanrasmussen 6y ago
        >It does hurt to see non-technical people inventing their own terrible VCSs, though ("Copy of Important Document 2020-11-21 (2) (Updated PB).docx") I don't think that is necessarily due to not be able to use git (as in not competent to use it) but not able to use it due to restrictions in their workplace or even just unfamiliarity with the possibility of such a tool existing.
        • simias 6y ago
          Well that and out of the box git isn't very user friendly, even for developers who are used to dealing with command line tools. To this day in my experience most devs have a relatively shallow understanding of git and often need assistance for anything more complex than commit and push. I can't count the number of times I've had to assist a colleague for what ended up being a relatively simple merge. I think you'd need an extremely good GUI if you wanted to market git to the masses.
          • sammorrowdrums 6y ago
            Hahaha, watch as colleagues stare blankly when you ask them to look at the reflog after botching a rebase and force pushing... and loads of other tools like bisect and blame heavily under-utilised, custom git hooks... The list of under-utilised git commands is long, and while perhaps a sign of a poor UX, if you use the features it really is rare that you are surprised or that you cannot return a repo to a good state, regardless of what you do.
            • simias 6y ago
              I do think that git's UI is a good case study on how not to design a command line interface. It's improved over the years but I remember that a decade ago the contrast was stark if you compared, say, mercurial to git. Git always felt more like you were exposed a raw low level API on the command line with a few shell macros on top to make it a bit more palatable which is effectively what it was for a long time. I suppose it fits well within the unix philosophy of clunky but very flexible and not very opinionated tools.
    • nix23 6y ago
      >What an incomprehensibly huge achievement on both counts! He is an amazing dev, don't get me wrong. BUT he had lots of luck starting from not choosing the name Freax, choosing the same license as his compiler (GPL), and a professor that did no understood free-software (Tannenbaum and his minix), the legal battle of the BSD's...and maybe a too expensive and ~slow solaris, and a really good but proprietary VCS (Bitkeeper) as a idea-blueprint for git.
      • sammorrowdrums 6y ago
        True, although when you compare for example to people behind large brands with frequently huge acclaim, and then glimpse inside their (frequently) empty shell that is a marketing PR machine where all the real innovation, manufacturer and logistics is all bought, I think it's ok to give acclaim to somebody lucky, with prior art and inspiration from people who's shoulders they stand on, simply for the outcome that emerged.
        • deleted 6y ago
          [deleted]
      • quesera 6y ago
        You're not wrong. But, tens of thousands of other people had all of those same lucky things. Linus has claimed to have been unaware of the existence of BSD, so perhaps he had a bit of fortunate ignorance as well. (FWIW, neither Linux nor git are my preferred options, but I still think Linus has spawned great things. :)
        • nix23 6y ago
          > You're not wrong. https://news.ycombinator.com/item?id=8641073 https://news.ycombinator.com/item?id=8641073 https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RR... >But, tens of thousands of other people had all of those same lucky things. Yes AND? >but I still think Linus has spawned great things. I did not say anything else.
  • b0rsuk 6y ago
    It's really a shame so few people recognize him. You don't count unless you sit on a large pile of money.
    • WJW 6y ago
      While I like Linus as much as anyone, he had a large impact in a small field. Even then both linux and git are community projects first and foremost, Torvalds is just the BDFL but the projects would continue very well without him. Almost nobody can name influential luminaries outside their field. Who outside the field of fiber communications has ever heard of Kao and Hockham? How many HN commenters could tell what Reynold Johnsons' team invented without having to google it? Those are just some examples from software-adjacent fields that we all use every day. Imagine how many fields there are out there that you'd never think of. In any case, what you mention as "counting" is a very narrow approach. If you mean "has to appear before congress for questioning" then having a lot of money helps. There are hundreds if not thousands people doing impactful work that you will never read about. There is not enough time in the day to keep up with all the work done in modern society but that does not make their work "count" any less.
  • nix23 6y ago
    >last OS and the last VCS I don't think that's true, he made a kernel NOT an OS, and the last VCS...we will see. There is zero proof that any software survives forever...well ok, COBOL maybe.
• globular-toast 6y ago
  Git is a funny one. I do believe the data model at the heart of git has a good change at being the last VCS data model. Apart from little details like the choice of hash function, there is little wrong with it. Git's success despite its perception of being difficult to learn and use is a testament to that. But we are long overdue a better porcelain for git. The standard CLI it comes with is just not good. Its level of abstraction is too high in a few places where it tries to make things seem not-too-dissimilar to "old world" VCS systems. And its too low in other places, for example tags are a great, flexible tool but the vast majority of users don't use them or need them, they just need to mark releases. The fact I need to write something like "git tag --annotate --sign" instead of just "git release" is a silly. I think a concerted effort to take what git is and what we do with (and forget old VCS systems) and reinvent the interface will create the closest to a successor to git. The only porcelain that is vaguely on the right track here is magit.
  • pabs3 6y ago
    There are a few things wrong with the git data model, one is lack of chunking, which makes versioning large files space inefficient. Some backup systems like borg and restic have fixed that issue in the git data model, but suffer from lack of chunking in directory listings, I assume git would have that issue too.
    • rakoo 6y ago
      Actually if you want to give credits were it is due, you should mention bup (https://github.com/bup/bup https://github.com/bup/bup) that arguably came up with the idea of content-defined-chunking for backups, and even stores it in git.
      • stevesimmons 6y ago
        Some nice references here are: * Using Rabin fingerprinting to break files into chunks: background here on SO, including link to Rabin's 1981 paper: https://cs.stackexchange.com/questions/82150/how-does-rabin-fingerprint-finds-breakpoints-chunk-boundary https://cs.stackexchange.com/questions/82150/how-does-rabin-... * Andrew Tridgell's PhD thesis on the rsync algorithm (1999): https://rsync.samba.org/~tridge/phd_thesis.pdf https://rsync.samba.org/~tridge/phd_thesis.pdf * Graham Keeling's Masters thesis on content-defined chunking used in his Burp backup program (2014): https://burp.grke.org/images/burp2-report.pdf https://burp.grke.org/images/burp2-report.pdf. Burp dates back to 2011 at least. Section 6 of the thesis has an interesting contemporary comparison of rsync, bup, burp, bacula, rdiff-backup and a few others. * Bup's design docs: https://raw.githubusercontent.com/bup/bup/master/DESIGN https://raw.githubusercontent.com/bup/bup/master/DESIGN * A Linux Weekly News review of Bup from 2010, with comments on strengths and weaknesses of the other approaches then available: https://lwn.net/Articles/380983/ https://lwn.net/Articles/380983/ Digging these out was a trip down memory lane. I tried most of them at various times, and now use borg-backup (https://borgbackup.readthedocs.io https://borgbackup.readthedocs.io).
• Lichtso 6y ago
  I think VCS is far from solved, it hasn't even started yet. So far we only have distributed VCS for sequences (mostly text / source code) and sometimes things which can be serialized unambiguously like trees and tables. But we don't have a general solution to distributed VCS. We currently can't use distributed VCS for: - DAGs - Arbitrary graphs (Topology) - 3D models (Geometry) - Mutli-dimensional sequences: Images, Videos, etc. - most domain specific problems / formats - ... almost everything else
  • tomc1985 6y ago
    Store all those things as text and you can stick them in git
    • strombofulous 6y ago
      You won't really get a meaningful diff from, for example, an image or video
    • marcosdumay 6y ago
      People do not want to represent most of them as text. Some of them need high amounts of compression to be viable. Others don't have any concept of locality that one can map into a single dimension. For some, locality of changes is even an anti-feature.
      • npsimons 6y ago
        > People do not want to represent most of them as text. "People" don't care what things are stored as. You could make GUI tools save to GraphViz's text based format (or heck PlantUML[0]) for graphs at least and it would work just fine. For assets which have to be truly binary, Perforce offers versioning of those. I know it's not open source and costs money, but if it's really a need, it's worth it. [0] - https://plantuml.com/ https://plantuml.com/
    • Lichtso 6y ago
      You can do that, but you will only get some of the features (a distributed backup system with an undo function). The most important one IMO is merging and that does not work on arbitrary formats serialized to text. E.g. let two 3D artists fork a blender 3D file in GIT, both do changes and commit them. Until here everything seems fine, now they want to merge their changes ... and suddenly everything falls apart. Edit: To clarify, if you don't need merging than you also don't need distributed VCS and centralized VCS will be sufficient. That is why I explicitly talked about distributed VCS.
• bhaak 6y ago
  Git has a really simple view of changes. That is, none. It just saves blobs. It doesn't really know what you commit. For example it doesn't know if commits are independent of each other. Darcs was also from the 2000s but unfortunately not fast enough to compete with git. If you want to see what a post-git VCS might look like, read this introduction to pijul, a VCS that is based on patches and not on blobs like git: https://jneem.github.io/merging/ https://jneem.github.io/merging/
  • l0b0 6y ago
    I suspect the theory behind Pijul is where VCS development goes from being a practice (build a pragmatic solution to everyday problems and iterate) to having a solid theoretical foundation. It'll be exciting to see how it evolves from here.
• redis_mlc 6y ago
  > characterized by the success story of git replacing everything else. For most people, svn was the better (easier) choice of tool, shown in how they only use the basic features in github to manage each repo in a centralized manner.