10 ms·

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. Th

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software required git, for all its issues, is not bundling the kitchen sink. I do prefer the "do one thing and do it well" approach.

queuebert 3y ago
From an ABI perspective, there's not a huge difference, mostly just where the code resides on disk, all local or scattered across multiple inodes.
- panzi 3y ago
  I think the point is that there is the option to have only git, which reduces the attack surface of only that tool, if you don't want/need anything else.
Dylan16807 3y ago
My git seems to be mostly a single binary, and it's larger than fossil.
jayski 3y ago
I think SQLite is fantastic and Richard is obviously a genius. But I always found his obsession with single binary monoliths odd. As you mentioned it goes against the Unix philosophy of do one thing and do it well. To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently.
- bane 3y ago
  I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libraries hasn't helped things. I know objectively that there's a notion that you can update libraries instead of applications, but it feels like it makes updating applications fragile and you inevitably end up in some kind of dependency hell. "But breaking insecure applications is a feature!" I mean, okay, I guess. But I still need something to work and don't want to spend all day fixing broken layers of dependent stuff. If I have to do that, I may as well just update a single binary. Go seems to have come back around to this style of thinking, and in a sense container images and JAR files are often trying to replicate what it's like to just download a binary, chmod +x it, and execute it.
  - osigurdson 3y ago
    Well, it’s either a single executable in a container or a bunch of dlls/sos in a container.
  - beebmam 3y ago
    If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.
    - jjnoakes 3y ago
      It depends. Sometimes you have no choice but to deploy to an old machine with back-leveled tls libraries, and static linking can save the day. Of course that tends to be the exception (hopefully).
    - andersa 3y ago
      The situation on windows is fascinating: everyone links these libraries dynamically, and yet, there are about two hundred of them on my system, every application using its own uniquely outdated version.
    - kibwen 3y ago
      On a closed-source system, sure. On a system where you have the source, you have the option to rebuild your binaries.
    - bborud 3y ago
      In my practical experience the set of things that can go wrong if you link apps dynamically is much larger than the problems that arise when they are statically linked. For one, it is more complicate to keep track of which of the many shared libraries on a typical system are used by which application. It is common that the same library occurs multiple times in different versions, built by different people/organizations and residing in different directories. Quick, without looking: which TLS library do your network exposed subsystems use, which directories are they in and where did you install them from. When you do go to look: did you find what you expected? Have a look at all the other shared libraries on your system. Do you know which binaries use them? Do you know which versions of which libraries work with which binaries? Do you trust the information your package manager has about version requirements? Does it even have that information? Then there's the problem of what happens when you upgrade. The servers you run might have a rigorous battery of tests. But now you are running them with libraries they were not tested against. Sure, most of the time it'll work. But you don't know that. And you have no way of knowing that without downloading, building and running the tests. Or have someone else do that. I've been in the situation where someone inadvertently updated a library in production and everything came crashing down. Not only did it take down the site, but it took a while to figure out what happened. Both because the person who did it wasn't aware of what they'd done. And the problem didn't manifest itself in a way that made the root cause obvious. The clearest risk with statically linked binaries is if they are not updated when there is, for instance a security problem. But in practice I find that easier to deal with since I know what I'm running, and for anything important, I'm usually aware of what version it is or when I last checked for updates/problems.
- forrestthewoods 3y ago
  I’m so thankful that Rust is helping popularize the solo exe that “just works”. I don’t care if a program uses DLLs or not. But my rule is “ship your fucking dependencies”. Python is the worst offender at making it god damned impossible to build and run a fucking program. I swear Docker and friends only exist because merely executing a modern program is so complicated and fragile it requires a full system image.
  - docandrew 3y ago
    Wish I had more upvotes for this sentiment.
  - bombela 3y ago
    The only way I know to manage python dependencies is Bazel as the build system, and implementing a custom set of rules that download and build all python dependencies. The download is done in a git repo. All magically missing libs must be added to the repo and Bazel. And finally you might have a way to... tar the output into a docker container... sigh
  - ogurechny 3y ago
    The choice is actually between dealing with complexity and shifting responsibility for that to someone else. The tools themselves (e.g. virtual environments) can be used for both. Either people responsible for packaging (authors, distribution maintainers, etc.) have some vague or precise understanding of how their code is used, on which systems, what are its dependencies (not mere names and versions, but functional blocks and their relative importance), when they might not be available, and which releases break which compatibility options, or they say “it builds for me with default settings, everything else is not my problem”.
    - josephg 3y ago
      > Either people responsible for packaging have some vague or precise understanding of how their code is used, on which systems, what are its dependencies But with python it’s a total mess. I’ve been using automatic1111 lately to generate stable diffusion images. The tool maintains multiple multi-hundred line script files for each OS which try to guess the correct version of all the dependencies to download and install. What a mess! And why is the job of figuring out the right version of pytorch the job of an end user program? I don’t know if PyTorch is uniquely bad at this, but all this work is the job of a package manager with well designed packages. It should be as easy as “cargo run” to run the program, no matter how many or how few dependencies there are. No matter what operating system I’m using. Even npm does a better job of this than python.
