Open-source paved the way for today’s remote software development processes
increment.com
increment.com
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?
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
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.
I think you'd need an extremely good GUI if you wanted to market git to the masses.
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.
To be honest, for most purposes, shared docs do revision control well enough for the purposes of text docs and presentations. I've used GitHub for some larger collaborations, but it's really overkill for most day-to-day docs.
Every time I do something more than that I end up needing to google error messages, and usually end up copying my changes to a temp directory, doing a hard reset, and starting over.
pull should’ve been clone.
commit should’ve been snap.
push should’ve been commit.
This way, clone (instead of pull) will make a local copy on your computer.
This is your local working copy. When you are ready to save, you can “snap” shot it, and leave a little message. And you can do as much of this as you want.
Then when you’re ready to merge it back to the primary database, then you can “commit” it.
The whole concept of pull/commit/push seems nonsensical to me. As a layman, I can’t understand the importance of pull vs. push in this context. And this makes it difficult to explain to someone non-technical.
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.
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. :)
https://news.ycombinator.com/item?id=8641073
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.
Linus is also lucky that he had decent nutrition in his childhood, and that Finland was not at war with Russia during his university years. He had the luck to be born to parents that were able to prioritize education over subsistence. So yes, he was lucky.
But in your previous comment, you also call Linus's choices "luck". That doesn't read fairly to me.
He had the luck to make good choices? Maybe in retrospect, but you must acknowledge that there's much more than luck involved.
Of the tens of thousands of people with enough "luck" to arrive at roughly the same place in 1991 -- by which I mean smart, well-fed, decent academic/life schedule with adequate free time, few or manageable commitments like spouses/dependent children or parents, broad and deep exposure to Unix, access to USENET and the Internet -- Linus remains exceptional.
My closing parenthetical was not a counterpoint to your message. It was to frame my perspective: I don't worship, but I do respect.
There where not "tens of thousands" peoples who made a ~unix kernel licensed with the GPL.
>Linus is also lucky that he had decent nutrition in his childhood
Yeah let's stop here it getting stupid.
Among the tens of thousands who were in the right place, single-digit dozens made the attempt, and only Linus succeeded in such a visible way. If you want to argue that he was merely the lucky one among dozens, then you still have a lot of extraordinary evidence to present, but you might have an interesting story to tell.
Your original comment reads like a dismissal because Linus drew inspiration from the world he lived in, and was just "lucky".
The point is that he did the work, he attracted the community, he managed the project. None of that was luck. And none of that is highly correlated with being an "amazing dev". Of course he stood on the shoulders of giants. Of course he learned from (and drew from) the environment around him. Of course Linux would be a forgotten academic project without the GNU userland (and license, maybe). Etc etc.
We all lived in that soup. Linus did the hard work and made something from it. I thought your comment was highly uncharitable in its disregard for all of things that made Linux successful.
> Yeah let's stop here it getting stupid.
On this, we can agree.
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.
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.
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.
* 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-...
* Andrew Tridgell's PhD thesis on the rsync algorithm (1999): 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. 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
* 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/
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).
Truer words have never been spoken!!
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 elseSome 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.
"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/
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.
However, I think the "fault" lies neither in the VCS nor file format. It simply shows that merging requires domain knowledge and that future VCS will need to cooperate with file formats to achieve that.
It would take a pretty monumental effort to build, but I think a huge step forward could be made with a VCS that has knowledge of code structure, and the relationships between source files.
Large scale refactoring is such a fragile affair with git. Conceptually though, it should be possible to cleanly and concisely represent such operations as renaming functions, reordering arguments, widening type parameters, etc.
Stability of the programming language in question is of course highly desirable, if you were to build such a system. The pace of change of Go would be much more conducive to success than that of JavaScript (or TypeScript).
Are you joking? Because you can represent these as Lisp sexps in plain text.
> - Arbitrary graphs (Topology)
GraphViz (https://graphviz.org/) and PlantUML (https://plantuml.com/).
> - 3D models (Geometry)
My experience here is much more limited, but I'm certain there are text based versions of 3D model formats. The names of these formats just doesn't come immediately to mind, but having worked with antenna models, we'd stay with text representations whenever possible, and it worked just fine.
> - Mutli-dimensional sequences: Images, Videos, etc.
> - most domain specific problems / formats
> - ... almost everything else
This is where things get tricky, and again, I don't have experience in these domains. I can say, I've worked on projects where binary assets were tracked in Perforce. Not sure how efficient it was with diffs, but I know it worked, and probably better than git, which yes, doesn't know anything about binaries.
Note: I am not a fan of Perforce, for other reasons, but I am not blind to the fact that it handles binary versioning better than git.
Note2: I will also add, SVGs are just one image format that can be stored as text. NetPBM (https://en.wikipedia.org/wiki/Netpbm) has also been around forever.
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:
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.
Personally, I don't much care for using things like Trello or GitHub for non-software tasks and generally resist doiung so.
But it could be like git, recoverable.
https://en.wikipedia.org/wiki/XMODEM#:~:text=XMODEM%20is%20a....
Even in the office they used terminals connected to mainframes over serial cables.
I credit this for sparking some interest in programming, as I was able to use these to play around with small FORTRAN and BASIC programs.
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.
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.
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.
I agree that 'lower tier' providers may be even cheaper, but they still count as cloud computing, so I think my point stands. As a slight off-topic, I've found that the cheaper providers generally offer an inferior product. You can expect to encounter poorly considered features, broken features, or expected features missing entirely.
IMHO getting into the cloud without using any cloud-native features isn't money well spent. you'll be much better off avoiding the VMs as much as possible - which is where your point about on-demand pricing makes sense for elastic workloads.
Running your own servers properly is a considerable undertaking. If you're just playing around, that's a different matter. Power-management equipment alone would cost more than what you'd spend on AWS. Even if you somehow got all your hardware for free, the time spent setting up would cost far more than AWS are asking.
> $74 isn't a lot; but then, it's still much more expensive than something like a raspberry pi 4 with a USB SSD
Serious cloud computing instances are backed by server-grade hardware, with automatic recovery systems to help cope with hardware failures if they do occur, in a dedicated facility with measures in place for everything from burglary to fire to power outages to network outages. The major cloud providers can offer all this for a few pounds/dollars a month due to economies of scale.
If it's your intent to just play around, a Raspberry Pi might be a fine choice, but a Raspberry Pi plugged into the wall isn't close to a proper server setup.
> the network isn't that relevant when going this low, since you won't be serving anything substantial out of it
Firstly, that's not necessarily true. If you're running something like an SFTP/FTPS server, you might make good use of the connection speed, despite only using a lightweight VM. Even if you're hosting a proper Web 2.0 site, an efficient architecture goes a long way. HackerNews and StackOverflow use famously few servers, for instance.
Secondly, a lot of ISPs are hostile to web hosting from home connections, so a Raspberry Pi might not be an option even if you're only hosting a 'toy' site.
Thirdly, it's not just performance, it's also reliability. AWS invest in redundancy and robustness. A home/small office connection isn't in the same league.
> getting into the cloud without using any cloud-native features isn't money well spent
If you can get a serious virtual/physical server for a better price elsewhere, that might be worth considering, sure. GitHub does this - they're hosted with a company called Carpathia, rather than with one of the major cloud providers. [0] The 'cloudy features' of a platform like EC2 are powerful though, features like automatic recovery from hardware failure, the ability to easily change the hardware spec of your instance with just a reboot of downtime, the ability to easily transform your virtual HDD into a virtual SSD, etc.
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.
And forcing someone to put a concept down in words is invaluable. It's like a digital rubber duck.