13 ms·

Linux in part won because the Regents were getting sued at a critical time. Without linux we would run BSD and it would be fine. Git is good in some ways, terr

by wbl 7y ago

Linux in part won because the Regents were getting sued at a critical time. Without linux we would run BSD and it would be fine. Git is good in some ways, terrible in others. I've used it for years and still don't feel really comfortable with it, but I've never had something as multiheaded as the linux repo.

qorrect 7y ago
> but I've never had something as multiheaded as the linux repo. Git is overkill for so many projects, I hate being forced into for everything.
- growlist 7y ago
  Definitely. I find SVN so much easier. But we must all use Git because cargo cultism is cool, or something.
  - deleted 7y ago
    [deleted]
  - majewsky 7y ago
    We use Git because GitHub happened to be the first non-shitty code repository website.
    - growlist 7y ago
      I'm talking about internal repos.
      - soraminazuki 7y ago
        I know people like to complain about git's interface, but is it so lacking to the point that it justifies the time spent on learning multiple version control systems?
        compiler-guy 7y ago
        Yes.
        catalogia 7y ago
        Go easy on yourself and stop forcing yourself to use the CLI tools if you dislike them so much. For every editor and IDE under the sun, there exists extensions for these version control systems that provide you with a nicer interface than the CLI interface of any VCS. For years probably 99% of my interactions with git, or any other VCS, is through editor extensions like magit or fugitive.
  - adrianN 7y ago
    How do you work on more than one thing at once with svn without manually managing patch files?
    - taco_emoji 7y ago
      Branches.
      - tasuki 7y ago
        Branches in SVN are such a pain! If I recall correctly, creating a branch in SVN consists of making a full copy of everything (remotely, usually). In Git, creating a new branch consists of creating a new pointer to an existing commit.
        _ph_ 7y ago
        Yes, branches look like full copies, but they are sparse copies. So only any changed data on the branch gets actually stored in the repository.
        taco_emoji 7y ago
        That's basically all it is in SVN as well... And of course it's remote, every action in SVN is remote since it's centralized (except for shelving).
- holtalanm 7y ago
  care to elaborate? I fail to see how git would be considered 'overkill' for a project.
  - bildung 7y ago
    Other version control software has way simpler syntax and workflow. Subversion for example. The complexity of git makes total sense if you indeed have a complex, multi-HEADed project like the Linux kernel. But most software isn't Linux.
    - Scarblac 7y ago
      Subversion needs a server, for one. For a single user and a single file, Git is already less overhead.
      - taco_emoji 7y ago
        It doesn't, actually, you can host a repo on the filesystem without any sort of server process. http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.create.html http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.create...
    - vultour 7y ago
      You literally need to know two commands to work with git in a simple project; add and commit. I don’t see how that is any complicated?
      - jcranmer 7y ago
        By that argument, you literally need to know a single command to work with Mercurial (hg commit) or SVN (svn commit), or hell, even CVS (cvs commit).
        drunken-serval 7y ago
        git commit -a then.
- jbob2000 7y ago
  How is git overkill? Perhaps you're conflating Git and Github? Or perhaps you're confusing git best practices or methodologies with git functionality? Git costs nothing to use, you add it to a project and then it sits there until you do something with it. If you want to use it as a "super save" function, it'll do that. If you want to use it to track every change to every line of code you've written, it'll do that too.
