11 ms·
Open-source paved the way for today’s remote software development processes
- maxekman 6y agoI have never seen the Increment magazine, is it worth ordering some paper copies of old issues? How do you appreciate the quality of the articles?
- est31 6y agoMost 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 think one interesting point from the article is that CVS is from the 80s, SVN from the 90s, and git from the 2000s. The past decade had no major VCS show up, but rather was characterized by the success story of git replacing everything else. Gcc's and LLVM's migration to git isn't that far in the past at all. So I wonder, as the last decade lacked a major leap in VCS technology, can VCS be considered a solved problem now? I recently read on hn a comment saying that Linux will be the last OS. Is git the last VCS?
- bryanrasmussen 6y agoif the same guy made the last OS and the last VCS, that would be some achievement.
- sammorrowdrums 6y agoIf 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 agoGit 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 agoWell 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 agoHahaha, 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.
- b0rsuk 6y agoIt's really a shame so few people recognize him. You don't count unless you sit on a large pile of money.
- WJW 6y agoWhile 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 agoGit 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 agoThere 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 agoActually 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 agoSome 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 agoI 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 agoStore all those things as text and you can stick them in git
- strombofulous 6y agoYou won't really get a meaningful diff from, for example, an image or video
- marcosdumay 6y agoPeople 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 agoYou 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 agoGit 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 agoI 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.
- tannhaeuser 6y agoF/OSS may have also paved the way for today's lock-in into "the cloud."
- MaxBarraclough 6y agoThis is a common sentiment but I think it glosses over the upside of cloud computing. Yes, the managed services generally lock you in, but cloud computing has given us cheap and robust VMs in world-class infrastructure. If you want to keep your project portable, you only need to avoid the vendor-specific managed services. As the FSF put it, there is no cloud, just other people's computers. Using someone else's computers doesn't have to mean lock-in.
- ls65536 6y agoOne way in which I've often thought about it is that whenever you build something on a foundation over which you have no (or little) say or control, then at least work to make it possible to be able to substitute that foundation for an alternative in the future. Or at the very least, be aware of the risks that come with such an arrangement and mitigate them appropriately. Even beyond software or cloud-based tech, this can be useful to think about and apply even more broadly in life, for example when consideing any variety of real or virtual tools, platforms or services that you may depend on.
- MaxBarraclough 6y agoThat all sounds sensible. As you say, deliberately committing to lock-in isn't necessarily a mistake. The Amazon Aurora managed database solution looks very impressive, for instance, and I imagine it could make good sense to use it despite the lock-in. In that instance, the service is compatible with MySQL/Postgres, but I imagine it could still be a considerable challenge to move away from it (moving from one high-availability Postgres-based database solution to another). The upsides may outweigh the downsides of lock-in, but the upside needs to be substantial.
- 6y ago
- cheph 6y agoTo me this title feels a bit like ... paving the way paved the way to paving the way... Open source software paved the way to many things, not sure why we subselect this one thing. It is like saying modern agriculture paved the way to the prescription opioid epidemic.. I mean it did, but why do we care about connecting these two things? We can also say romans paving the way paved the way to open source software paving the way to remote software development paving the way to a covid-19 vaccine to pave the way back on location development. Why would we though.
- pjmlp 6y agoI have been doing remote software development, with commercial software, since around 2000, and back in the 90's if you could afford modem calls tarifs, with stuff like Novel Netware over WAN.
- MrBuddyCasino 6y agoI wonder if people worked from home using terminals connected to mainframes back in the 70s and 80s.
- pjmlp 6y agoIt wasn't as common as today, and it were isolated cases, but it was certainly happening. https://en.wikipedia.org/wiki/XMODEM#:~:text=XMODEM%20is%20a%20simple%20file,and%20called%20the%20result%20XMODEM https://en.wikipedia.org/wiki/XMODEM#:~:text=XMODEM%20is%20a....
- bregma 6y agoYes, except management did not approve because they couldn't check to make sure you were wearing your required white shirt, dark tie, and work-appropriate slacks. Even in the office they used terminals connected to mainframes over serial cables.
- teekert 6y agoWebcams would have been so handy back then. I bet some hacker managed to sent a picture of him in correct attire every now and then. Proving the whole thing is BS of course.
- dietrichepp 6y agoMy dad mentioned that he did his graduate work from home in the early 1980s (maybe late 70s?) using a 32-column terminal that he made from an Intel 8008 and a TV. He apparently bypassed the color demodulator in the TV to get a crisper B&W image. He dialed in to the University computer with a 300 baud modem.
- 6y ago
- teekert 6y agoI have hard time explaining exactly how our async way of communicating makes the whole wfh situation so much more pleasant (we work via GitHub) to my non-developer colleagues. I feel they could benefit a lot and their constant complaining about telco filled days could be much reduced. But how could they do this when they email office docs around (i.e. for grant applications or IP) and fill out bespoke systems for their project management steps...?
- itomato 6y agoInitiatives, Epics, Issues, Tasks and Subtasks.
- ghaff 6y agoShared docs (e.g. GSuite or Office365) help. I rarely mail around documents. And even to the degree that you also have calls, a shared Agenda is a good start. Personally, I don't much care for using things like Trello or GitHub for non-software tasks and generally resist doiung so.
- teekert 6y agoI push for those, but some people lost some data because at point OneDrive just decided it would incorporate someone's desktop folder (seriously, why?!). And occasionally it errors with cryptic error messages like "can't open document" no further info. People fear it and I understand them actually. It must really be flawless, mess up 3 hours of work for someone and it will take years before you can try and pry them away from email-only again.
- ghaff 6y agoI actually don't have any real experience with Microsoft's cloud products, just Google's. They're pretty flawless IMO and have just the right set of features for me in general. Certainly I've lost far more work over the years with desktop products crashing or just accidentally deleting the wrong file.
- marcosdumay 6y ago
- BMSmnqXAE4yfe1 6y agoNah, I've been a cheap overseas help for years. We paid for this with our $2-12/hour salaries, not the spoiled open source brats with trust funds.
- msoad 6y agoI have a teammate that loves to send messages like "I have a question about xyz, hey @my-handle can you jump on a Zoom call to discuss this?". I freaking hate this! Nobody in the open source can do this!
- thrower123 6y agoI have setup an auto-response for these kinds of requests which is "Describe what it is that you want in an email"
- npsimons 6y agoEmail is perhaps one of the most useful tools, ever, yet so many people just don't use it. Like, they won't even respond, I just don't get it. And forcing someone to put a concept down in words is invaluable. It's like a digital rubber duck.
- schoolornot 6y agoI see this quite a bit. I also see a lot of people waiting around until the next Zoom call to present issues that should and could have been dealt with over Slack/Email when they first arose. I'm not sure if it's a matter of people wanting brownie points for speaking or if there is an intention to avoid owning such issues by blurting about them in a time constrained meeting where there isn't an opportunity to discuss details, impact, and next steps.
- npsimons 6y agoBy some peoples' standards, I'm a young un', but I can distinctly recall being 100% remote in 2000, working on adding real-time to the Linux kernel. We were using BitKeeper, and had no central office. We'd meet at each others' homes as needed, but otherwise just worked from our home offices (it was at this point I moved out of a house I rented with two other guys still in college (I had just graduated), and got my own 2 bedroom apartment to have a home office). Now that I've been reminded of how much more productive and happy I can be working from home, I'm working on making 100% work from home a reality.