vscode-gitlens VS liblinux

Quite a while ago, the GitLens+ plugin gained the Commit Graph feature--the same graph you see in GitKraken. Until then I had used Git Graph for visualizing my repositories and GitLens+ for git blame in the GUI. Since one plugin could now do both, the natural course of action was to remove the other--goodbye, Git Graph!

Btw, today I want to speak about something different, I love git and I love terminal, but sometimes I love having the info visualised appealingly and get info about the source control quickly. I work with VsCode typically, so some months ago I tried to find a solution for this editor that resolves what was said before. After googling and some testing, the result of my search was: GitLens. Now, I want to show you how it works and how it can improve your routine. So don't waste time and let's jump in it!

GitLens extension chef's kiss

for GitLens https://gitlens.amod.io/

Hi. Vs code is pretty well integrated with git. There are built in git support and a couple other plugins. For example, the most popular git plugin for vs code is git lens. It also has powerful rebase editor (i guess, it is my favorite feature), which you can enable by following this guide. I personally realy enjoing Git Graph extension, which allow you to observe your git history in pretty similar to git kraken way. It also provide navigation facilities and some other useful features.

Redder color means changes were made very recently in that area. Again you can fully customize age thresholds, locations, the color of the most recent and least recent changes, etc., from the settings.

So here are some of my favorite GitLens features that I use regularly. You can find the full list of the features here.

Phone a friend. I recommend integrating git blame into your development environment I use the Git lens plugin which shows you, directly within files in a code editor, who authored certain file changes and the PR which can be helpful for quickly getting more context regarding decisions by looking at the associated Pull Request or having the opportunity to connect directly with the committer. Pair programming can be an effective way to debug and share knowledge. Similar, to the magic of figuring out the solution to a bug in the shower or overnight there is a phenomenon called rubber ducky debugging in which just explaining the issue to someone else (even an inanimate rubber duck) can help make the solution more obvious.

If you're using VS Code, get the GitLens extension. It has an interactive rebase editor which I find very helpful (as well as heaps of other nice features).

GitLens - https://gitlens.amod.io/#features , see who did what, when and why in your IDE and also quickly see any changes you have made

> Now, do I think it would make total sense for syscall wrappers and NSS to be split into their own libs (or dbus interfaces maybe) with stable ABIs to enable other libc's, absolutely!

I worked on this a few years ago: liblinux.

https://github.com/matheusmoreira/liblinux

I'm not developing it anymore though because I found out the Linux kernel itself has a superior nolibc library:

https://github.com/torvalds/linux/tree/master/tools/include/...

It used to be a single header but it looks like they've recently organized it into a proper project!

I wonder if it will become some kind of official kernel library at some point. I asked Greg Kroah-Hartman about this and he mentioned there was once a klibc:

https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

> This is something the BSD's got absolutely right.

BSDs, every other operating system really, force us to use the bundled C libraries and the C ABI. I think Linux's approach is better. It has a language-agnostic system call binary interface: it's just a simple calling convention and the system call instruction.

The right place for system call support is the compiler. We should have system_call keywords that cause it to emit code in the aforementioned calling convention. With this single keyword, it's possible to do program literally anything on Linux. Wrappers for every specific system call should be part of every language's standard library with language-specific types and semantics.

I'm not using this stuff professionally, it's just my own home lab's virtual machines with little services implemented as freestanding C programs. Not doing anything fancy right now, much of it was just to see if I could do it.

I've seen other people commenting here on HN saying they're using the same approach so it's defenitely not my invention.

I published some of my work in the form of a liblinux that I use to make system calls:

https://github.com/matheusmoreira/liblinux

I'm not developing it anymore though because I found out the kernel itself has a nolibc library:

https://github.com/torvalds/linux/tree/master/tools/include/...

It used to be a single header but it looks like they've organized it into a proper project.

That's awesome. I didn't know about rwildcard until now. Is it part of GMSL? I searched for rwildcard on gmsl.sourceforge.io but didn't find it.

I think my function is needlessly complicated compared to rwildcard. Here's my code:

https://github.com/matheusmoreira/liblinux/blob/modular-buil...

https://github.com/matheusmoreira/liblinux/blob/modular-buil...