- kungito 7y ago
  Git is the simplest, low friction, low cost, low everything above file storage. How can there be something simpler atop an existing file system (I know there are some versioning file systems but I've never used them). I use git for practically anything I do. I to git init and I have my project versioned and I can but don't have to even add messages to each of my versions. You don't have to use anything else if you don't want to but you have so many options if you need them. You don't have to even use git on line if you don't want but if you do there are multiple (even open source) git repositories with free private repos. What is there not to like?
  - bildung 7y ago
    > I know there are some versioning file systems but I've never used them But those other systems were the whole point of the post you replied to ;)
  - jcranmer 7y ago
    > How can there be something simpler atop an existing file system Mercurial? Similar DVCS concepts, but you no longer have to worry about garbage collection or staging areas...
    - kungito 7y ago
      What garbage collection? Isn't staging area actually a feature? I've never used anything else since when I started needing something like 5 years ago git was already a recommended choice, but I also never felt like I needed anything else.
      - jcranmer 7y ago
        If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages. And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.
- leshow 7y ago
  It has such minimal overhead I don't know how you could say that.
- bcrosby95 7y ago
  Sure. But you know what is more complex than git? Git + <anything else>. If you use git at all, you may as well use it for everything. If you have control over which version control system to use, there's no good reason to actively use multiple ones at the same time.
- andyjohnson0 7y ago
  I agree. I have reasonable familiarity with git but I find that traditional SVN-type systems often (not always) have a lower cognitive overhead. If I ever need to manage the codebase for a huge, multi-level project involving large numbers of geographically dispersed developers then I'm sure I'd use git. For simpler projects, not so likely.
- ivalm 7y ago
  I use git at work where branching matters, I also use git for home projects where git add/commit/push/pull are the only commands I use. Git is efficient at both scales, it is opposite of overkill.
  - baot 7y ago
    Furthermore, if you're forced to use it, it's because you need it to interact with others' versions of the repo, in which case branching matters.
naringas 7y ago
what if google built androd on top of BSD?
- pjmlp 7y ago
  Almost there. The Linux kernel is the only GPL piece still standing.
- liveoneggs 7y ago
  wouldn't change a thing. Apple built on freebsd; Android userland and libc is all BSD
  - rhinoceraptor 7y ago
    Slight clarification, Darwin is a mish-mash of CMU's Mach microkernel, some 4.3 BSD, some BSD userland, some GNU userland (although that seems to be going away), and then NeXT/Apple stuff on top of that.
LoSboccacc 7y ago
imho git is not a version control system but a version control tool. when we started using git trough a system mediating all the functionality trough a goal/workflow oriented approach our whole experience radically changed. both fork and the intellij ide are great for that, handling the common cases solidly and building up so many convenience functions I can't live without them now, like whitespace aware conflict resolution or single line commits.
- StillBored 7y ago
  Right, git sort of make the easy thing easier, and the hard things harder. I think its a large part why "stable" software branching is unpopular. The difficulty of tracking fixes against their core features over time is extremely difficult without an additional "shim" on top. Even knowing what group of commits comprise related functionality becomes difficult without layering on a commit group id (as gerrit does for example) on top. (AKA i'm looking at $file which has a set of commits for feature $Y, what are the related commits in other parts of the system required to implement this feature). Or for that matter, the ability to group a fix with its original commit (without rewritting public history) is why projects like the linux kernel implement "fixes:" tags which are then scanned by scripts/etc to detect fixes for a given commit group for back-porting functionality. Except in that case its brittle as frequently everyone involved forgets the tag. Bottom line, git is the VSC equivalent of C, it is quite powerful, but its got a lot of foot-gun moments and requires a lot of human rigor/experience to make it work well. Rigor that even the best users frequently mess up.
temac 7y ago
The thing about fiction is that it is... fiction! So yes, if you make the hypothesis that things went out so we would all be using BSD, then we would. And yes, successful projects and people always come from a part of luck. But so what? What happened in reality is what happened, and if they went lucky good for them, but this does not really removes anything from their achievements.
- weberc2 7y ago
  If your achievements came about by luck then how do you get off claiming credit for their success? I don’t think git was purely luck—it is a formidable tool in its own right, but there are better tools out there, and that was especially true at the time when git really took off, which is to say when GitHub began to be popular.
  - rlonstein 7y ago
    > If your achievements came about by luck then how do you get off claiming credit for their success? The same way it doesn't stop gamblers, stock pickers, actors, and entrepreneurs from mistaking survivorship bias for talent. That said, I don't think git was purely luck either.
xorcist 7y ago
Not really. Linux won because the GPL has proven to be more suitable to businesses, and especially commercial open source business models as practiced by companies such as Cygnus and Red Hat. BSD-style licenses tend to be a better fit for business models that sell proprietary extensions to free software. These form lock-in moats that inhibits the growth of any deeper ecosystems. We've seen this over and over again with things such as graphical subsystems for non-free UNIX, but also more recent examples with firewalls and storage boxes. Those are great for what they do, but work on the free parts are seen more like a gift to the community than a money maker. The tit-for-tat model of the GPL enables those ecosystems to form. By forcing your competitors to free their code in exchange for yours, game theory dictates that moats cannot form, and when everyone stands on other's shoulders development is faster. I'd say that's pretty much experimentally proven by now. Of course, reality is not as black and white, especially when GPL-style companies contribute to BSD-licensed software and vice versa. Perhaps PostgreSQL is a prominent example of that. There are however traces of these patterns there too, for example in how the many proprietary clustering solutions for the longest time kept the community from focusing on a standard way.
- CharlesW 7y ago
  > Linux won because the GPL has proven to be more suitable to businesses, and especially commercial open source business models as practiced by companies such as Cygnus and Red Hat. That's an interesting take, but I'm not sure I understand. Are you saying Linux would've lost (presumably to proprietary OSs?) if it used a permissive license? If the GPL has been proven to be more suitable for business, why is the use of GNU GPL licenses declining in favor of permissive licenses? I don't have a hog in this pen and so I'm not trying to provoke. I'd just like to hear thoughts on why it looks so different from where I sit.
  - mumblemumble 7y ago
    > If the GPL has been proven to be more suitable for business, why is the use of GNU GPL licenses declining in favor of permissive licenses? It isn't, at least not exactly. It's declining in favor of a combined permissive/commercial license model. And it's only doing that for products that are meant to be software components. The typical model there is that you use a permissive license for your core product as a way of getting a foot in the door. Apache 2.0 is permissive enough that most businesses aren't going to be afraid that integrating your component poses any real strategic risk. GPL, on the other hand, is more worrisome - even if you're currently a SAAS product, a critical dependency on GPLv2 components could become problematic if you ever want to ship an on-prem product, and might also become a sticking point if you're trying to sell the company. But it's really just a foot in the door. The free bits are typically enough to keep people happy just long enough to take a proper dependency on your product, but not sufficient to cover someone's long-term needs. Maybe it's not up to snuff on compliance. Or the physical management of the system is kind of a hassle. Something like that. That stuff, you supply as commercial components.
pjmlp 7y ago
And Microsoft at the time wasn't serious about POSIX.
CydeWeys 7y ago
It's a shame how poor the command-line usability of the git client is. Commands are poorly named and often do the wrong thing. It's really hard to explain to new users why you need to run `git checkout HEAD *` instead of `git reset` as you'd expect, why `git branch [branchname]` just switches to a branch whereas `git checkout -b [branchname]` actually creates it, etc. I really wish he'd collaborated with some more people in the early stages of writing git to come up with an interface that makes sense, because everyone is constantly paying the cost of those decisions, especially new git learners.
- adrianN 7y ago
  The git storage structure is not that difficult. People could implement their own compatible clients on top of it with a quite different UI. That there is nothing that overtook git as UI in popularity seems to be an indication that the interface is not as bad as many people claim.
  - CydeWeys 7y ago
    People have added better UIs on top of git. The problem is they don't come installed by default out of the box, and unless everyone else you work with is using them too it becomes quite hard for you to communicate properly over git issues (especially in writing development workflow docs). hg has a better UI out of the box, and is notably easier for new users to pick up and become productive with. You're underestimating how much inertia is created simply by being the out-of-the-box default, and how hard that inertia is to overcome even by better alternatives.
  - IcePic 7y ago
    GoT (gameoftrees.org) did just that. Built another tool similar but not same, using the same storage method underneath.
  - wbl 7y ago
    I use magit and it is a lifesaver.
  - weberc2 7y ago
DCKing 7y ago
While I think a world where BSD would have become dominant would have thrived, things would have been different. Because of GNU existing before Linux, and it never fully adopting Linux as its kernel, Linux has always existed seperate from a specific userland. In my mind, this allowed more variety to be created on top of it (for better or worse). Moreover, Linux' license has encouraged a culture of sharing around kernel components that the BSD license did not mandate. In an alternative timeline where BSD would be dominant, would we have e.g. free software AMD drivers? Would we have such big variation in containers, VMs, and scalabe system administration as we do on Linux? I wonder. No doubt that world would also be prettier than what we have now - in line with ways in which the BSDs are already better than Linux - but who knows.
spamizbad 7y ago
But those lawsuits were well settled long before Linux saw a significant inflection point, mostly with the rise of cloud computing. For example, AWS launched EC2 in 2006 (and Android 2 years after that), 12 years after the BSD lawsuit was settled. Linux still doesn't have a desktop footprint outside of the workstation market. By contrast, Apple (well, NeXT) incorporated portions of FreeBSD and NetBSD into their operating system. This might be a controversial opinion but: Linux likely "won" because it was better in the right areas.
- laumars 7y ago
  Linux was already used heavily long before "cloud" computing became a coined term. Not just for cheap hosting providers either, in the early 00s Linux dominated the 500 super computers. I also remember repairing an enterprise satellite box in 2002 which ran Linux. You're right that those law suits were settled long before Linux gained momentum though. FreeBSD and NetBSD were released after Linux and their predecessor (386BSD) is very approximately as old as Linux (work started on it long before Linux but it's first release was after Linux). As far as I can recall, 386BSD wasn't targeted by lawsuits. Also wasn't BSD used heavily by local ISPs in the 90s? In any case, I think Linux's success was more down to it being a "hacker" OS. People would tinker with it for fun in ways people didn't with BSD. Then those people eventually got decision making jobs and stuck with Linux because that's where their experience was. So if anything, Linux "won" not because it was "better" than BSD on a technical level but likely because it was "worse" which lead to it becoming more of a fun project to play with.
mikece 7y ago
I used to believe that absent the lawsuits that BSD would have been THE choice instead of Linux, but I think there's a lot of truth to the position that Linux was far more experimental and evolving rapidly -- and exciting! -- than FreeBSD (et all) which were busy doing things like powering the biggest web companies of the 90s (Yahoo and many more). Making waves and iterating rapidly was never going to mesh with the Unix Way (even open source Unix). As such, Linux got the mind-share of hackers, idealists, students, and startups and the rest is history. (I think it's a pity that the useful innovations that happened in Linux cannot be moved back over to FreeBSD because of licensing -- the computing world would be better off if it could.)
- rhinoceraptor 7y ago
  Serious question, what innovations in Linux would FreeBSD even want? I honestly can't think of any. IMO it's Linux that should want the features from FreeBSD/Solaris. I want ZFS, dtrace, SMF, and jails/zones. Linux is basically at feature parity, but the equivalents have a ton of fragmentation, weird pitfalls, and are overall half baked in comparison. For example, eBPF is a pretty cool technology. It can do amazing things, but it requires 3rd party tooling and a lot of expertise to be useful. It's not something you can just use on any random box like dtrace to debug a production issue.
  - auslander 7y ago
    > Serious question, what innovations in Linux would FreeBSD even want? I honestly can't think of any. systemd