- lolinder 3y ago
  Slight tangent: it bugs me when people say "it goes against the Unix philosophy" as though The Unix Philosophy were some kind of religious text. Not everything should be a pluggable Unix executable, and Fossil making non-Unixy choices doesn't reflect poorly on it. They just chose a different philosophy.
- eesmith 3y ago
  > it goes against the Unix philosophy of do one thing and do it well For me, Perl shows just how restricted that viewpoint was. After I learned Perl, I stopped caring about tr, and sed, and many of the other "one thing well" command-line tools. And I've no desire to swap out and modify the 's//' component of perl. Perl does "one thing" - interpret Perl programs - even though it also replaces many things. I know 'rmdir' exists. It does one thing, well - remove an empty directory. It's been around since the first release of Unix. However, I use "rm -rf" because it's easier to use a more powerful tool which handles empty directory removal as a special case. You can also change your viewpoint and say that Fossil does do one thing well: it's a distributed project control system. That's a new category I just made up, to highlight just how subjective "one thing" is.
  - herewulf 3y ago
    I like `rmdir` because I don't have to check if a directory that I think is empty is actually empty with `ls -la` before removing it. This happens a lot with moving stuff out of directories (sometimes to different destinations).
    - eesmith 3y ago
      Even in that case, you can use "rm -d" instead of "rmdir". % mkdir herewulf % rm herewulf rm: herewulf: is a directory % rm -d herewulf % % mkdir herewulf % touch herewulf/nonempty.txt % % rm herewulf/ rm: herewulf/: is a directory % rm -d herewulf/ rm: herewulf/: Directory not empty % rm herewulf/nonempty.txt % rm -d herewulf/ The only distinct feature of rmdir is that it won't remove things that aren't files: % touch herewulf % rm -d herewulf % touch herewulf % rmdir herewulf rmdir: herewulf: Not a directory Is that "one thing well" really enough to justify its own tool? Unix has always had a tension between "one thing well" and "one powerful tool". Is 'cc' a preprocessor? A compiler? A linker? Yes! Does 'date' show the current date (and time), set the system date, or convert between dates? Yes!
      - cesarb 3y ago
        > Is 'cc' a preprocessor? A compiler? A linker? Yes! It's none of them; it's a driver which calls the preprocessor (cpp), the real compiler, and the linker (ld).
- kaba0 3y ago
  Unix’s philosophy is more of what you’d call ‘guidelines’, and is not universally applicable — not all problems can be decomposed nicely, and IPC just gives you a badly debuggable hodgepodge of added accidental complexity. It’s good for trivial tools like ls, cat, etc, but something more complex is likely better off as a monolith.
- usrusr 3y ago
  Exceptional things rarely happen without some outlier conviction involved. Most things happening due to outlier convictions are just that, follies that lead nowhere. But when the stars align and there's both great ability involved and a genuine gap to fill that would have remained undiscovered workout the outlier conviction, something like SQLite happens.
- alpaca128 3y ago
  > To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. But where do you draw the line? What's "one thing"? - The size and complexity between cli tools doing one thing varies by orders of magnitude, some of those programs are much larger than this Fossil "monolith". Should a component have more functionality if separation means 10 times slower performance? What if it has hundreds of such features? What if separating those features means a hundredfold increase in complexity for setting up the software as it now has distributed dependencies? Should you have a separate audio player when a video player could already do the job out of necessity? Should a terminal support scrolling if you can already get that via tmux? The Unix philosophy is bad for judging individual programs.