The file? and directory? functions were inspired by GMSL.

I wrote a general recursion function. It takes a function to apply to lists and a function to compute whether an element is a base case.

The recursive file system traversal function applies a directory globbing function to the list of paths and has file? as base case.

The find function filters out any items not matching a given predicate function. It was my intention to provide predicates like C_file? and header_file? but I stopped developing that project before that happened.

I think rwildcard is probably simpler and more efficient!

Thanks for this, it's extremely awesome! Really happy to see others have gone so much farther than I ever did.

I started looking into this myself some years ago. Even started developing a liblinux with process startup code and everything. Abandoned it after I found the kernel itself had an awesome nolibc.h file that was much more practical for my C programming needs:

https://elixir.bootlin.com/linux/latest/source/tools/include...

My code is here if you'd like to take a look as well:

https://github.com/matheusmoreira/liblinux

It's amazing how this really lets you do everything... Want a JIT compiler? Map some executable pages and emit some code. You can statically allocate memory at process startup and then implement memory allocation and garbage collection in your own language.

> A new libc starting fresh would be nice.

Agreed. I want to make something like this on top of Linux. I discarded the entire libc and started from scratch with freestanding C and nothing but the Linux system call interface. Turns out the Linux system call interface is so much nicer.

https://github.com/matheusmoreira/liblinux/blob/master/examp...

I wish I still had the free time to work on this...

> What I wouldn't give for a liblinux, similar to NTDLL.

Hey I actually tried to make such a thing.

https://github.com/matheusmoreira/liblinux

It provides access to Linux system calls and process start up code that gets all the arguments, environment and auxiliary values. I have several examples of applications written in 100% freestanding C with no dependencies except this library.

It's a bit too low level compared to the dynamic loading library but I actually planned to make my own ld-liblinux eventually. I stopped working on it because I found better solution for system calls on the Linux kernel repository:

https://github.com/torvalds/linux/blob/master/tools/include/...

You think liblinux could have a future?

Thanks! Your projects are so inspiring. I too felt great joy discovering all this. Every time I see someone asking about system calls I respond by writing about everything I know. I usually don't get many replies... So happy to see another person who understands.

> You would like this project: https://chromium.googlesource.com/linux-syscall-support/

Yes, I would! I saw references to this library in your source code, specifically your jump slots implementation. I had no idea Chromium had this and I've been meaning to explore it later. I'm gonna do it now.

> Because too many people who post here hold the viewpoint that SYSCALL is evil and you must link the platform libc dynamic shared object or else you're a very horrible person who deserves to have their binaries broken like Apple did to Go.

I know what you mean! Using system calls are heavily discouraged by libc maintainers and even users. Using calls like clone will actually screw up the global state maintained by glibc threads implementation. It gets to the point where they don't even offer wrappers for system calls they don't want to support. I don't like it... What's the point of an amazing system call that lets you choose exactly what resources you want to share with a child task if all it's ever used for is some POSIX threads implementation?

Even the Linux manuals do this for some reason: the documentation I linked in my above post actually describe the glibc stuff as if it was part of the kernel and leaves the actual binary interfaces as an afterthought. Linux manuals also inexplicably host documentation for systemd instead of a generic description of how a Linux init system is supposed to interface with the kernel. It makes no sense to me!

I even asked Greg Kroah-Hartman about it on Reddit:

https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...

I actually think using the system call interface is better than using the C library. No thread local errno business, no global state anywhere, no buffering unless you do it explicitly, no C standard to keep in mind... It's just so simple it's amazing. It's also stable unlike other operating systems which ship user space libraries as the actual interface. On Linux there's no reason not to use it!

> I feel like you should publish this and post it on Hacker News.

I wrote a liblinux library, the README describes part of my journey learning about this system call stuff. Lots of LWN sources!

https://github.com/matheusmoreira/liblinux/blob/master/READM...

I've been thinking about expanding on it in order to describe everything I know about the Linux system call interface. You really think I should publish this?

The reason I didn't post liblinux here is it's in a very incomplete state and actually less practical than the kernel nolibc.h file. I only discovered the header much later into development and figured there was no point anymore since the kernel had a much better solution not only available but in actual use. I ended up rewriting autoconf in pure makefiles instead...