tzs 7y ago
I'd say a big part was attitude toward common hardware and existing common setups. There were a couple of times early on when I wanted to try both Linux and one of the BSDs on my PC. I had CDs of both. With Linux, I just booted from a Linux boot floppy with my Linux install CD in the CD-ROM drive, and ran the installation. With BSD...it could not find the drive because I had an IDE CD-ROM and it only supported SCSI. I asked on some BSD forums or mailing lists or newsgroups where BSD developers hang out about IDE support, and was told that IDE is junk and no one would put an IDE CD-ROM in their server, so there was no interest in supporting it on BSD. I was quite willing to concede that SCSI was superior to IDE. Heck, I worked at a SCSI consulting company that did a lot of work for NCR Microelectronics. I wrote NCR's reference SCSI drivers for their chips for DOS, Windows, Netware, OS/2, and Netware. I wrote the majority of the code in the SCSI BIOS that NCR licensed to various PC makers. I was quite thoroughly sold on the benefits of SCSI, and my hard disks were all SCSI. But not for a sporadically used CD-ROM. At the time, SCSI CD-ROMs where about 4x as expensive as IDE CD-ROMs. So what if IDE was slower than SCSI or had higher overhead? The fastest CD-ROM drives still had maximum data rates well under what IDE could easily handle. If all you are going to use the CD-ROM for is installing the OS, and occasionally importing big data sets to disk, then it makes no sense to spring for an expensive SCSI CD-ROM. This is true on both desktops and servers. The second problem I ran into when I wanted to try BSD is that it did not want to share a hard disk with a previous DOS/Windows installation. It insisted on being given a disk upon which it could completely repartition. I seem to recall that it would be OK if I left free space on that disk, and then added DOS/Windows after installing BSD. Linux, on the other hand, was happy to come second after my existing DOS/Windows. It was happy to adjust the existing partition map to turn the unpartitioned space outside my DOS/Windows partition into a couple Linux partitions and install there. As with the IDE thing, the reasons I got from the BSD people for not supporting installing second were unconvincing. The issue was drive geometry mapping. Once upon a time, when everything used the BIOS to talk to the disk, sectors where specified by giving their actual physical location, specifying what cylinder they were on (C), which head to get the right platter (H), and on the track that C and H specifies, which sector it is (S). This was commonly called a CHS address. There were limits on the max values of C, H, and S, and when disks became available that had sectors whose CHS address would exceed those limits, a hack was employed. The BIOS would lie to the OS about the actual disk geometry. For example, suppose the disk had more heads than would fit in the H field of a BIOS disk request. The BIOS might report to the OS that the disk only has half that number of heads, and balance that out by reporting twice as many cylinders as it really has. It can then tranlate between this made up geometry that the OS thinks the disk is using and the actual geometry of the real disk. For disks on interfaces that don't even have the concept of CHS, such as SCSI which uses a simple block number addressing scheme, the BIOS would still make up a geometry so that BIOS clients could use CHS addressing. If you have multiple operating systems sharing the disk, some using the BIOS for their I/O, and some not, they all really should be aware of that made up geometry, even if they don't use it themselves, to make sure that they all agree on which parts of the disk belong to which operating systems. Fortunately, it turns out that DOS partitioning had some restrictions on alignment and size, and other OSes tended to follow those same restrictions for compatibility, and you could almost always look at an existing partition scheme and figure out from the sizes and positions of the existing partitions either what CHS to real sector mapping the partition maker was using. Details on doing this were includes in the SCSI-2 Common Access Method ANSI standard. The people who did Linux's SCSI stuff have a version [1]. I said "almost always" above. In practice, I never ran into a system formatted and partitioned by DOS/Windows for which it gave a virtual geometry that did not work fine for installing other systems for dual boot. But this remote possibility that somehow one might have an existing partitioning scheme that would get trashed due to a geometry mismatch was enough for the BSD people to say no to installing second to DOS/Windows. In short, with Linux there was a good chance an existing DOS/Windows user could fairly painlessly try Linux without needing new hardware and without touching their DOS/Windows stuff. With BSD, a large fraction would need new hardware and/or be willing to trash their existing DOS/Windows installation. By the time the BSD people realized they really should be supporting IDE CD-ROM and get along with prior DOS/Windows on the same disk, Linux was way ahead. [1] https://github.com/torvalds/linux/blob/master/drivers/scsi/scsicam.c https://github.com/torvalds/linux/blob/master/drivers/scsi/s...