- flohofwoe 3y ago
  The UNIX philosophy of minimal cmdline tools that do one thing right is fine and the Go-style 'monolithic exe' without runtime dependencies except the OS is also fine (and both philosophies actually don't need to collide). The problem is all the software that depends on tons of dependencies that are brought in dynamically. Just look at Jekyll vs Hugo. I have Jekyll break regularly when something (seemingly) unrelated changes on my machine, but Hugo is just rock solid. Or another much more annoying example: Linux executables linking with glibc and then not running on systems that don't have that particular version of glibc installed.
- bborud 3y ago
  I think the "Unix philosophy" is best applied to problems that indeed can be de-composed into clear discrete steps. In fact, that's the metric I use when I write command line utilities: does this make sense in a pipe? There are a lot of things where this isn't very practical. For instance, imagine building a web server that consists of a couple of dozen discrete utilities that are then cobbled together using pipes. Or even implementing the core feature set of Git in this manner. Would it be practical? Would it be better if Git was an enormous shellscript that connected all of these "things" into an application? What does that give you? And what would be the cost? How would you do SQLite (the CLI application) as a bunch of discrete commands?
- sgbeal 3y ago
  > As you mentioned it goes against the Unix philosophy of do one thing and do it well. To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. Anecdote: when i first met Richard in 2011, after having contributed to Fossil since 2008, i asked him why he chose to implement fossil as a monolithic app instead of as a library. His answer was, "because I wanted it working next week instead of next month." It was a matter of expedience and rewriting it now would be a major undertaking for little benefit. Reimplementing fossil as a library is a years-long undertaking (literally) and is not something we're interested in doing directly within the Fossil project, but is something i maintain as a semi-third-party effort, along with a handful of other Fossil contributors, over at <https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil>.
- IshKebab 3y ago
  The Unix philosophy was a very rough guideline from the 70s, not a divine commandment that must be followed unwaveringly. There are a gazillion examples of excellent pieces of software that don't do "one thing" that can be piped as unstructured text into another program. Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`. Laughable. But how many people decry Excel for "not more than one thing"? You probably haven't even considered it. I'd put it up there with "premature optimisation" as one of the most damaging programming mantras.
  - tzs 3y ago
    > Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`. It would be even more cumbersome than that. After that command you'd have to restore foo.xls from a backup, and then do the edit again this time remembering that the "> foo.xls" executes before the pipe executes. :-) I wonder if anyone has written something to make pipes like that work? E.g., write two programs, "replace" and "with" that could be used like this: replace foo.xls | ... | with foo.xls What "replace [file]" would do is set a write lock on the file, copy the file to stdout, then release the lock. What "with [file]" would do is copy stdin to the file, after obtaining a write lock on the file. I think most shells would start the components of a pipe in order so "replace" should be able to set its lock before "with" tries to get a lock, but to be safe "with" could be written to buffer incoming data and only start checking the lock after it has received a significant amount or seen an EOF on stdin. Or "replace" and "with" could coordinate using some out-of-band method.
    - Sprocklem 3y ago
      `sponge` from moreutils more or less does this.
- naasking 3y ago
  > To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. Why is "cleaner" the only thing that matters? Why not "functional/featureful"? It's open source so it can be modified, but I'm not sure why ability to swap matters.
maxxk 3y ago
> git, for all its issues, is not bundling the kitchen sink. It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal. While you can download Fossil as a 3.3 MB standalone binary for any supported platform.
- op00to 3y ago
  I don’t develop on a machine where this matters, even at scale. Who cares about a 47MB difference on machines with a few gigs of ram?
  - deleted 3y ago
    [deleted]
  - nickpsecurity 3y ago
    I used to try to make tools fit in cache, esp L1, because they'd load and run a lot faster. Lightening fast! Try that to see if it still works on the newer machines.
  - abwizz 3y ago
    for scale you usally want things to be efficient. and caring about caching effects is not seldomly the lowest hanging fruit.
- hot_gril 3y ago
  I remember people installing git-bash and putty for Windows in computer science class to fill in all the gaps. Idk what the deal was with that cause, uh, why would I use Windows.
- willdr 3y ago
  But on a developer machine this doesn't matter does it?
  - NikkiA 3y ago
    Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32 it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent.
devin 3y ago
the more important takeaway imho is that the tooling doesn't really matter, but i hear you.
- dmvdoug 3y ago
  Outsider here. One thing that I have observed about programmers is how obsessed they are with tooling. Whether it’s exactly which model of ergonomic keyboard or exactly which toolchain(s) they’re using, there seems to be an endless desire or eagerness to shoot the shit over tooling.
forrestthewoods 3y ago
> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable for petabyte scale storage and terabyte scale partial clones, imho. Git feels like an inferior technology that succeeded and now we’re mostly stuck with it. Maybe someday someone will create a proper Perforce competitor and we can all migrate to something that’s actually good.
- hprotagonist 3y ago
  > The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …
  - LordShredda 3y ago
    Not an issue, if remote goes down you can always restore from backup
    - hprotagonist 3y ago
      having been the guy who did that: i assure you, doing it is An Issue.
      - KerrAvon 3y ago
        I was once responsible for doing this with a Perforce server. Only time in my career a VCS has lost data. This was decades ago now and the data loss might have been due to hardware; I cannot definitively blame Perforce, but man was it shitty to deal with at the time. We migrated to Subversion and never had another issue.
        hprotagonist 3y ago
zaps 3y ago
> git, for all its issues, is not bundling the kitchen sink In my experience, installing git on most Linux distros pulls in a bunch of perl dependencies
- qbasic_forever 3y ago
  Git includes a web interface written as a perl CGI script, so yeah it has a lot more dependencies than people realize. It is most certainly not just a simple single binary to plop on a machine and call it good.
qbasic_forever 3y ago
Git actually is bundling a lot of stuff you probably don't realize. Run 'git instaweb' for example and it will spin up a local CGI server and perl CGI script to give a very simple web UI: https://git-scm.com/docs/git-instaweb https://git-scm.com/docs/git-instaweb Fossil isn't much different in core functionality here. There is a ton of email client integration and functionality in git too that most people who only use GitHub probably have absolutely no idea exists or even why it's there. Stuff like sending email patches right from git: https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email
- thayne 3y ago
  FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.
  - qbasic_forever 3y ago
    Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.
    - westurner 3y ago
      Securing the software supply chain for software updaters and VCS systems means PKI and/or key distribution, cryptographic hashes and signatures, file manifests with per-archive-file checksums, and DAC extended filesystem attributes for installed files; Ironically, there's more to it than just `curl`'ing a binary into place and not remembering to update it. And that is why package managers.
      - westurner 3y ago
        And sigstore; for centralized software artifact (package,) hashes: https://sigstore.dev/ https://sigstore.dev/
velcrovan 3y ago
And yet, because git does not bundle those things, which actually do belong as part of a modern SCMS, people lock themselves into GitHub or Gitlab, which provide those missing pieces.
pyeri 3y ago
The "do one thing and do it well" approach died the day when systemd became a super hit.
3cats-in-a-coat 3y ago
The concept that you can isolate "one thing" and it's not in itself "a set of other things" is a very nasty myth in the world of programming. Everything is composite. Everything is a pipeline of commands. Made of things. The "job to do" is in the eye of the beholder, not absolute. The "single responsibility principle" is not applicable in reality. It's always a tradeoff of maintaining a balance of cohesion and modularity. Where we make a cut and call it a "thing" is up to us and our needs. For many people, for example, the tools of GitHub are so integral to their workflow, they can't use Git alone at all. So to them GitHub is the "one thing". So SQLite has their own "thing".
- hinkley 3y ago
  I'm not sure where I stand in this whole argument, but > The "job to do" is in the eye of the beholder, not absolute. It's definitely the case that the less sophisticated the user, the more requirements they can pack into a sentence.
- IshKebab 3y ago
  They're not saying it doesn't encapsulate more than one thing. They're saying *at the abstraction level of "stuff you need to install and run" it is one thing.
  - 3cats-in-a-coat 3y ago
    My comment is in response to this in the parent comment: > I do prefer the "do one thing and do it well" approach.
deleted 3y ago
[deleted]
bborud 3y ago
Why do you think it is a strength that git is "not bundling the kitchen sink"? I'd like to understand better why other people prefer kitchen sink vs multiple binaries. I am in two minds when it comes to this. A lot of (server) software I write bundles server, client and tools in the same binary. I also embed the API documentation, the OpenAPI files, the documentation and sometimes related documentation in the binary so that it can be served on an endpoint on the server or extracted. So you have one binary, statically linked whenever possible, that contains everything you will need. And where everything is the same release as everything else, so there are no chances you'll end up with different versions of client, server, documentation, tooling etc. The binary size doesn't concern me. I could easily increase the binary size tenfold, and it still wouldn't be a problem for the software I write. I don't think binary size is a big concern today since so much software "splats" files all over your system anyway (which I think is a horrific way to do things), so footprints tend to be somewhat large anyway. What occasionally does concern me is that this might be confusing to the user. But it is possible to make things confusing for the user even if a piece of software is more focused (ie does "one thing"). One example is CLI utilities that have multiple screenfuls of `--help` output. To me, that's poor usability. Users end up resizing terminal windows, scrolling back and forth (when you deal with related options) and perhaps even resorting to grep or less to find what you are looking for. I try to mitigate this by always structuring CLI applications with commands and subcommands. Where you can do --help at each level. Quite a few CLI applications do this and I think it helps. This summer I wrote the first piece of software in perhaps half a decade that has separate binaries for the client and the server. Because I want to share the client code, but not the server code. While the split was unrelated to usability, I've started asking myself if this presents a better user experience. I haven't really been able to conclude.
Shorel 3y ago
> I do prefer the "do one thing and do it well" approach. I prefer the "do what you do well" approach. If it's one thing, or many things, doesn't matter, as long as it's both efficient and correct. I mean, if Fossil fails at some of these things, then we can criticise it for its failings, but it appears it actually does the things correctly. The comparison with GitLab is quite enlightening. Fossil is a few MB, and Git + GitLab (to be feature equivalent) is a few GB and requires far more resources. Then which one does what it does well? Now, there are a few things I don't like from Fossil, like the lack of a cherry-pick command. I have no intention of using Fossil over Git. I am just stating that criticism should be based on actual misfeatures and not on development "philosophies".
- SQLite 3y ago
  Use whatever VCS you like, but do please note that Fossil does have a "cherry-pick" command. See https://fossil-scm.org/home/help?cmd=cherry-pick https://fossil-scm.org/home/help?cmd=cherry-pick for the documentation. Earlier in it's history, Fossil didn't have a separate cherry-pick command, but rather just a --cherrypick option to the "merge" command. See https://fossil-scm.org/home/help?cmd=merge https://fossil-scm.org/home/help?cmd=merge. Perhaps that is where you got the idea that Fossil did not cherry-pick. Fossil has always been able to cherry-pick. Furthermore, Fossil actually keeps track of cherry-picks. Git does not - there is no space in the Git file format to track cherry-picks merges. As a result, Fossil is able to show cherry-picks on the timeline graph. It shows cherry-pick merges as dashed lines, as opposed to solid lines for regular merges. For example the "branch-3.42" branch (https://sqlite.org/src/timeline?r=branch-3.42 https://sqlite.org/src/timeline?r=branch-3.42) consists of nothing but cherry-picks of bug fixes that have been checked into trunk since the 3.42.0 release.
- deleted 3y ago
  [deleted]

queuebert 3y ago

From an ABI perspective, there's not a huge difference, mostly just where the code resides on disk, all local or scattered across multiple inodes.

panzi 3y ago
I think the point is that there is the option to have only git, which reduces the attack surface of only that tool, if you don't want/need anything else.

Dylan16807 3y ago

My git seems to be mostly a single binary, and it's larger than fossil.

jayski 3y ago

I think SQLite is fantastic and Richard is obviously a genius. But I always found his obsession with single binary monoliths odd. As you mentioned it goes against the Unix philosophy of do one thing and do it well. To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently.

bane 3y ago
I have no idea why Richard focuses on such things but: I'm old enough to remember when developers spent time making sure they could plow all of their build assets into a single binary distributable. It often had kind of a zest to it and when you dealt with software had directories full of stuff it looked both "corporate" and "sloppy". I've never quite gotten over the feeling that the piles of dynamically linked libraries hasn't helped things. I know objectively that there's a notion that you can update libraries instead of applications, but it feels like it makes updating applications fragile and you inevitably end up in some kind of dependency hell. "But breaking insecure applications is a feature!" I mean, okay, I guess. But I still need something to work and don't want to spend all day fixing broken layers of dependent stuff. If I have to do that, I may as well just update a single binary. Go seems to have come back around to this style of thinking, and in a sense container images and JAR files are often trying to replicate what it's like to just download a binary, chmod +x it, and execute it.
- osigurdson 3y ago
  Well, it’s either a single executable in a container or a bunch of dlls/sos in a container.
- beebmam 3y ago
  If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.
  - jjnoakes 3y ago
    It depends. Sometimes you have no choice but to deploy to an old machine with back-leveled tls libraries, and static linking can save the day. Of course that tends to be the exception (hopefully).
  - andersa 3y ago
    The situation on windows is fascinating: everyone links these libraries dynamically, and yet, there are about two hundred of them on my system, every application using its own uniquely outdated version.
  - kibwen 3y ago
    On a closed-source system, sure. On a system where you have the source, you have the option to rebuild your binaries.
  - bborud 3y ago
    In my practical experience the set of things that can go wrong if you link apps dynamically is much larger than the problems that arise when they are statically linked. For one, it is more complicate to keep track of which of the many shared libraries on a typical system are used by which application. It is common that the same library occurs multiple times in different versions, built by different people/organizations and residing in different directories. Quick, without looking: which TLS library do your network exposed subsystems use, which directories are they in and where did you install them from. When you do go to look: did you find what you expected? Have a look at all the other shared libraries on your system. Do you know which binaries use them? Do you know which versions of which libraries work with which binaries? Do you trust the information your package manager has about version requirements? Does it even have that information? Then there's the problem of what happens when you upgrade. The servers you run might have a rigorous battery of tests. But now you are running them with libraries they were not tested against. Sure, most of the time it'll work. But you don't know that. And you have no way of knowing that without downloading, building and running the tests. Or have someone else do that. I've been in the situation where someone inadvertently updated a library in production and everything came crashing down. Not only did it take down the site, but it took a while to figure out what happened. Both because the person who did it wasn't aware of what they'd done. And the problem didn't manifest itself in a way that made the root cause obvious. The clearest risk with statically linked binaries is if they are not updated when there is, for instance a security problem. But in practice I find that easier to deal with since I know what I'm running, and for anything important, I'm usually aware of what version it is or when I last checked for updates/problems.
forrestthewoods 3y ago
I’m so thankful that Rust is helping popularize the solo exe that “just works”. I don’t care if a program uses DLLs or not. But my rule is “ship your fucking dependencies”. Python is the worst offender at making it god damned impossible to build and run a fucking program. I swear Docker and friends only exist because merely executing a modern program is so complicated and fragile it requires a full system image.
- docandrew 3y ago
  Wish I had more upvotes for this sentiment.
- bombela 3y ago
  The only way I know to manage python dependencies is Bazel as the build system, and implementing a custom set of rules that download and build all python dependencies. The download is done in a git repo. All magically missing libs must be added to the repo and Bazel. And finally you might have a way to... tar the output into a docker container... sigh
- ogurechny 3y ago
  The choice is actually between dealing with complexity and shifting responsibility for that to someone else. The tools themselves (e.g. virtual environments) can be used for both. Either people responsible for packaging (authors, distribution maintainers, etc.) have some vague or precise understanding of how their code is used, on which systems, what are its dependencies (not mere names and versions, but functional blocks and their relative importance), when they might not be available, and which releases break which compatibility options, or they say “it builds for me with default settings, everything else is not my problem”.
  - josephg 3y ago
    > Either people responsible for packaging have some vague or precise understanding of how their code is used, on which systems, what are its dependencies But with python it’s a total mess. I’ve been using automatic1111 lately to generate stable diffusion images. The tool maintains multiple multi-hundred line script files for each OS which try to guess the correct version of all the dependencies to download and install. What a mess! And why is the job of figuring out the right version of pytorch the job of an end user program? I don’t know if PyTorch is uniquely bad at this, but all this work is the job of a package manager with well designed packages. It should be as easy as “cargo run” to run the program, no matter how many or how few dependencies there are. No matter what operating system I’m using. Even npm does a better job of this than python.
lolinder 3y ago
Slight tangent: it bugs me when people say "it goes against the Unix philosophy" as though The Unix Philosophy were some kind of religious text. Not everything should be a pluggable Unix executable, and Fossil making non-Unixy choices doesn't reflect poorly on it. They just chose a different philosophy.
eesmith 3y ago
> it goes against the Unix philosophy of do one thing and do it well For me, Perl shows just how restricted that viewpoint was. After I learned Perl, I stopped caring about tr, and sed, and many of the other "one thing well" command-line tools. And I've no desire to swap out and modify the 's//' component of perl. Perl does "one thing" - interpret Perl programs - even though it also replaces many things. I know 'rmdir' exists. It does one thing, well - remove an empty directory. It's been around since the first release of Unix. However, I use "rm -rf" because it's easier to use a more powerful tool which handles empty directory removal as a special case. You can also change your viewpoint and say that Fossil does do one thing well: it's a distributed project control system. That's a new category I just made up, to highlight just how subjective "one thing" is.
- herewulf 3y ago
  I like `rmdir` because I don't have to check if a directory that I think is empty is actually empty with `ls -la` before removing it. This happens a lot with moving stuff out of directories (sometimes to different destinations).
  - eesmith 3y ago
    Even in that case, you can use "rm -d" instead of "rmdir". % mkdir herewulf % rm herewulf rm: herewulf: is a directory % rm -d herewulf % % mkdir herewulf % touch herewulf/nonempty.txt % % rm herewulf/ rm: herewulf/: is a directory % rm -d herewulf/ rm: herewulf/: Directory not empty % rm herewulf/nonempty.txt % rm -d herewulf/ The only distinct feature of rmdir is that it won't remove things that aren't files: % touch herewulf % rm -d herewulf % touch herewulf % rmdir herewulf rmdir: herewulf: Not a directory Is that "one thing well" really enough to justify its own tool? Unix has always had a tension between "one thing well" and "one powerful tool". Is 'cc' a preprocessor? A compiler? A linker? Yes! Does 'date' show the current date (and time), set the system date, or convert between dates? Yes!
    - cesarb 3y ago
      > Is 'cc' a preprocessor? A compiler? A linker? Yes! It's none of them; it's a driver which calls the preprocessor (cpp), the real compiler, and the linker (ld).
kaba0 3y ago
Unix’s philosophy is more of what you’d call ‘guidelines’, and is not universally applicable — not all problems can be decomposed nicely, and IPC just gives you a badly debuggable hodgepodge of added accidental complexity. It’s good for trivial tools like ls, cat, etc, but something more complex is likely better off as a monolith.
usrusr 3y ago
Exceptional things rarely happen without some outlier conviction involved. Most things happening due to outlier convictions are just that, follies that lead nowhere. But when the stars align and there's both great ability involved and a genuine gap to fill that would have remained undiscovered workout the outlier conviction, something like SQLite happens.
alpaca128 3y ago
> To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. But where do you draw the line? What's "one thing"? - The size and complexity between cli tools doing one thing varies by orders of magnitude, some of those programs are much larger than this Fossil "monolith". Should a component have more functionality if separation means 10 times slower performance? What if it has hundreds of such features? What if separating those features means a hundredfold increase in complexity for setting up the software as it now has distributed dependencies? Should you have a separate audio player when a video player could already do the job out of necessity? Should a terminal support scrolling if you can already get that via tmux? The Unix philosophy is bad for judging individual programs.
flohofwoe 3y ago
The UNIX philosophy of minimal cmdline tools that do one thing right is fine and the Go-style 'monolithic exe' without runtime dependencies except the OS is also fine (and both philosophies actually don't need to collide). The problem is all the software that depends on tons of dependencies that are brought in dynamically. Just look at Jekyll vs Hugo. I have Jekyll break regularly when something (seemingly) unrelated changes on my machine, but Hugo is just rock solid. Or another much more annoying example: Linux executables linking with glibc and then not running on systems that don't have that particular version of glibc installed.
bborud 3y ago
I think the "Unix philosophy" is best applied to problems that indeed can be de-composed into clear discrete steps. In fact, that's the metric I use when I write command line utilities: does this make sense in a pipe? There are a lot of things where this isn't very practical. For instance, imagine building a web server that consists of a couple of dozen discrete utilities that are then cobbled together using pipes. Or even implementing the core feature set of Git in this manner. Would it be practical? Would it be better if Git was an enormous shellscript that connected all of these "things" into an application? What does that give you? And what would be the cost? How would you do SQLite (the CLI application) as a bunch of discrete commands?
sgbeal 3y ago
> As you mentioned it goes against the Unix philosophy of do one thing and do it well. To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. Anecdote: when i first met Richard in 2011, after having contributed to Fossil since 2008, i asked him why he chose to implement fossil as a monolithic app instead of as a library. His answer was, "because I wanted it working next week instead of next month." It was a matter of expedience and rewriting it now would be a major undertaking for little benefit. Reimplementing fossil as a library is a years-long undertaking (literally) and is not something we're interested in doing directly within the Fossil project, but is something i maintain as a semi-third-party effort, along with a handful of other Fossil contributors, over at <https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil>.
IshKebab 3y ago
The Unix philosophy was a very rough guideline from the 70s, not a divine commandment that must be followed unwaveringly. There are a gazillion examples of excellent pieces of software that don't do "one thing" that can be piped as unstructured text into another program. Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`. Laughable. But how many people decry Excel for "not more than one thing"? You probably haven't even considered it. I'd put it up there with "premature optimisation" as one of the most damaging programming mantras.
- tzs 3y ago
  > Imagine editing a spreadsheet like `cat foo.xls | select-cell B3 | replace '=B2+1' > foo.xls`. It would be even more cumbersome than that. After that command you'd have to restore foo.xls from a backup, and then do the edit again this time remembering that the "> foo.xls" executes before the pipe executes. :-) I wonder if anyone has written something to make pipes like that work? E.g., write two programs, "replace" and "with" that could be used like this: replace foo.xls | ... | with foo.xls What "replace [file]" would do is set a write lock on the file, copy the file to stdout, then release the lock. What "with [file]" would do is copy stdin to the file, after obtaining a write lock on the file. I think most shells would start the components of a pipe in order so "replace" should be able to set its lock before "with" tries to get a lock, but to be safe "with" could be written to buffer incoming data and only start checking the lock after it has received a significant amount or seen an EOF on stdin. Or "replace" and "with" could coordinate using some out-of-band method.
  - Sprocklem 3y ago
    `sponge` from moreutils more or less does this.
naasking 3y ago
> To me it's obviously cleaner to divide a system into components that can later be swapped or modified independently. Why is "cleaner" the only thing that matters? Why not "functional/featureful"? It's open source so it can be modified, but I'm not sure why ability to swap matters.

maxxk 3y ago

> git, for all its issues, is not bundling the kitchen sink. It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal. While you can download Fossil as a 3.3 MB standalone binary for any supported platform.

op00to 3y ago
I don’t develop on a machine where this matters, even at scale. Who cares about a 47MB difference on machines with a few gigs of ram?
- deleted 3y ago
  [deleted]
- nickpsecurity 3y ago
  I used to try to make tools fit in cache, esp L1, because they'd load and run a lot faster. Lightening fast! Try that to see if it still works on the newer machines.
- abwizz 3y ago
  for scale you usally want things to be efficient. and caring about caching effects is not seldomly the lowest hanging fruit.
hot_gril 3y ago
I remember people installing git-bash and putty for Windows in computer science class to fill in all the gaps. Idk what the deal was with that cause, uh, why would I use Windows.
willdr 3y ago
But on a developer machine this doesn't matter does it?
- NikkiA 3y ago
  Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32 it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent.

devin 3y ago

the more important takeaway imho is that the tooling doesn't really matter, but i hear you.

dmvdoug 3y ago
Outsider here. One thing that I have observed about programmers is how obsessed they are with tooling. Whether it’s exactly which model of ergonomic keyboard or exactly which toolchain(s) they’re using, there seems to be an endless desire or eagerness to shoot the shit over tooling.

forrestthewoods 3y ago

> and do it well If only Git did it well! Ok that’s not fair. Git is pretty okay for the Linux open source project. But it’s pretty mediocre-to-bad for everything else. The D is DVCS is a waste of effort. Almost all projects are defacto centralized. In fact the D is anti-pattern that makes things like large binary files a still unsolved problem in Git. And no Git LFS doesn’t count. Source control should be capable for petabyte scale storage and terabyte scale partial clones, imho. Git feels like an inferior technology that succeeded and now we’re mostly stuck with it. Maybe someday someone will create a proper Perforce competitor and we can all migrate to something that’s actually good.

hprotagonist 3y ago
> The D is DVCS is a waste of effort. until the de facto centralized remote goes offline and you’re stuck with no local history …
- LordShredda 3y ago
  Not an issue, if remote goes down you can always restore from backup
  - hprotagonist 3y ago
    having been the guy who did that: i assure you, doing it is An Issue.
    - KerrAvon 3y ago
      I was once responsible for doing this with a Perforce server. Only time in my career a VCS has lost data. This was decades ago now and the data loss might have been due to hardware; I cannot definitively blame Perforce, but man was it shitty to deal with at the time. We migrated to Subversion and never had another issue.
      - hprotagonist 3y ago

zaps 3y ago

> git, for all its issues, is not bundling the kitchen sink In my experience, installing git on most Linux distros pulls in a bunch of perl dependencies

qbasic_forever 3y ago
Git includes a web interface written as a perl CGI script, so yeah it has a lot more dependencies than people realize. It is most certainly not just a simple single binary to plop on a machine and call it good.

qbasic_forever 3y ago

Git actually is bundling a lot of stuff you probably don't realize. Run 'git instaweb' for example and it will spin up a local CGI server and perl CGI script to give a very simple web UI: https://git-scm.com/docs/git-instaweb https://git-scm.com/docs/git-instaweb Fossil isn't much different in core functionality here. There is a ton of email client integration and functionality in git too that most people who only use GitHub probably have absolutely no idea exists or even why it's there. Stuff like sending email patches right from git: https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email

thayne 3y ago
FWIW, that isn't actually part of the core git binary. Because unlike fossil, git is a collection of executables, not just one.
- qbasic_forever 3y ago
  Yes, which is why git is a pain in the butt to install and you have to rely on your OS packages (which includes all the kitchen sink stuff) or a GUI installer with all the necessary dependencies vs. Fossil which is just download executable and done.
  - westurner 3y ago
    Securing the software supply chain for software updaters and VCS systems means PKI and/or key distribution, cryptographic hashes and signatures, file manifests with per-archive-file checksums, and DAC extended filesystem attributes for installed files; Ironically, there's more to it than just `curl`'ing a binary into place and not remembering to update it. And that is why package managers.
    - westurner 3y ago
      And sigstore; for centralized software artifact (package,) hashes: https://sigstore.dev/ https://sigstore.dev/

velcrovan 3y ago

And yet, because git does not bundle those things, which actually do belong as part of a modern SCMS, people lock themselves into GitHub or Gitlab, which provide those missing pieces.

pyeri 3y ago

The "do one thing and do it well" approach died the day when systemd became a super hit.

3cats-in-a-coat 3y ago

The concept that you can isolate "one thing" and it's not in itself "a set of other things" is a very nasty myth in the world of programming. Everything is composite. Everything is a pipeline of commands. Made of things. The "job to do" is in the eye of the beholder, not absolute. The "single responsibility principle" is not applicable in reality. It's always a tradeoff of maintaining a balance of cohesion and modularity. Where we make a cut and call it a "thing" is up to us and our needs. For many people, for example, the tools of GitHub are so integral to their workflow, they can't use Git alone at all. So to them GitHub is the "one thing". So SQLite has their own "thing".

hinkley 3y ago
I'm not sure where I stand in this whole argument, but > The "job to do" is in the eye of the beholder, not absolute. It's definitely the case that the less sophisticated the user, the more requirements they can pack into a sentence.
IshKebab 3y ago
They're not saying it doesn't encapsulate more than one thing. They're saying *at the abstraction level of "stuff you need to install and run" it is one thing.
- 3cats-in-a-coat 3y ago
  My comment is in response to this in the parent comment: > I do prefer the "do one thing and do it well" approach.

deleted 3y ago

[deleted]

bborud 3y ago

Why do you think it is a strength that git is "not bundling the kitchen sink"? I'd like to understand better why other people prefer kitchen sink vs multiple binaries. I am in two minds when it comes to this. A lot of (server) software I write bundles server, client and tools in the same binary. I also embed the API documentation, the OpenAPI files, the documentation and sometimes related documentation in the binary so that it can be served on an endpoint on the server or extracted. So you have one binary, statically linked whenever possible, that contains everything you will need. And where everything is the same release as everything else, so there are no chances you'll end up with different versions of client, server, documentation, tooling etc. The binary size doesn't concern me. I could easily increase the binary size tenfold, and it still wouldn't be a problem for the software I write. I don't think binary size is a big concern today since so much software "splats" files all over your system anyway (which I think is a horrific way to do things), so footprints tend to be somewhat large anyway. What occasionally does concern me is that this might be confusing to the user. But it is possible to make things confusing for the user even if a piece of software is more focused (ie does "one thing"). One example is CLI utilities that have multiple screenfuls of `--help` output. To me, that's poor usability. Users end up resizing terminal windows, scrolling back and forth (when you deal with related options) and perhaps even resorting to grep or less to find what you are looking for. I try to mitigate this by always structuring CLI applications with commands and subcommands. Where you can do --help at each level. Quite a few CLI applications do this and I think it helps. This summer I wrote the first piece of software in perhaps half a decade that has separate binaries for the client and the server. Because I want to share the client code, but not the server code. While the split was unrelated to usability, I've started asking myself if this presents a better user experience. I haven't really been able to conclude.

Shorel 3y ago

> I do prefer the "do one thing and do it well" approach. I prefer the "do what you do well" approach. If it's one thing, or many things, doesn't matter, as long as it's both efficient and correct. I mean, if Fossil fails at some of these things, then we can criticise it for its failings, but it appears it actually does the things correctly. The comparison with GitLab is quite enlightening. Fossil is a few MB, and Git + GitLab (to be feature equivalent) is a few GB and requires far more resources. Then which one does what it does well? Now, there are a few things I don't like from Fossil, like the lack of a cherry-pick command. I have no intention of using Fossil over Git. I am just stating that criticism should be based on actual misfeatures and not on development "philosophies".

SQLite 3y ago
Use whatever VCS you like, but do please note that Fossil does have a "cherry-pick" command. See https://fossil-scm.org/home/help?cmd=cherry-pick https://fossil-scm.org/home/help?cmd=cherry-pick for the documentation. Earlier in it's history, Fossil didn't have a separate cherry-pick command, but rather just a --cherrypick option to the "merge" command. See https://fossil-scm.org/home/help?cmd=merge https://fossil-scm.org/home/help?cmd=merge. Perhaps that is where you got the idea that Fossil did not cherry-pick. Fossil has always been able to cherry-pick. Furthermore, Fossil actually keeps track of cherry-picks. Git does not - there is no space in the Git file format to track cherry-picks merges. As a result, Fossil is able to show cherry-picks on the timeline graph. It shows cherry-pick merges as dashed lines, as opposed to solid lines for regular merges. For example the "branch-3.42" branch (https://sqlite.org/src/timeline?r=branch-3.42 https://sqlite.org/src/timeline?r=branch-3.42) consists of nothing but cherry-picks of bug fixes that have been checked into trunk since the 3.42.0 release.
deleted 3y ago
[deleted]