Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SQLite does not use Git (2018)

sqlite.org

Post reply on HN
Print view View original

71–80 of 454 posts

Re: Why SQLite does not use Git (2018)

#71

Post by bane »

no_wizard wrote: post #56
bane wrote: post #41

Earlier quoted context omitted.

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 libra…

Monolithic builds are great if you have no control over the deployed environment (IE desktop apps sans OS supplied libs). They’re worse if you do control the environment and how the upgrade paths get followed

Doesn't it seem that more and more people are just given access to some managed environment they have little control over anyway?

I feel like sometimes the dependency on dynamically linked stuff is akin to "well transistor radios are great if you don't care about soldering on fresh vacuum tubes like a real radio person would."

Re: Why SQLite does not use Git (2018)

#72

Post by bombela »

forrestthewoods wrote: post #53
jayski wrote: post #37

Earlier quoted context omitted.

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.

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.

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

Re: Why SQLite does not use Git (2018)

#73

Post by whateveracct »

somenewaccount1 wrote: post #59

>Git focuses on individual branches, because that is exactly what you want for a highly-distributed bazaar-style project such as Linux. Linus Torvalds does not want to see every check-in by every contributor to Linux: such extreme visibility does not scale well. Contrast Fossil, which was written for the cathedral-style SQLite project and its handful of active committers Ugh...so after all that fanfare of how amazing…

"Scaling well" isn't table stakes. it's a tradeoff.

Re: Why SQLite does not use Git (2018)

#74

Post by jjnoakes »

beebmam wrote: post #55
bane wrote: post #41

Earlier quoted context omitted.

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 libra…

If you're using TLS/crypto in an app, it's scary to statically bundle those libraries.

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).

Re: Why SQLite does not use Git (2018)

#76

Post by [deleted] »

op00to wrote: post #47
maxxk wrote: post #42

Earlier quoted context omitted.

> 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.

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]

Re: Why SQLite does not use Git (2018)

#77

Post by mbfg »

i guess you use what you have, and don't use what you don't have, but i don't really know when i've ever thought let me see what happened after that branch was merged into future.

I do have a simple script that will list what branches were merged into the current branch in git. That is useful, so being built in, in Fossil is useful i guess.

My gripe with Fossil, is not technical, it is really just who uses it? How much support does it get. When will it wither and die? Maybe that is an invalid concern on my part. But that is way more important to me than any technical issues raised here.

Re: Why SQLite does not use Git (2018)

#78

Post by willdr »

maxxk wrote: post #42
ohthatsnotright wrote: post #21

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 require…

> 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.

But on a developer machine this doesn't matter does it?

Re: Why SQLite does not use Git (2018)

#79

Post by colordrops »

bane wrote: post #41
jayski wrote: post #37

Earlier quoted context omitted.

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.

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 libra…

You'd love NixOS. Gives you the flexibility of dynamic libraries with the isolation and full dependency bundling per app and less janky than snap or flatpak.

Re: Why SQLite does not use Git (2018)

#80

Post by mbfg »

qaq wrote: post #18
BuckRogers wrote: post #8

I’m sure git is less than ideal. I pretty much just know enough to do what I need to do with it. The only reason I want to use it is because it is the industry standard tool. Otherwise Hg, Perforce, have all had pretty compelling arguments put forward for their use. There’s so much technical churn in this industry, that any time I can use something that’s widely embraced I’m actually happy for that. Regardless of my…

I'd choose git over perforce any day.

doesn't perforce only allow one branch per repo? Or is that something they addressed.
Post reply on HN