by wbl 7y ago

qorrect 7y ago

> but I've never had something as multiheaded as the linux repo. Git is overkill for so many projects, I hate being forced into for everything.

growlist 7y ago
Definitely. I find SVN so much easier. But we must all use Git because cargo cultism is cool, or something.
- deleted 7y ago
  [deleted]
- majewsky 7y ago
  We use Git because GitHub happened to be the first non-shitty code repository website.
  - growlist 7y ago
    I'm talking about internal repos.
    - soraminazuki 7y ago
      I know people like to complain about git's interface, but is it so lacking to the point that it justifies the time spent on learning multiple version control systems?
      - compiler-guy 7y ago
        Yes.
        catalogia 7y ago
        Go easy on yourself and stop forcing yourself to use the CLI tools if you dislike them so much. For every editor and IDE under the sun, there exists extensions for these version control systems that provide you with a nicer interface than the CLI interface of any VCS. For years probably 99% of my interactions with git, or any other VCS, is through editor extensions like magit or fugitive.
- adrianN 7y ago
  How do you work on more than one thing at once with svn without manually managing patch files?
  - taco_emoji 7y ago
    Branches.
    - tasuki 7y ago
      Branches in SVN are such a pain! If I recall correctly, creating a branch in SVN consists of making a full copy of everything (remotely, usually). In Git, creating a new branch consists of creating a new pointer to an existing commit.
      - _ph_ 7y ago
        Yes, branches look like full copies, but they are sparse copies. So only any changed data on the branch gets actually stored in the repository.
      - taco_emoji 7y ago
        That's basically all it is in SVN as well... And of course it's remote, every action in SVN is remote since it's centralized (except for shelving).
