Threads for emilengler

  1. 2

    It is exactly what curl does, with the argument, that git may not be the last VCS and that this would make a migration easier.

    1. 7

      This really isn’t what curl does at all.

      1. 3

        Thanks. I have understood my misinformation.

        1. 5

          It would be fun if this was what curl does :)

      2. 3

        This is something else.

        Today I’m taking this one step further, and I’m introducing a new concept: extremely linear git history.

        With our extremely linear history, the first commit in a repo hash a hash that starts with 0000000, the second commit is 0000001, the third is 0000002, and so on!

      1. 2

        Is there any larger FOSS projects that is currently using Fossile for their version control? I’m curious to see how this works for external contributors.

        1. 5

          The obvious FOSS project using Fossil is SQLite. And Fossil itself. :-)

          1. 4

            TCL/TK uses Fossil too.

            1. 4

              Perhaps not “larger,” but Retro Forth uses Fossil.

              1. 2

                I’ve been happy with Fossil, but my workflow has me as a gatekeeper. I accept patches (and/or modified source files directly), review, revise if necessary, and then merge them. At this point I’m the only one with access to push changes to the primary repository.

            1. 4

              The best design choice I can say about Fossil is using SQLite. The Git data structure is much more complicated and magic-like compared to a good-old database with SQL. Fossil is not integrated with almost any tool, but the design choice is something more software architects need to learn.

              1. 1

                The table schemas and whatnot might be simpler than the git object store (though, the git object store isn’t very complicated), but SQLite is very much not simple. Not its query engine, not its on-disk format - they’re all quite complicated, more so than Git.

                (Git does not include a bytecode engine, SQLite does.)

                1. 3

                  But SQLite is a standardized, well-known, well-documented and well-tested tool, that has been widely deployed and is even recommended by the US Library of Congress for long-term storage. git(5) is reinventing the wheel here IMO.

                  1. 3

                    Exactly. It all comes down to the interface. SQLite and Fossil can be used with a little simple SQL. What about Git? You will need to have a degree on that or search everything you need.

              1. 8

                As a satisfied git user, this seems fair. The tldr is: fossil uses substantially the same data structure as git but makes completely opposite choices because it’s optimized for smaller development teams.

                I’d love to hear from someone who has used both extensively and prefers fossil. What’s it like? What’s lost that git users rely on? What huge wins does fossil open up?

                1. 8

                  I actually go so far as to just use Fossil for most of my websites. The wiki in markdown mode works great for my sites.

                  What’s lost that git users rely on?

                  The big thing is, git allows mutability, in fact all of git is basically a big fungible ball of mud. Fossil is much more immutable. If you think your VCS should allow mutable history, Git is for you. If you think your commits are immutable history, you should take a serious look at Fossil. I’m not sure there is a “right” answer here, it just depends on your perspective. Personally I’m an immutable person, that does mean you get the occasional commit message that looks like: ‘oops, fix typo’. But you can be fairly confident Fossil’s history is what actually happened and not a cleaned up version of reality.

                  1. 11

                    For what it’s worth, the commit graph in git is immutable. The only thing mutable are the references. What’s different is that in git you can move the references however you please, with no restrictions to move them along the edges of the commit graph.

                    In fossil, you can only converge the timelines. In git, you can jump between them.

                    1. 7

                      A big realization for me was that the git graph itself is versioned in the reflog. Using git reflog to restore old references is hugely valuable and I’m way more confident using git because of it. But to be fair, those commits are only stored on my local machine, will eventually be gc-ed and won’t be pushed to a remote. Fossil would track them everywhere.

                    2. 6

                      Could you elaborate a bit on the value of immutability to you? I fall into the mutability camp because I find the additional context is rarely worth the value when it costs so much to untangle. I’d rather use the mutability to create untangled context and have that be the only artifact that remains. I’m not disagreeing that the immutability has value to you, I’m just seeking understanding since I experience things differently.

                      1. 5

                        I generally have two diametrically opposed views on immutability:

                        • In other people’s repos, I want immutability with no exceptions. If I clone your repo, nothing you do should be able to modify the history that I think I have, so I can always find a common ancestor between your version and my fork and merge back or pull in new changes.
                        • In my own repo, I want the flexibility to change whatever I want, commit WIP things, move fixes back to the commit that introduced the bug, and so on.

                        I think GitHub’s branch protection rules are a good way of reconciling this. The main branch enforces immutable history, as do release branches. Ideally tags would also be immutable. Anything else is the wild west: if you work from those branches then don’t expect them to still exist upstream next time you pull and you may need to resolve conflicts later. I’d like a UI that made this distinction a lot more visible.

                        1. 2

                          This is definitely a reasonable perspective.

                          Question, what is the point of committing WIP stuff?

                          1. 3

                            Locally, so that I have an undo button that works across files, so once something is working and I want to clean it up, I can always see what I’ve changed and broken during cleanup.

                            Publicly, so that I can get feedback (from humans or CI), incorporate it, and then clean up the result so that, when it’s merged, everything in the history is expected to be working. This means that other people can bisect to find things that broke and not have to work out if a particular version is expectedly or unexpectedly broken. It also means that people merging don’t see conflicts in places where I made a change in a file, discovered I didn’t need it, reverted it, and they did a real change in that location.

                            1. 1

                              Thanks!

                              For me and us @ $WORK, the undo button is either ZFS snapshots(exposed as ~/.snapshots) or $EDITOR’s undo functionality.

                              For human feedback, we have a shared user machine we work from or we use other more general purpose tools, like desktop screen sharing(typically tmux, or guacamole).

                              For CI feedback, since our CI/CD jobs are just nomad batch jobs, it’s just a nomad run project-dev.nomad command away.

                              I.e. we prefer general tools we have to use anyway to solve these problems, instead of specific tools.

                              1. 3

                                For me and us @ $WORK, the undo button is either ZFS snapshots(exposed as ~/.snapshots) or $EDITOR’s undo functionality.

                                That requires me to either:

                                • Have a per-source-tree ZFS dataset (possible with delegated administration, but a change from just having one for my home directory and one for my builds which doesn’t get backed up and has sync turned off)
                                • Tracking metadata externally about which of my snapshots corresponds to a checkpoint of which repo.

                                In contrast, git already does this via a mechanism that is the same one that I use for other things. Vim has persistent undo, which is great for individual files, but when a change spans a dozen files then trying to use vim’s undo to go back to (and compare against) the state from the middle of yesterday afternoon that worked is hard.

                                For human feedback, we have a shared user machine we work from or we use other more general purpose tools, like desktop screen sharing(typically tmux, or guacamole).

                                That requires everyone that you collaborate with to be in the same company as you (or introduces some exciting security problems for your admin team to have to care about), for your code review to be synchronous. The first is not true for me, the second would be problematic given that I work with people distributed across many time zones. Again, GitHub’s code review doesn’t have those problems.

                                For CI feedback, since our CI/CD jobs are just nomad batch jobs, it’s just a nomad run project-dev.nomad command away.

                                That’s fine if everyone running your CI has deploy permissions on all of the infrastructure where you do testing.

                                I.e. we prefer general tools we have to use anyway to solve these problems, instead of specific tools.

                                The tools that you use have a lot of constraints that would prevent me from using them in most of the places where I use git.

                                1. 1

                                  Around CI/CD. For local testing with nomad it can be as simple as download the nomad binary then nomad agent -dev then nomad run <blah.nomad> and you can be off to the races, running CI locally.

                                  We don’t do that, because @ $WORK, our developers are all in-house and it’s a non-issue, to share resources.

                                  Just to be clear, I’m not trying to convert you, just for those following along at home.

                                  Also, within Fossil’s commits, you can totally hide stuff from the timeline, similar to git rebase, using amend

                                  1. 1

                                    Thanks for the exchange! It’s interesting seeing the different trade-offs on workflow.

                                    For those following along, another way, totally within fossil to do undo across large amounts of code change is just generate a sqlite patch file instead of a commit. it’s easy enough: fossil patch create <blah.patch> and to undo: fossil patch apply <blah.patch> The patch file will include by default all uncommitted changes in the repo.

                                2. 1

                                  an undo button that works across files, so once something is working and I want to clean it up, I can always see what I’ve changed and broken during cleanup.

                                  The staging area is underappreciated for this problem. Often when I hit a minor milestone (the tests pass!) I’ll toss everything into staged and then try to make it pretty in unstaged. With a good git UI it’s easy to look at the unstaged hunks in isolation and blow them away if I mess up. Good code gets promoted to the staging area and eventually I get a clean commit.

                                  …and then I end up with lots of messy commits anyway to accommodate the “humans or CI” cases. :)

                                3. 1

                                  In short, for backing it up or for pushing out multiple commits to create a design sketch.

                                  1. 1

                                    The Fossil “Rebase Considered Harmful” document provides a lot of reasons for committing WIP: bisect works better, cherry-picks work better, backouts work better. Read the doc for more: https://www2.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

                                    Rebase is a hack to work around a weakness in git that doesn’t exist in fossil.

                                    The Git documentation acknowledges this fact (in so many words) and justifies it by saying “rebasing makes for a cleaner history.” I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a “clean” history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.

                                    So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn’t it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary?

                                4. 5

                                  Sometimes it’s policy/law. When software starts mucking about with physical things that can kill/maim/demolish lives, stuff has to be kept track of. Think airplane fly by wire systems, etc. Fossil is good for these sorts of things, git could be with lots of policy around using it. Some industries would never allow a git rebase, for any reason.

                                  • The perspective of Fossil is: Think before you commit. It’s called a commit for a reason.
                                  • The perspective of Git is, commit every nanosecond and maybe fix the history later.

                                  Of course history being immutable can be annoying sometimes, but history is messy in every version of history you look at, except perhaps kindergarten level history books :P I’m not a kindergartener anymore, I can handle the real history.

                                  For me at $WORK, it’s policy.

                                  1. 6

                                    Ah, a policy reason certainly makes sense. I work in FinTech, where policy and/or law has not quite caught up to software to burden us with a more deeply ingrained moral responsibility to assure accountability of the software we write.

                                    • The perspective of Fossil is: Think before you commit. It’s called a commit for a reason.
                                    • The perspective of Git is, commit every nanosecond and maybe fix the history later.

                                    Of course history being immutable can be annoying sometimes, but history is messy in every version of history you look at, except perhaps kindergarten level history books :P I’m not a kindergartener anymore, I can handle the real history.

                                    This is condescending. Human beings make mistakes and storing those mistakes in all cases isn’t always a valuable artifact. Imagine a text editor that disallows text deletions. “You should have thought harder before typing it.” Come on, dude.

                                    1. 7

                                      Imagine a text editor that disallows text deletions.

                                      We call that Blockchain Notepad.

                                      1. 4

                                        Thanks, I hate it!

                                      2. 3

                                        I had a :P in there :)

                                        I apologize, but come on, it’s not like your comparison is remotely fair either :)

                                        Human beings make mistakes and storing those mistakes in all cases isn’t always a valuable artifact.

                                        I agree. Fossil(and git) both have ways to fix mistakes that are worth cleaning up. Git just has more of them. See “2.7 What you should have done vs. What you actually did” in the OP’s link.

                                        1. 1

                                          One thing I’m seeing about fossil that illuminates things a bit is that it looks like it might be possible to limit what sets of changes you see as a product of querying the change sets. This seems useful - not to reproduce something git-like - but to limit only to the changes that are considered more valuable and final than anything more transient. If that’s the case, I can see the “mess” of fossil being less of a problem, though with the added cost of now needing to be comfortable with querying the changes.

                                      3. 5

                                        I’d much rather have cleaned up history than try to bisect around half-finished commits.

                                        1. 3

                                          From a Fossil perspective, half finished commits belong locally or in .patch files to move around(which in Fossil land are sqlite3 files, not diffs). They don’t belong in commits.

                                          To be clear I agree with you, bisecting half-finished commits are terrible. Fossil just has a different perspective and workflow than Git when it comes to this stuff.

                                          1. 2

                                            I imagine that the way this would get handled in fossil land is people making local half commits then redrafting the changes cleanly on another branch and using that as the official commits to release

                                          2. 3

                                            There’s a series of steps that any change takes as it passes through decreasingly mutable tiers of storage, so to speak:

                                            • typing moves things from the programmer’s brain to an editor buffer
                                            • saving moves things from an editor buffer to a file
                                            • committing moves things from a file to a (local) repo’s history
                                            • pushing moves things from a local repo to a (possibly) public one

                                            The question is at what level a given change becomes “permanent”. With git it’s really only when you’ve published your history, whereas it sounds like fossil’s approach doesn’t really allow the distinction between the last two and hence that happens on every (local) commit.

                                            You could move the point-of-no-undo even earlier and install editor hooks to auto-commit on every save, or save and commit on every keystroke, but I think most people would agree that that would produce an unintelligible useless mess of history, even if it is “a more accurate record of reality” – so even in the fossil approach you’re still looking at a somewhat massaged, curated view of the development history. I think git’s model just makes that curation easier, by allowing you to create “draft” commits and modify them later.

                                            1. 2

                                              Fossil’s perspective would be, once it’s committed it is immutable, but you can do reporting on it and make it spit out whatever you want. i.e. Fossil really is just a fancy UI and some tooling around a SQLite database. There is basically no end to what one can do when your entire code tree is living in a SQL database.

                                              i.e. You don’t change the history, you change the report of history to show the version of reality that is interesting to you today.

                                              Fossil even includes an API for it: https://www2.fossil-scm.org/home/doc/trunk/www/json-api/api-query.md Not to mention the built-in querying available for instance in the timeline view

                                            2. 3

                                              While I disagree with conclusion, I appreciate you taking the time to explain this way of looking at it. The legality angle seems reasonable, (and, ofc, if you have no choice, you have no choice) but digging further I have some questions for you….

                                              1. By this line of reasoning, why is the fossil commit the unit of “real history”? Why not every keystroke? I am not just being facetious. Indeed, why not screen record every editing session?
                                              2. Given that the fossil commit has been deemed the unit of history, doesn’t this just encourage everyone to big-batch their commits? Indeed, perhaps even use some other mechanism to save ephemeral work while I spend hours, or even days, waiting for my “official work” to be done so that I can create clean history?

                                              I’m not a kindergartener anymore, I can handle the real history.

                                              This strikes me an almost Orwellian reversal, since I would say: “You (coworker) are not a kindergartner anymore. Don’t make me read your 50 garbage commits like ‘checkin’, ‘try it out’, ‘go back’, etc, when the amount of changes you have merits 3 clean commits. Have the basic professionalism to spend 5-10 minutes to organize and communicate clearly the work you have actually done to your current and future coworkers.” I am no more interested in this “true history” than I am interested in the 5 intermediate drafts of the email memo you just sent out.

                                              1. 2

                                                Don’t make me read your 50 garbage commits …

                                                It sounds like we are no longer discussing Fossil, but a way of using Git where you do not use rebase.

                                                Here’s what the Fossil document says:

                                                Git puts a lot of emphasis on maintaining a “clean” check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. Branches may be rebased before being pushed to make it appear as if development had been linear, or “squashed” to make it appear that multiple commits were made as a single commit. There are other history rewriting mechanisms in Git as well. Git strives to record what the development of a project should have looked like had there been no mistakes.

                                                Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project “messy,” but another point of view is that this makes the history “accurate.” In actual practice, the superior reporting tools available in Fossil mean that this incidental mess is not a factor.

                                                Like Git, Fossil has an amend command for modifying prior commits, but unlike in Git, this works not by replacing data in the repository, but by adding a correction record to the repository that affects how later Fossil operations present the corrected data. The old information is still there in the repository, it is just overridden from the amendment point forward.

                                                My reading is that Fossil permits you to view a “clean” history of changes due to its “superior reporting tools” and the “correction records” added by the amend command. But unlike Git, the original commit history is still recorded if you need to see it.

                                                1. 1

                                                  My reading is that Fossil permits you to view a “clean” history of changes due to its “superior reporting tools” and the “correction records” added by the amend command. But unlike Git, the original commit history is still recorded if you need to see it.

                                                  Ok that is interesting… I had been assuming that they were dismissing the value of clean history, but it seems they are not, but instead solving the same problem but at a different level in the stack.

                                                2. 1

                                                  By this line of reasoning, why is the fossil commit the unit of “real history”? Why not every keystroke? I am not just being facetious. Indeed, why not screen record every editing session?

                                                  That’s what Teleport is for. Other tools obviously also do this.

                                                  More generally, stuff in the commit tree will eventually make it to production and run against real data and possibly hurt people. The stuff that can hurt people needs to be tracked. The ephemeral stuff in between doesn’t much matter. If I was purposefully negligent in my code, no amount of ephemeral work would prove it, there would be some other mechanism in place to prove that (my emails to a co-conspirator maybe, recording me with that evil spy, etc).

                                                  Given that the fossil commit has been deemed the unit of history, doesn’t this just encourage everyone to big-batch their commits? Indeed, perhaps even use some other mechanism to save ephemeral work while I spend hours, or even days, waiting for my “official work” to be done so that I can create clean history?

                                                  Why do you need to commit ephemeral work? what is the point?

                                                  Have the basic professionalism to spend 5-10 minutes to organize and communicate clearly the work you have actually done to your current and future coworkers.”

                                                  LOL fair point :) But that goes back to the previous comments, what is the purpose of committing ephemeral work? From my perspective there are 2 general reasons:

                                                  • Show some pointy haired boss you did something today
                                                  • Share some code in progress with another person to help solve a problem, code review, etc.

                                                  The 1st, no amount of code commits will solve this, it’s either trust me or come sit next to me and watch me do stuff(or screen record, video record my office, etc). If my boss doesn’t trust me to be useful to the organization, I’m at the wrong organization.

                                                  The 2nd, is easily solved in a myriad of ways, from desktop/screen sharing, to code collab tools to sharing Fossil patch files around.

                                                  I truly don’t understand the point of committing half-done work like Git proponents seem to think is an amazing idea. A commit needs to be USEFUL to be committed. Perhaps it’s part of a larger body of work, it’s very common to do that, but then it’s not ephemeral, you are doing a cleanup so you can then implement $FEATURE, that cleanup can happily be it’s own commit, etc.

                                                  But committing every nanosecond or on every save is just idiotic from my point of view. If you want that sort of thing, just run against a versioned file system. You can do this with ZFS snapshots if you don’t want to run a versioned file system. Git is not a good backup tool.

                                                  1. 4

                                                    I think this is fundamentally a workflow difference.

                                                    Proponents of git, myself included, use committing for many purposes, including these prominent ones:

                                                    1. A way to save partially complete work so you don’t lose it, or can go back to that point of time in the midst of experimentation.
                                                    2. A way to share something with a co-worker that will not be part of permanent history or ever merged.

                                                    The 2nd, is easily solved in a myriad of ways, from desktop/screen sharing, to code collab tools to sharing Fossil patch files around.

                                                    Yes, I suppose there are other ways to solve the sharing problem. But since we do everything in git anyway and will have a PR in Github anyway, it is very convenient to just commit to share, rather than introduce a new mechanism for sharing.

                                                    I truly don’t understand the point of committing half-done work like Git proponents seem to think is an amazing idea. A commit needs to be USEFUL to be committed.

                                                    Sharing code to discuss and backing up milestones of incomplete, experimental are both very useful to me.

                                                    1. 1

                                                      I think the disconnect is probably in what we consider “ephemeral.” You seem to think that we’re “idiotically [. . .] committing every nanosecond” (which, seriously, stop phrasing it like this because you’re being an asshole), but in most of my own use cases it’s simply a matter of wanting to preserve the current state of my work until I’ve reached a point where I’m ready to construct what I view as a salient description of the changes. In many cases this means making commits that roughly match the structure I’m after - a sort of design sketch - and maybe these don’t include all of the test changes yet, and I haven’t fully written out a commit message because I haven’t uncovered all the wrinkles that need ironing as I continue the refactor, and I find something later that makes more sense as a commit in the middle because it relates directly to that other block of work, and and and…

                                                      An example: when I reach the end of the day, I may want to stash what I’m working on or - depending on the amount of work I’ve put in - I may want to push up a WIP commit so that if something happens on my workstation that I don’t lose that work (this is always a real concern for reasons I won’t go into). Maybe that WIP commit doesn’t have tests passing in it, and I and my team try to follow the practice of ensuring that every commit makes a green build, so I don’t want that to be the final version of the commit that eventually makes it into the main branch. The next day I come in, reset my WIP commit and add the test changes I was missing and now make the actual commit I want to eventually see pushed up to the main branch.

                                                      I don’t know of anybody who thinks saving things in WIPs for untangling later is - as you say - “an amazing idea,” but it’s a natural extension of our existing workflow.

                                            3. 6

                                              I use both Fossil and Git at work, although we are almost done with moving all the Fossil repos to Git.

                                              Fossil is fine, but the immutability is kind of annoying in the long term. The lack of a rebase for local work is a drag.

                                              Its biggest problem is tooling. Nothing works with it. It doesn’t integrate with the CI system without a lot of effort, there’s no Bitbucket/Github-like system to use for PRs or code reviews, and it doesn’t integrate with the ticket system. Sure, it contains all those things, but they don’t meet the needs we (and most others, it seems) require.

                                              On a personal note, I dislike the clone/open workflow as I’d much rather have the database in the project directory similar to the .git directory. There are other little things I don’t like, but they are mostly because I’m used to Git, despite all its flaws.

                                              1. 3

                                                I would argue it’s because your perspective around Fossil is wrong when it comes to immutability. Fossil’s perspective is when you commit, it’s literally a commitment, it’s done. Be careful and think about your commits. Practically the only thing we have noticed is occasionally we get ‘oops fixed typo’ type commits.

                                                I agree with the clone/open workflow, but it’s that way for a reason, the perspective is, you clone locally once, and you open per branch/feature you want to mess with. So a cd is all you need to switch between branches. Once I figured that out, I didn’t mind the workflow that much, I just have a ~/fossil dir that keeps all my local open projects, and otherwise I mostly ignore that directory.

                                                I agree with the tooling problem, though I don’t think it’s quite as bad as you think. There is fossil patch for PR/code review workflows. The only special tooling fossil gives you here is the ability to copy and apply the patch to a remote SSH host. Perhaps that could be changed, but it allows you to develop your own workflow if you care about those sorts of things.

                                                I have a totally different perspective than the entire industry around CI/CD. CI/CD is just a specialization of running batch jobs. Since we have to run batch jobs anyway, we just use our existing batch job tooling for CI/CD. For us, that means our CI/CD integration is as simple as a commit hook that runs: nomad run <reponame.nomad> After that our normal nomad tooling handles all of our CI/CD needs, and allows anyone to start a CI/CD run, since it’s all in the repo, there is no magic or special tooling for people to learn. If you have to learn how production works anyway for batch jobs there is no sense in learning a diff. system too.

                                                1. 2

                                                  It’s not just about perspective. I’m firmly in the mutable history camp, because a lot of my work - the vast majority of it, really - is experimenting and research. It’s all about coming up with ideas, sharing them, seeking feedback, and iterating. Most of those will get thrown out the window after a quick proof of concept. I see no point in having those proof of concepts be part of the history. Nor will I spend considerable time and effort documenting, writing tests and whatnot for what is a proof of concept that will get thrown out and rewritten either way, just to make the history usable. I’d rather just rearrange it once the particular branch is being finalised.

                                                  Immutable history is great when you can afford it, but a huge hindrance when you can’t.

                                                  With git, both can be accomplished with a little care: no force pushes to any branch. Done.

                                                  What one does locally is irrelevant. Even with Fossil, you will likely have had local variations before you ended up comitting it. The difference with git is that you can make local snapshots and rearrange them later, using the same tool. With Fossil, you would have to find some other way to store draft work which is not ready to become part of the immutable history.

                                                  I mean, there’ve been many cases over my career where I was working on a thing that became a single commit in the end, for days, sometimes even weeks. I had cases where that single commit was a single line changed, not a huge amalgamation or anything like that. But it took a lot of iteration to get there. With git, I could commit my drafts, share it with others, and then rewrite it before submitting it upstream. I made use of that history a lot. I rolled back, reverted, partially reverted, looked at things I tried before, and so on. With Fossil, I would have had to find a way to do all that, without comitting the drafts to the immutable history. It would have made no sense to commit them - they weren’t ready. Yet, I still wanted to iterate, I still wanted to easily share with colleagues.

                                                  1. 3

                                                    Clearly you and I are going to disagree, but I would argue that Fossil can handle your use-case just fine, albeit very differently than Git would handle it. You have clearly gotten very use to the Git workflow model, and that’s fine. That doesn’t mean the Fossil workflow model is wrong or bad or evil or anything, it’s just different than Git’s, because (I’d argue) it’s coming from a different perspective.

                                                    Fossil does have ways to store draft work and ship it around, I mentioned two ways in the comment you are replying to, but you either didn’t see them or just chose to ignore them. fossil patch is actually pretty cool, as the patch file is just a sqlite3 file. Easy to ship/move/play with.

                                                    1. 2

                                                      I wasn’t saying the Fossil model is bad - it isn’t. It’s just not suitable for every scenario, and I have yet to see what benefit it would have over the mutable model for me. Just because it can handle the scenarios I want doesn’t mean it’s easy, convenient or straightforward to do it. Git can do immutable workflows too, and mutable ones too - it just makes the latter a lot easier, while the former possible if you put in the work.

                                                      I did not see your comments about fossil patch before, I skipped over that part of your comment, sorry. However, that’s not suitable for my workflow: I don’t need a single patch, I can ferry one around easily, that wouldn’t be a problem. I work with branches, their history important, because I go often go back and revert (fully or partially), I often look back at things I tried before. That is important history during drafting, but completely irrelevant otherwise. Git lets me do dirty things temporarily, and share the refined result. Fossil lets me ferry uncomitted changes around, but that’s so very far from having a branch history. I could build something on it, sure. But git already ships with that feature out of the box, so why would I?

                                                      I could, of course, fork the repo, and do my draft commits in the fork, and once it reaches a stage where it’s ready to be upstreamed, I can rebuild it on top of the main repo - manually? Or does Fossil have something to help me with that?

                                                      I’m sure it works in a lot of scenarios, where the desire to commit often & refine is less common than think hard & write only when it’s already refined. It sounds terrible for quick prototyping or proof of concepts (which are a huge part of my work) within an existing project.

                                                      1. 2

                                                        Fossil really is just a fancy UI and some tooling around a SQLite database. There is basically no end to what one can do when your entire code tree is living in a SQL database. You don’t need 100k confusing git commands, when you literally can type sqlite3 <blah.fossil> and do literally anything you want. If fossil will understand it for you after is of course an exercise left to the SQL writer. :)

                                                        That is important history during drafting, but completely irrelevant otherwise.

                                                        Fossil has a different perspective here. All history is important.

                                                        I think the big difference here is, Fossil’s UI and query tools are vastly more functional than Git’s. Literally an entire SQL implementation. Meaning you can hide/ignore loads of stuff from the history, so that in practice most of this ‘irrelevant history’ can be hidden from view the vast majority of the time.

                                                        I could, of course, fork the repo, and do my draft commits in the fork, and once it reaches a stage where it’s ready to be upstreamed, I can rebuild it on top of the main repo - manually? Or does Fossil have something to help me with that?

                                                        Yes, see: https://www2.fossil-scm.org/home/doc/trunk/www/branching.wiki

                                                        No need to fork, a branch should work just fine.

                                                        1. 2

                                                          Fossil really is just a fancy UI and some tooling around a SQLite database.

                                                          Similarly, git is just an UI over an object store. You can go and muck with the files themselves, there are libraries that help you do that. If git will understand it for you after, is an exercise left for whoever mucks in the internals. ;)

                                                          Fossil has a different perspective here. All history is important.

                                                          And that is my major gripe. I do not believe that all history is important.

                                                          Meaning you can hide/ignore loads of stuff from the history, so that in practice most of this ‘irrelevant history’ can be hidden from view the vast majority of the time.

                                                          It still takes up space, and it still takes effort to even figure out what to ignore. With git, it’s easy: it simply isn’t there.

                                                          No need to fork, a branch should work just fine.

                                                          According to the document, a branch is just a named, intentional fork. From what I can tell, the history of the branch is still immutable, so if I want to submit it upstream, I would still need to manually rebuild it first. Fossil maintains a single DAG for the entire repo (so the linked doc says), so if I wanted to clean things up before I submit it upstream, I’d need to rebuild by hand. With git, I can rebase and rewrite history to clean it up.

                                                          1. 2

                                                            I do not believe that all history is important.

                                                            Seconded.

                                                            We do not have to remember everything we do.

                                                      2. 1

                                                        Can you explain a little bit more how things like code reviews work? I’m not skeptical that they can’t be done in fossil, it’s just that the workflow is so different from what I’m used to.

                                                        1. 2

                                                          I am by no means a Fossil expert, but I’ll give you my perspective. Fossil handles moving the code back and forth, the rest is up to you.

                                                          I work on a new feature and am ready to commit, but I want Tootie to look it over(code review). If we have a shared machine somewhere with SSH and fossil on it, I can use fossil patch push server:/path/to/checkout and push my patch to some copy for her to look at. If not I can fossil patch create <feature.patch> and then send her the .patch file(which is just a sqlite3 DB file) via any method.

                                                          She does her review and we talk about it, either in Fossil Forums or Chat, or email, irc, xmpp, whatever. Or she can hack on the code directly and send a new .patch file back to me to play with.

                                                          Whenever we agree it’s good to go, either one of us can commit it(assuming we both have commit rights). See the fossil patch docs.

                                                2. 1

                                                  What do you mean of “the same data structure as git”, you know Fossil is using SQLite? I don’t know what the current Git data structure is, but from my experience with it, it is much more complicated to do something with compared to a SQL database.

                                                  1. 2

                                                    From the link under heading 2.3:

                                                    The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage a directed acyclic graph (DAG) of Merkle tree structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via the parent’s hash.

                                                    1. 1

                                                      A merkle tree of commits containing the file contents.

                                                    2. 1

                                                      I’ve been using Fossil for my personal projects since summer 2020.

                                                      The main advantages I see compared to git is that it is fairly easy to backup/move to a new server (the repository is just a single SQLite database and not a folder of a custom key/value format), as well as to give other contributors commit access (no shell access required).

                                                      Beside this, I’m also more inclined to their philosophy of being immutable, as I would otherwise spent way too much time making my commits looks nice.

                                                      1. 9

                                                        I think there’s a reason why languages like PHP once were created, despite having such a capable language as C/C++ widely available.

                                                        It goes something like:

                                                        You can write a fast program in C, but in perl/python/php you can write a program fast

                                                        1. 4

                                                          I don’t completely disagree, but I think there’s also other reasons for PHP picking up. For example it providing the 90s version of serverless, and no compilation being required.

                                                          On top of that the fact that approaches to get closer to natural languages (in one way or another) as well as text processing were big goals, also easy interfacing with databases in the standard library.

                                                          Times change, we see trends in the opposite direction. Ambiguity and expressiveness over simplicity are not the goal anymore, and people want things to look familiar, trading writing a few more understood constructs for simplicity. People prefer being explicit instead of implicit.

                                                          An example of that is also how there’s a trend away from duck typing. Once that was a good thing, because it’s closer to natural language and less writing, and just like with natural language you were able to be shorter when many things are implied.

                                                          Then we had a rise of Java style languages and now the interesting new languages are the ones copying much of the philosophy that people associate with C.

                                                          Not saying people should use C or BCHS, but that a language isn’t bad because people follow different trends, learn other languages in school or similar. Popular languages tend to keep evolving and the ecosystems maturing.

                                                          Of course that also means legacy as in “failed attempts”, old interfaces (see Go getting new network address types), unmaintained libraries, etc. accumulating and I have to admit the lack of these is really exciting about new languages. There’s usually also just less bad, ugly, buggy, unidiomatic code on very new languages.

                                                          However, times have changed and given that there isn’t much too similar to BCHS, also because both the world and the technologies it depends on were at least different I think the existence of PHP doesn’t seem like a good argument against BCHS.

                                                          Again, not saying you should use it or that PHP worse or better. Just that such general rules usually aren’t the best helpers for practical decisions.

                                                        2. 5

                                                          C is a straightforward, non-mustachioed language.

                                                          So much to unpack here.

                                                          1. 1

                                                            It has full access to the kernel’s system calls and a massive set of development tools and libraries.

                                                            I don’t think C the programming language has anything to do with syscalls. Which ones you have access to instead depending on which ones your standard library decides to implement wrappers for, same as many other languages. Granted on BSD this is likely most of them, but certainly isn’t guaranteed.

                                                            1. 1

                                                              I think you might have replied to this comment in error.

                                                              1. 1

                                                                Let’s pretend I replied one level up, or that I was also unpacking that section of the website. :)

                                                                1. 1

                                                                  Sorry, I missed that you were referring to content on the same site. The phrase “non-mustachioed” was a thought terminator.

                                                                  I think the entire site is meant to be read as satire. “The internet is unsafe” - granted, but recommending C in that case is not best practices.

                                                                  httpd(8): OpenBSD’s home-grown web server. If you need more features for your web application, submit a patch.

                                                                  OK then.

                                                                  It’s not as if you can’t use a sane language like Perl on OpenBSD, it’s included in base for building.

                                                        1. 6

                                                          if you program and want any longevity to your work, make a game. all else recycles, but people rewrite architectures to keep games alive.

                                                          – Why The Lucky Stiff

                                                          1. 7

                                                            git-checkout(1) is truly a very misleading command due to its various possible meanings (same with C static keyword). I hope these commands could make the situation better but I think it might be a lost race as git-checkout is already very established in the workflow of many users.

                                                            1. 5

                                                              I hope these commands could make the situation better but I think it might be a lost race as git-checkout is already very established in the workflow of many users.

                                                              I think framing this as a “race” is kind of a false dichotomy; these commands can improve the ergonomics for people who find checkout confusing. I won’t be switching, but that’s because checkout’s behaviour has always felt intuitive to me, which is why it’s firmly established in my workflow.

                                                              The new commands broaden the friendliness of git, they’re not “losing” just because I personally have no need to take them up. It’s not one or the other.

                                                              1. 4

                                                                The goal is definitely GNU-free, but yea, it still depends on gmake to build some packages. It’s the only GNU dependency, too. A gmake replacement would finish the job.

                                                                1. 4

                                                                  Seems that you would have to replace freetype as well.

                                                                  Curious to read a little bit more about the rationale though. What’s so wrong about GNU software?

                                                                  1. 20

                                                                    I think one advantage is that GNU has had something of a “monopoly” in a few areas, which hasn’t really improved the general state of things. The classic example of this is gcc; everyone had been complaining about its cryptic error messages for years and nothing was done. Clang enters the scene and lo an behold, suddenly it all could be improved.

                                                                    Some more diversity isn’t a bad thing; generally speaking I don’t think most GNU projects are of especially high quality, just “good enough” to replace Unix anno 1984 for their “free operating system”. There is very little innovation or new stuff.

                                                                    Personally I wouldn’t go so far so make a “GNU free Linux”, but in almost every case where a mature alternative to a GNU project exists, the alternative almost always is clearly the better choice. Sometimes these better alternatives have existed for years or decades, yet for some reason there’s a lot of inertia to get some of these GNU things replaced, and some effort to show “hey, X is actually a lot better than GNU X” isn’t a bad thing.

                                                                    1. 8

                                                                      A LOT of people have soured on GNU/FSF as a result of the politics around RMS and the positions he holds.

                                                                      1. 3

                                                                        A lot of people were soured on them long before that; the whole GPL3 debacle set a lot of bad blood, the entire Open Source movement was pretty much because people had soured on Stallman and the FSF, the relentless pedantry on al sorts of issues, etc. Of course, even more people soured on them after this, but it was just the last in a long line of souring incidents.

                                                                        Was (re)watching some old episodes of The Thick of It yesterday; this classic Tucker quote pretty much sums up my feelings: “You are a fucking omnishambles, that’s what you are. You’re like that coffee machine, from bean to cup, you fuck up.”

                                                                        1. 1

                                                                          For sure. Never seen The Thick Of It but I love Britcoms and it’s on my list :)

                                                                          I’ve always leaned towards more permissive licenses. We techies love to act as if money isn’t a thing and that striving to make a living off our software is a filthy dirty thing that only uncool people do.

                                                                          And, I mean, I get it! I would love NOTHING more than to reach a point in my life where I can forget about the almighty $ once and for all and hack on whatever I want whenever I want for as long as I want! :)

                                                                      2. 4

                                                                        Yeah, when I hear “GNU” I think cruft. And this is from someone who uses emacs! (I guess you could argue it’s the exception that proves the rule, since the best thing about emacs is the third-party ecosystem).

                                                                        And this is only about GNU as an organization, to be clear. I have no particular opinions on the GPL as a license.

                                                                        1. 2

                                                                          Even Emacs is, unfortunately, being hampered by GNU and Stallman, like how Stallman flat-out refused to make gcc print more detailed AST info for use in Emacs “because it might be abused by evil capitalists”, and the repeated drama over the years surrounding MELPA over various very small issues (or sometimes: non-issues).

                                                                          1. 2

                                                                            Yeah, it’s really unfortunate :/

                                                                      3. 12

                                                                        From the site:

                                                                        Why
                                                                        • Improve portability of open source software
                                                                        • Reduce requirements on GNU packages
                                                                        • Prove the “It’s not Linux it’s GNU/Linux …” copypasta wrong
                                                                        1. 2

                                                                          Why not? (I’m not affiliated with the project, you’d have to ask the people maintaining it)

                                                                          1. 6

                                                                            Yeah, “why not?” is a valid reason imvho. I would like to know which one it theirs in actuality. I often find that the rationale behind a project is a good way to learn things.

                                                                            And fair enough, I assumed you were affiliated. FWIW, Freetype is not a GNU project, but it is indeed fetched from savannah in their repos, which I found slightly funny.

                                                                            ETA: it also seems to be a big endeavor so the rationale becomes even more interesting to me.

                                                                            1. 1

                                                                              My rationale was partially to learn things, partially for the memez and partially as an opportunity to do things the way I want (all these people arguing about init systems, iglunix barely has one and I don’t really need anything more). I wanted to do Linux from scratch to learn more about Linux but failed at that and somehow this ended up being easier for me. I think I definitely learnt more trying to work out what was needed for myself rather than blindly following LFS.

                                                                          2. 1

                                                                            There is nothing inherently wrong with gnu software; I just like to have choice.

                                                                            1. 1

                                                                              Freetype is available under its own permissive license.

                                                                              1. 1

                                                                                That’s correct! I downloaded https://download-mirror.savannah.gnu.org/releases/freetype/freetype-2.11.0.tar.xz just to double check, and here is the license:

                                                                                FREETYPE LICENSES
                                                                                -----------------
                                                                                
                                                                                The FreeType  2 font  engine is  copyrighted work  and cannot  be used
                                                                                legally without  a software  license.  In order  to make  this project
                                                                                usable to  a vast majority of  developers, we distribute it  under two
                                                                                mutually exclusive open-source licenses.
                                                                                
                                                                                This means that *you* must choose  *one* of the two licenses described
                                                                                below, then obey all its terms and conditions when using FreeType 2 in
                                                                                any of your projects or products.
                                                                                
                                                                                  - The FreeType License,  found in the file  `docs/FTL.TXT`, which is
                                                                                    similar to the  original BSD license *with*  an advertising clause
                                                                                    that forces  you to explicitly  cite the FreeType project  in your
                                                                                    product's  documentation.  All  details are  in the  license file.
                                                                                    This license is suited to products which don't use the GNU General
                                                                                    Public License.
                                                                                
                                                                                    Note that  this license  is compatible to  the GNU  General Public
                                                                                    License version 3, but not version 2.
                                                                                
                                                                                  - The   GNU   General   Public   License   version   2,   found   in
                                                                                    `docs/GPLv2.TXT`  (any  later  version  can  be  used  also),  for
                                                                                    programs  which  already  use  the  GPL.  Note  that  the  FTL  is
                                                                                    incompatible with GPLv2 due to its advertisement clause.
                                                                                
                                                                                The contributed  BDF and PCF  drivers come  with a license  similar to
                                                                                that  of the  X Window  System.   It is  compatible to  the above  two
                                                                                licenses (see files `src/bdf/README`  and `src/pcf/README`).  The same
                                                                                holds   for   the   source    code   files   `src/base/fthash.c`   and
                                                                                `include/freetype/internal/fthash.h`; they wer part  of the BDF driver
                                                                                in earlier FreeType versions.
                                                                                
                                                                                The gzip  module uses the  zlib license (see  `src/gzip/zlib.h`) which
                                                                                too is compatible to the above two licenses.
                                                                                
                                                                                The  MD5 checksum  support  (only used  for  debugging in  development
                                                                                builds) is in the public domain.
                                                                                
                                                                                --- end of LICENSE.TXT ---
                                                                                
                                                                            2. 4

                                                                              Why would anyone want to write a GNU make replacement when GNU make exists?

                                                                              1. 3

                                                                                Having it under a more permissive license is a very valid reason though. Guess why FreeBSD is writing their own git implementation…

                                                                                If the only tool for a task is closed-source then there is a project trying to make an open-source one. If the only open-source tool for a task is under a copyleft license then there is a project trying to make a non-copyleft one. Once a project is BSD, MIT or public domain we can finally stop rewriting it.

                                                                                1. 2

                                                                                  If avoiding copyleft is the goal then the Linux kernel is a weird choice. And important parts of the FreeBSD kernel (zfs) are under a copyleft license too (CDDL).

                                                                                  1. 1

                                                                                    I find OpenBSD to be one of the best choices as far as license goes. I’ve been slowly moving all my Debian machines to OpenBSD in the past year (not only because of the license, but because it’s an awesome OS).

                                                                                    1. 1

                                                                                      I haven’t tried using OpenBSD in earnest since are around 1998. I prefer a copyleft to a BSD style license personally but maybe I’ll take another look. And I hear that tar xzf blah.tar.gz might even work these days.

                                                                                      1. 1

                                                                                        It gets improved with every new major release, I’ve used it consistently for the past 3 or 4 releases and there’s always noticeable improvement in performance, user-land tools, drivers, arch support, etc. I’d definitely give it a try again!

                                                                                  2. 1

                                                                                    This is fine reasoning but relativized. After all, I could just as easily say that if the only tool for a task is under a non-copyleft license, then there is a project trying to make a GNU/FSF version; once GNU has a version of a utility, we can stop rewriting it.

                                                                                  3. 2

                                                                                    They don’t want to do that. They want a non-GNU replacement for GNU make

                                                                                    1. 1

                                                                                      They could just fork GNU make. That would work right?

                                                                                      1. 4

                                                                                        Or use bsdmake.

                                                                                        1. 2

                                                                                          bsdmake is in fact included, but it can’t build all gmake makefiles unfortunately.

                                                                                          1. 3

                                                                                            I used to do a fair bit of packaging on FreeBSD, and avoiding things like GNU make, autotools, libtool, bash, etc. will be hard and a lot of effort. You’ll essentially have to rewrite a lot of project’s build systems.

                                                                                            Also GTK is GNU, and that’ll just outright exclude whole swaths of software, although it’s really just “GNU in name only” as far as I know.

                                                                                          2. 1

                                                                                            No bmake isn’t enough to build the Linux kernel

                                                                                          3. 1

                                                                                            Depends on their goals. Some people don’t like GNU or GPL projects. If that’s the case then probably not.

                                                                                            1. 4

                                                                                              If they don’t like GPL projects then using the Linux kernel is a weird choice.

                                                                                            2. 1

                                                                                              The entire point here is to not contain any GNU code, so no.

                                                                                              1. 5

                                                                                                zlib is derived from GNU code (gzip) so anything that includes zlib or libpng etc will “contain GNU code”. This includes for example the Linux kernel.

                                                                                                1. 6

                                                                                                  He didn’t say they’ve achieved their goal. It’s still a goal.

                                                                                                  Why does it seem like you’re trying to “gotcha” on any detail you can refute?

                                                                                                  It’s just someone’s project.

                                                                                                  1. 3

                                                                                                    I’m trying to understand the goal. If the goal is avoiding software that originated from the GNU project that is probably futile. The GNU project has been a huge, positive influence on software in general.

                                                                                                    1. 5

                                                                                                      You know the goal. They stated it. The parent comment to you stated it again.

                                                                                                      It might be futile, but luckily we don’t control other peoples free time and hobbies, so they get to try if they want. You seem to be taking personal offense at the goal.

                                                                                          4. 1

                                                                                            For fun

                                                                                        2. 3

                                                                                          From the site:

                                                                                          Iglunix is a Linux distribution but, unlike almost all other Linux distributions, it has no GNU software¹

                                                                                          ¹With the exception of GNU make for now

                                                                                          1. 1

                                                                                            Yes I still haven’t been able to replace a couple projets. For self hosting gnu make is all that’s left, for chromium bison (and by extension gnu m4) and gperf are all that’s left.

                                                                                          1. 4

                                                                                            I wonder if somebody gona implement sqlite as an optional storage backend for Git’s ref and commit-graph. It would be interesting to see a benchmark against the current WIP reftable format.

                                                                                            1. 10

                                                                                              Somewhat related: SQLite itself uses the Fossil-SCM instead of Git which uses an SQLite DB to store its data.

                                                                                              1. 3

                                                                                                Yeah I have heard of Fossil but unfortunately its not that common as Git.

                                                                                                Here is the context for what im suggesting for those who might be interested https://gitlab.com/gitlab-org/git/-/issues/6#note_501523892. Refs in Git are managed either in many files or concat into a single file plain text.

                                                                                                It would be very interesting if somebody try using SQLite for it. I think most of the ground works are being done with the reftable format introduction that would help the tests in git.git to stop accessing the refs files directly and use API instead.

                                                                                                1. 2

                                                                                                  I totally agree with you. The git storage format is only barely documented and not even standardized. This makes it really hard for alternative git implementations like got(1), git9(1) or OpenGIT to get going. An SQLite DB would offer standardization to at least some degree.

                                                                                                  Yeah I have heard of Fossil but unfortunately its not that common as Git.

                                                                                                  Fossil is not competing against Git though but goes hand in hand with it. This is especially notable that there is no limit on the amount of imports and exports you can do between Fossil and Git.

                                                                                            1. 4

                                                                                              Why use C89 in 2021? That’s a 32 year old standard. We have C17 now.

                                                                                              1. 9

                                                                                                Especially with C89 you have a huge variety of compilers available allowing you to run your code on nearly every architecture as well as checking your code for maximum standard compliance (some compilers are more liberal than others).

                                                                                                With any C standard that is >= C99 you are effectively forced using clang or gcc.

                                                                                                1. 4

                                                                                                  Can you give an example of an architecture that is only supported by a C89 compiler?

                                                                                                  1. 3

                                                                                                    MS VisualC++ only began to add C99 support in Visual Studio 2013, and I’m not sure they support anything newer. So you’re no longer limited to C89 for Windows code these days, but there’s a long tradition of “keep your expectations very low if you want to write C and be portable to the most popular desktop OS”.

                                                                                                    1. 3

                                                                                                      According to this blog post they were working on C11 and C17 support last year. I don’t know how far they are with things they listed as missing.

                                                                                                2. 4

                                                                                                  Later versions of the C standard are a lot less portable and a lot more complex. I use C89 when I want to write software that I know will be portable across many different machines and will work with nearly any C compiler. IMO, it doesn’t really make sense to target anything later than C11; C17 doesn’t make enough notable and useful changes to warrant using it.

                                                                                                  1. 1

                                                                                                    Some old code bases, especially in the embedded space, are still written for it.

                                                                                                  1. 2

                                                                                                    In the SiteDefinition there is find_video_direct_url() function. Is it a good abstraction, generic and flexible enough? What if some site requires composing the video from several pieces or does some other kind of streaming? Some sites may also require specific User-Agent headers or some cookies.

                                                                                                    Maybe the SiteDefinition could return an input stream of bytes or get an output stream of bytes as a parameter and write to it.

                                                                                                    BTW: I like your Code of Merit.

                                                                                                    1. 1

                                                                                                      I am not the author though

                                                                                                      1. 1

                                                                                                        You are right, downloading from several parts is not supported yet, resulting in a lack of support for (e.g.) YouTube playlists. I outlined a draft to fix this in issue #1 and I hope that someone helps me to make it. :-) Thank you for the suggestion.

                                                                                                      1. 3

                                                                                                        strlcpy is identical to the sprintf invocation from before, except it uses the correct size_t return type. This still means it fails to satisfy the performance requirements of 3 and 4

                                                                                                        This isn’t true. I don’t know why this person thinks strlcpy is implemented in terms of snorintf, but of course it isn’t; that would be silly. I haven’t seen the implementation, but I have no reason to assume its performance is less than the optimized code at the start.

                                                                                                          1. 1

                                                                                                            What interface works best depends on your use. Are you reallocating the destination buffer if it is too small? Are you concatenating a lot of strings? Are you scanning a buffer copying out substrings?

                                                                                                            Performing a strlen like this one can be dangerous because people might end up with accidentally quadratic code.

                                                                                                            1. 2

                                                                                                              Totally fair point! However even for such simple but critical functions I prefer to use a bullet-proofen implementation which strlcpy(3) and strlcat(3) are.

                                                                                                        1. 2

                                                                                                          I’m generally an enjoyer of the SQLite ecosystem and it’s always interesting how they come up with their own solutions cause other ones weren’t fitting: CVSTrac, Fossil-SCM, Lemon and apparently Althttpd which all look really neat in my opinion.

                                                                                                          1. 10

                                                                                                            Nice, super easy/quick upgrade from 6.8 using sysupgrade.

                                                                                                            1. 4

                                                                                                              Upgraded my server too. This time there sure wasn’t any manual work.

                                                                                                              After sysupgrade, there was nothing to sysmerge, so I just pkg_add -u’d and rebooted again.

                                                                                                              1. 5

                                                                                                                While talking about pkg_add -u, it received a major boost in performance!

                                                                                                            1. 6

                                                                                                              I hope this might lead to a relicensing of Plan9 to a more liberal license than GPL. Many forks already did that maybe a newer license could bring back some unity

                                                                                                              1. 29
                                                                                                                1. 7

                                                                                                                  Why would that matter? Linux is under the GPL and it seems to do just fine. In fact, for an operating system it feels like the GPL might be the best option to prevent fragmentation and incompatibility.

                                                                                                                  1. 12

                                                                                                                    The problem is that several Plan 9 forks license their contributions under a different license so up until now there’s no unity and that kinda sucks to check which part of the code is under which license

                                                                                                                    1. 2

                                                                                                                      Oh, gotcha, that’s unfortunate!

                                                                                                                  2. 3

                                                                                                                    I don’t think that would help anything: folks who refuse to contribute their changes to the rest of the community (as required by the GPL) are unlikely to contribute those changes to the rest of the community when no longer so required.

                                                                                                                    Sure, things like the BSDs exist, but their ecosystem is far, far smaller than the GNU ecosystem.

                                                                                                                    1. 3

                                                                                                                      That would be an issue for a usual open source project. The status of the plan 9 and its forks is: there are forks, with the plural ‘s’. Allow me to rephrase your statement: folks who refuse others’ changes are unlikely to accept those changes no matter what license they use.

                                                                                                                  1. 2

                                                                                                                    Interesting design decision to avoid any heap allocation, even at the cost of performance.

                                                                                                                    Thinking about performance, I started to idly wonder just how much of the work could be done at compile time, if you had a better meta programming framework than C macros.

                                                                                                                    1. 4

                                                                                                                      The costs appear much greater than performance. It looks like providing an invalid regex results in memory corruption: https://github.com/kokke/tiny-regex-c/issues/30

                                                                                                                      1. 3

                                                                                                                        Yeah, when I saw this library I considered all the potential bugs possible when implementing something as fiddly as regexes in a language as unsafe as C; then I backed slowly away.

                                                                                                                        1. 1

                                                                                                                          I mean, just because it’s in C doesn’t mean it’s untrustworthy. GNU Grep is written in C (over 3K lines, not including external helpers) and seems to work pretty well.

                                                                                                                        2. 1

                                                                                                                          That issue was closed as “fixed” a year ago, about 6 months after it was opened. The code now passes analysis by KLEE.

                                                                                                                          1. 2

                                                                                                                            The response from the maintainer made it seem like it was a design decision. And also, “If you are concerned about security problems, this library is not for you.”

                                                                                                                            But good to see that it has been fixed. It looks like the maintainer has gone from “i don’t care about ub” to “let’s do formal analysis to prove it doesn’t happen.” That’s good.

                                                                                                                        3. 2

                                                                                                                          That decision is probably based on the intended platform:

                                                                                                                          Most (all?) of my public projects are designed to be runnable on embedded platforms, and usually that means I make some harsh compromises.

                                                                                                                          Static allocation makes it much easier to ensure that code won’t run out of memory on a device with very little of it.

                                                                                                                          1. 1

                                                                                                                            There is a template-based compile-time regex implementation in C++. I didn’t bookmark it, though; all I remember is it was written by a Russian woman about four years ago.

                                                                                                                            I imagine this could be done in Rust, Nim or Zig, too.

                                                                                                                            1. 2

                                                                                                                              You mean this?

                                                                                                                          1. 4

                                                                                                                            This is by far the best resource for networking ever published. His guides aren’t boring as he even makes them entertaining and fun to read

                                                                                                                            1. 2

                                                                                                                              I recall being put of by the overly tongue-in-cheek tone. It distracted me from what I wanted to know. Though that might be because I wanted a reference manual, and what I was reading was more like a book.

                                                                                                                            1. 8

                                                                                                                              http://undeadly.org for anything OpenBSD-related

                                                                                                                              1. 4

                                                                                                                                About Dragonfly, but actually covering all BSDs to some degree.

                                                                                                                                https://www.dragonflydigest.com/

                                                                                                                                1. 3

                                                                                                                                  The weekly bsd and then one day later the weekly “cool stuff from the internet” are one of the posts I look forward to everyone week!

                                                                                                                                  1. 1

                                                                                                                                    Absolutely. They manage to be the highlight from my tracked rss these days, quite often.

                                                                                                                                  2. 2

                                                                                                                                    I second this.

                                                                                                                                1. 12

                                                                                                                                  Some more interesting articles on the website, including: http://jehanne.io/2018/11/15/simplicity-awakes.html

                                                                                                                                  I wonder why GCC and not e.g. tcc, if simplicity is stated as the primary goal?

                                                                                                                                  The author ponders package management in one place, I’m curious if they’d like https://github.com/andrewchambers/hermes

                                                                                                                                  1. 4

                                                                                                                                    I think the answer to this question is that much software relies on a (GNU) C standard not fully supported by tcc. As far as I know tcc only supports C89 fully (maybe even GNU89 although I am not sure)

                                                                                                                                    1. 1

                                                                                                                                      Is there an alternative minimal C toolchain that supports C11?

                                                                                                                                      1. 7

                                                                                                                                        cproc? The vast majority of packages in Oasis Linux are compiled with it

                                                                                                                                        1. 1

                                                                                                                                          Even if it supports C11, that wouldn’t be sufficient. Many applications use so called GNU C extensions (Linux for example) which are only fully supported by clang and gcc.

                                                                                                                                    1. 3

                                                                                                                                      As someone who is the target audience of this guide (programming experience but never written a single line of R in my life) I must say that this guide is pretty good. Short, simple and straightforward. Unfortunately many languages often only offer guides for total beginners which isn’t necessarily a bad thing but often boring for people with programming experience who just want to get started as fast as possible. This often leads to the skipping of chapters and therefore the missing of important information from those.