chromebrew VS Git

Hello, I have a TP Link Archer T2U Plus adapter with RTL8821AU and I would like to use it on my PC, could you help me? PD: I have tried to install the Linux subsystem but I get an error, so I tried something from this post although I don't know how to use it https://github.com/skycocker/chromebrew

I see, to give you a point of view i should mention that Chrome OS itself is a Linux, to test what i mean you can press ctrl+alt+t and crosh terminal window will open(it is different than Linux development environment), now type "uname -a" and you'll see which kernel version it is, and it is actually capable of running regular GNU/Linux applications as expected(*See chromebrew for real world example). Why did they chose virtual machine approach for running regular GNU/Linux applications is for babysitting reasons, and embracing web apps as it is made as thin client rather than full blown OS.

Or you could install Chromebrew and use sommelier

As a Chromebrew dev... lololol. :)

2- The terminal you see when you activate Linux support is not the terminal of Chrome OS itself but the terminal of virtual machine called Crostini.Although Chrome OS itself is capable of running containers running on top of same kernel(Crouton for real world example) or running GNU/Linux apps even without needing Crostini virtual machine(Flatpak support on the Cloudready and Chromebrew Package Manager directly running on top of Chrome OS for the real world example), see the page below for understanding why they chose this approach(TL; DR Babysitting reasons for someone who uses sudo for everything):

Chrome OS itself is pretty much capable of running regular GNU/Linux programs without needing a virtual machine like Crostini, there is even a package manager for it. However like i said Google chooses only using web apps route, Crostini is meant to be only for development purposes and pretty much limited like usb or internal hardware access(like camera) and even the screen sharing itself.

> Because it was under 1000 layers of other bullshit

Not only because of that.

git-range-diff, while absolutely a killer feature, is a relatively new feature of git as well (a bit similarly to "git rebase --update-refs" -- which I've just learned of from you <https://news.ycombinator.com/item?id=41511241>, so thanks for that :)).

Namely, git-range-diff existed out-of-tree as "git tbdiff" <https://github.com/trast/tbdiff> originally. It was ported to git proper in August 2018 <https://github.com/git/git/commit/d9c66f0b5bfd>; so it's not a feature people could have used "15 years ago".

(FWIW, before git-range-diff was a thing, and also before I had learned about git-tbdiff, I had developed a silly little script for myself, for doing nearly the same. Several other people did the same for themselves, too. Incremental review was vital for most serious maintainers, so it was a no-brainer to run "git format-patch" on two versions of a series, and colordiff those. The same workflow is essential for comparing a backport to the original (upstream) version of the series. Of course my stupid little script couldn't recognize reorderings of patches, or a subject line rewrite while the patch body stayed mostly the same.)

>> So it's hard for me to recommend tk for GUI development.

Tcl/Tk is widely used in lightweight legacy GUIs.

Python distributions will typically include tkinter (https://docs.python.org/3/library/tkinter.html) which is just a Python wrapper for Tk.

Git usually includes the gitk graphical utility which is written in Tcl/TK: https://github.com/git/git/blob/master/gitk-git/gitk

It's probably in use in other places, but those are two that quickly come to mind.

I agree that Tcl/Tk is probably not an ideal choice for new projects, but it has a long legacy, is quite stable and likely to be around, largely unchanged, for some time to come.

`git add` can be quite slow when handling large files, in large repositories, with a large index or on slow platforms. For instance this optimization in git brought the runtime of `git add .` on Windows with 200k files from 6s to 3s: https://github.com/git/git/commit/d1664e73ad96aa08735bf81d48....

100ms let alone 3s is much too long a wait, so Sublime Merge predicts the outcome of staging and presents that immediately. This made a noticeable improvement to responsiveness even on small repositories under Linux.

When you have the necessary dependencies, you can obtain the latest tagged Git release from several sources. The tarball is available at the kernel.org site (https://www.kernel.org/pub/software/scm/git) or the GitHub mirror (https://github.com/git/git/tags). The GitHub page typically provides clearer visibility into the latest version, while the kernel.org site offers release signatures for download verification.

Look at any PR/patch series that got merged into the Git project. https://github.com/git/git/

Any random one. Because those that did not meet the minimum criteria for a well-crafted history would not have passed review.