holtalanm 7y ago
care to elaborate? I fail to see how git would be considered 'overkill' for a project.
- bildung 7y ago
  Other version control software has way simpler syntax and workflow. Subversion for example. The complexity of git makes total sense if you indeed have a complex, multi-HEADed project like the Linux kernel. But most software isn't Linux.
  - Scarblac 7y ago
    Subversion needs a server, for one. For a single user and a single file, Git is already less overhead.
    - taco_emoji 7y ago
      It doesn't, actually, you can host a repo on the filesystem without any sort of server process. http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.create.html http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.create...
  - vultour 7y ago
    You literally need to know two commands to work with git in a simple project; add and commit. I don’t see how that is any complicated?
    - jcranmer 7y ago
      By that argument, you literally need to know a single command to work with Mercurial (hg commit) or SVN (svn commit), or hell, even CVS (cvs commit).
      - drunken-serval 7y ago
        git commit -a then.
jbob2000 7y ago
How is git overkill? Perhaps you're conflating Git and Github? Or perhaps you're confusing git best practices or methodologies with git functionality? Git costs nothing to use, you add it to a project and then it sits there until you do something with it. If you want to use it as a "super save" function, it'll do that. If you want to use it to track every change to every line of code you've written, it'll do that too.
kungito 7y ago
Git is the simplest, low friction, low cost, low everything above file storage. How can there be something simpler atop an existing file system (I know there are some versioning file systems but I've never used them). I use git for practically anything I do. I to git init and I have my project versioned and I can but don't have to even add messages to each of my versions. You don't have to use anything else if you don't want to but you have so many options if you need them. You don't have to even use git on line if you don't want but if you do there are multiple (even open source) git repositories with free private repos. What is there not to like?
- bildung 7y ago
  > I know there are some versioning file systems but I've never used them But those other systems were the whole point of the post you replied to ;)
- jcranmer 7y ago
  > How can there be something simpler atop an existing file system Mercurial? Similar DVCS concepts, but you no longer have to worry about garbage collection or staging areas...
  - kungito 7y ago
    What garbage collection? Isn't staging area actually a feature? I've never used anything else since when I started needing something like 5 years ago git was already a recommended choice, but I also never felt like I needed anything else.
    - jcranmer 7y ago
      If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages. And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.
leshow 7y ago
It has such minimal overhead I don't know how you could say that.
bcrosby95 7y ago
Sure. But you know what is more complex than git? Git + <anything else>. If you use git at all, you may as well use it for everything. If you have control over which version control system to use, there's no good reason to actively use multiple ones at the same time.
andyjohnson0 7y ago
I agree. I have reasonable familiarity with git but I find that traditional SVN-type systems often (not always) have a lower cognitive overhead. If I ever need to manage the codebase for a huge, multi-level project involving large numbers of geographically dispersed developers then I'm sure I'd use git. For simpler projects, not so likely.
ivalm 7y ago
I use git at work where branching matters, I also use git for home projects where git add/commit/push/pull are the only commands I use. Git is efficient at both scales, it is opposite of overkill.
- baot 7y ago
  Furthermore, if you're forced to use it, it's because you need it to interact with others' versions of the repo, in which case branching matters.

naringas 7y ago

what if google built androd on top of BSD?

pjmlp 7y ago
Almost there. The Linux kernel is the only GPL piece still standing.
liveoneggs 7y ago
wouldn't change a thing. Apple built on freebsd; Android userland and libc is all BSD
- rhinoceraptor 7y ago
  Slight clarification, Darwin is a mish-mash of CMU's Mach microkernel, some 4.3 BSD, some BSD userland, some GNU userland (although that seems to be going away), and then NeXT/Apple stuff on top of that.

LoSboccacc 7y ago

imho git is not a version control system but a version control tool. when we started using git trough a system mediating all the functionality trough a goal/workflow oriented approach our whole experience radically changed. both fork and the intellij ide are great for that, handling the common cases solidly and building up so many convenience functions I can't live without them now, like whitespace aware conflict resolution or single line commits.

StillBored 7y ago
Right, git sort of make the easy thing easier, and the hard things harder. I think its a large part why "stable" software branching is unpopular. The difficulty of tracking fixes against their core features over time is extremely difficult without an additional "shim" on top. Even knowing what group of commits comprise related functionality becomes difficult without layering on a commit group id (as gerrit does for example) on top. (AKA i'm looking at $file which has a set of commits for feature $Y, what are the related commits in other parts of the system required to implement this feature). Or for that matter, the ability to group a fix with its original commit (without rewritting public history) is why projects like the linux kernel implement "fixes:" tags which are then scanned by scripts/etc to detect fixes for a given commit group for back-porting functionality. Except in that case its brittle as frequently everyone involved forgets the tag. Bottom line, git is the VSC equivalent of C, it is quite powerful, but its got a lot of foot-gun moments and requires a lot of human rigor/experience to make it work well. Rigor that even the best users frequently mess up.

temac 7y ago

The thing about fiction is that it is... fiction! So yes, if you make the hypothesis that things went out so we would all be using BSD, then we would. And yes, successful projects and people always come from a part of luck. But so what? What happened in reality is what happened, and if they went lucky good for them, but this does not really removes anything from their achievements.

weberc2 7y ago
If your achievements came about by luck then how do you get off claiming credit for their success? I don’t think git was purely luck—it is a formidable tool in its own right, but there are better tools out there, and that was especially true at the time when git really took off, which is to say when GitHub began to be popular.
- rlonstein 7y ago
  > If your achievements came about by luck then how do you get off claiming credit for their success? The same way it doesn't stop gamblers, stock pickers, actors, and entrepreneurs from mistaking survivorship bias for talent. That said, I don't think git was purely luck either.

xorcist 7y ago

Not really. Linux won because the GPL has proven to be more suitable to businesses, and especially commercial open source business models as practiced by companies such as Cygnus and Red Hat. BSD-style licenses tend to be a better fit for business models that sell proprietary extensions to free software. These form lock-in moats that inhibits the growth of any deeper ecosystems. We've seen this over and over again with things such as graphical subsystems for non-free UNIX, but also more recent examples with firewalls and storage boxes. Those are great for what they do, but work on the free parts are seen more like a gift to the community than a money maker. The tit-for-tat model of the GPL enables those ecosystems to form. By forcing your competitors to free their code in exchange for yours, game theory dictates that moats cannot form, and when everyone stands on other's shoulders development is faster. I'd say that's pretty much experimentally proven by now. Of course, reality is not as black and white, especially when GPL-style companies contribute to BSD-licensed software and vice versa. Perhaps PostgreSQL is a prominent example of that. There are however traces of these patterns there too, for example in how the many proprietary clustering solutions for the longest time kept the community from focusing on a standard way.

CharlesW 7y ago
> Linux won because the GPL has proven to be more suitable to businesses, and especially commercial open source business models as practiced by companies such as Cygnus and Red Hat. That's an interesting take, but I'm not sure I understand. Are you saying Linux would've lost (presumably to proprietary OSs?) if it used a permissive license? If the GPL has been proven to be more suitable for business, why is the use of GNU GPL licenses declining in favor of permissive licenses? I don't have a hog in this pen and so I'm not trying to provoke. I'd just like to hear thoughts on why it looks so different from where I sit.
- mumblemumble 7y ago
  > If the GPL has been proven to be more suitable for business, why is the use of GNU GPL licenses declining in favor of permissive licenses? It isn't, at least not exactly. It's declining in favor of a combined permissive/commercial license model. And it's only doing that for products that are meant to be software components. The typical model there is that you use a permissive license for your core product as a way of getting a foot in the door. Apache 2.0 is permissive enough that most businesses aren't going to be afraid that integrating your component poses any real strategic risk. GPL, on the other hand, is more worrisome - even if you're currently a SAAS product, a critical dependency on GPLv2 components could become problematic if you ever want to ship an on-prem product, and might also become a sticking point if you're trying to sell the company. But it's really just a foot in the door. The free bits are typically enough to keep people happy just long enough to take a proper dependency on your product, but not sufficient to cover someone's long-term needs. Maybe it's not up to snuff on compliance. Or the physical management of the system is kind of a hassle. Something like that. That stuff, you supply as commercial components.

pjmlp 7y ago

And Microsoft at the time wasn't serious about POSIX.

CydeWeys 7y ago

It's a shame how poor the command-line usability of the git client is. Commands are poorly named and often do the wrong thing. It's really hard to explain to new users why you need to run `git checkout HEAD *` instead of `git reset` as you'd expect, why `git branch [branchname]` just switches to a branch whereas `git checkout -b [branchname]` actually creates it, etc. I really wish he'd collaborated with some more people in the early stages of writing git to come up with an interface that makes sense, because everyone is constantly paying the cost of those decisions, especially new git learners.

adrianN 7y ago
The git storage structure is not that difficult. People could implement their own compatible clients on top of it with a quite different UI. That there is nothing that overtook git as UI in popularity seems to be an indication that the interface is not as bad as many people claim.
- CydeWeys 7y ago
  People have added better UIs on top of git. The problem is they don't come installed by default out of the box, and unless everyone else you work with is using them too it becomes quite hard for you to communicate properly over git issues (especially in writing development workflow docs). hg has a better UI out of the box, and is notably easier for new users to pick up and become productive with. You're underestimating how much inertia is created simply by being the out-of-the-box default, and how hard that inertia is to overcome even by better alternatives.
- IcePic 7y ago
  GoT (gameoftrees.org) did just that. Built another tool similar but not same, using the same storage method underneath.
- wbl 7y ago
  I use magit and it is a lifesaver.
- weberc2 7y ago

DCKing 7y ago

While I think a world where BSD would have become dominant would have thrived, things would have been different. Because of GNU existing before Linux, and it never fully adopting Linux as its kernel, Linux has always existed seperate from a specific userland. In my mind, this allowed more variety to be created on top of it (for better or worse). Moreover, Linux' license has encouraged a culture of sharing around kernel components that the BSD license did not mandate. In an alternative timeline where BSD would be dominant, would we have e.g. free software AMD drivers? Would we have such big variation in containers, VMs, and scalabe system administration as we do on Linux? I wonder. No doubt that world would also be prettier than what we have now - in line with ways in which the BSDs are already better than Linux - but who knows.

spamizbad 7y ago

But those lawsuits were well settled long before Linux saw a significant inflection point, mostly with the rise of cloud computing. For example, AWS launched EC2 in 2006 (and Android 2 years after that), 12 years after the BSD lawsuit was settled. Linux still doesn't have a desktop footprint outside of the workstation market. By contrast, Apple (well, NeXT) incorporated portions of FreeBSD and NetBSD into their operating system. This might be a controversial opinion but: Linux likely "won" because it was better in the right areas.

laumars 7y ago
Linux was already used heavily long before "cloud" computing became a coined term. Not just for cheap hosting providers either, in the early 00s Linux dominated the 500 super computers. I also remember repairing an enterprise satellite box in 2002 which ran Linux. You're right that those law suits were settled long before Linux gained momentum though. FreeBSD and NetBSD were released after Linux and their predecessor (386BSD) is very approximately as old as Linux (work started on it long before Linux but it's first release was after Linux). As far as I can recall, 386BSD wasn't targeted by lawsuits. Also wasn't BSD used heavily by local ISPs in the 90s? In any case, I think Linux's success was more down to it being a "hacker" OS. People would tinker with it for fun in ways people didn't with BSD. Then those people eventually got decision making jobs and stuck with Linux because that's where their experience was. So if anything, Linux "won" not because it was "better" than BSD on a technical level but likely because it was "worse" which lead to it becoming more of a fun project to play with.

mikece 7y ago

I used to believe that absent the lawsuits that BSD would have been THE choice instead of Linux, but I think there's a lot of truth to the position that Linux was far more experimental and evolving rapidly -- and exciting! -- than FreeBSD (et all) which were busy doing things like powering the biggest web companies of the 90s (Yahoo and many more). Making waves and iterating rapidly was never going to mesh with the Unix Way (even open source Unix). As such, Linux got the mind-share of hackers, idealists, students, and startups and the rest is history. (I think it's a pity that the useful innovations that happened in Linux cannot be moved back over to FreeBSD because of licensing -- the computing world would be better off if it could.)

rhinoceraptor 7y ago
Serious question, what innovations in Linux would FreeBSD even want? I honestly can't think of any. IMO it's Linux that should want the features from FreeBSD/Solaris. I want ZFS, dtrace, SMF, and jails/zones. Linux is basically at feature parity, but the equivalents have a ton of fragmentation, weird pitfalls, and are overall half baked in comparison. For example, eBPF is a pretty cool technology. It can do amazing things, but it requires 3rd party tooling and a lot of expertise to be useful. It's not something you can just use on any random box like dtrace to debug a production issue.
- auslander 7y ago
  > Serious question, what innovations in Linux would FreeBSD even want? I honestly can't think of any. systemd

tzs 7y ago

I'd say a big part was attitude toward common hardware and existing common setups. There were a couple of times early on when I wanted to try both Linux and one of the BSDs on my PC. I had CDs of both. With Linux, I just booted from a Linux boot floppy with my Linux install CD in the CD-ROM drive, and ran the installation. With BSD...it could not find the drive because I had an IDE CD-ROM and it only supported SCSI. I asked on some BSD forums or mailing lists or newsgroups where BSD developers hang out about IDE support, and was told that IDE is junk and no one would put an IDE CD-ROM in their server, so there was no interest in supporting it on BSD. I was quite willing to concede that SCSI was superior to IDE. Heck, I worked at a SCSI consulting company that did a lot of work for NCR Microelectronics. I wrote NCR's reference SCSI drivers for their chips for DOS, Windows, Netware, OS/2, and Netware. I wrote the majority of the code in the SCSI BIOS that NCR licensed to various PC makers. I was quite thoroughly sold on the benefits of SCSI, and my hard disks were all SCSI. But not for a sporadically used CD-ROM. At the time, SCSI CD-ROMs where about 4x as expensive as IDE CD-ROMs. So what if IDE was slower than SCSI or had higher overhead? The fastest CD-ROM drives still had maximum data rates well under what IDE could easily handle. If all you are going to use the CD-ROM for is installing the OS, and occasionally importing big data sets to disk, then it makes no sense to spring for an expensive SCSI CD-ROM. This is true on both desktops and servers. The second problem I ran into when I wanted to try BSD is that it did not want to share a hard disk with a previous DOS/Windows installation. It insisted on being given a disk upon which it could completely repartition. I seem to recall that it would be OK if I left free space on that disk, and then added DOS/Windows after installing BSD. Linux, on the other hand, was happy to come second after my existing DOS/Windows. It was happy to adjust the existing partition map to turn the unpartitioned space outside my DOS/Windows partition into a couple Linux partitions and install there. As with the IDE thing, the reasons I got from the BSD people for not supporting installing second were unconvincing. The issue was drive geometry mapping. Once upon a time, when everything used the BIOS to talk to the disk, sectors where specified by giving their actual physical location, specifying what cylinder they were on (C), which head to get the right platter (H), and on the track that C and H specifies, which sector it is (S). This was commonly called a CHS address. There were limits on the max values of C, H, and S, and when disks became available that had sectors whose CHS address would exceed those limits, a hack was employed. The BIOS would lie to the OS about the actual disk geometry. For example, suppose the disk had more heads than would fit in the H field of a BIOS disk request. The BIOS might report to the OS that the disk only has half that number of heads, and balance that out by reporting twice as many cylinders as it really has. It can then tranlate between this made up geometry that the OS thinks the disk is using and the actual geometry of the real disk. For disks on interfaces that don't even have the concept of CHS, such as SCSI which uses a simple block number addressing scheme, the BIOS would still make up a geometry so that BIOS clients could use CHS addressing. If you have multiple operating systems sharing the disk, some using the BIOS for their I/O, and some not, they all really should be aware of that made up geometry, even if they don't use it themselves, to make sure that they all agree on which parts of the disk belong to which operating systems. Fortunately, it turns out that DOS partitioning had some restrictions on alignment and size, and other OSes tended to follow those same restrictions for compatibility, and you could almost always look at an existing partition scheme and figure out from the sizes and positions of the existing partitions either what CHS to real sector mapping the partition maker was using. Details on doing this were includes in the SCSI-2 Common Access Method ANSI standard. The people who did Linux's SCSI stuff have a version [1]. I said "almost always" above. In practice, I never ran into a system formatted and partitioned by DOS/Windows for which it gave a virtual geometry that did not work fine for installing other systems for dual boot. But this remote possibility that somehow one might have an existing partitioning scheme that would get trashed due to a geometry mismatch was enough for the BSD people to say no to installing second to DOS/Windows. In short, with Linux there was a good chance an existing DOS/Windows user could fairly painlessly try Linux without needing new hardware and without touching their DOS/Windows stuff. With BSD, a large fraction would need new hardware and/or be willing to trash their existing DOS/Windows installation. By the time the BSD people realized they really should be supporting IDE CD-ROM and get along with prior DOS/Windows on the same disk, Linux was way ahead. [1] https://github.com/torvalds/linux/blob/master/drivers/scsi/scsicam.c https://github.com/torvalds/linux/blob/master/drivers/scsi/s...