I wouldn't buy cables from them. Their 100W cables dont work even with their own 100W chargers. Bought multiple at different times, since I'd been using them with 60W chargers before. All of them had the same issue with dropping out with 100W chargers from Anker or other brands. I ended up throwing them all out and getting 100W cables from another brand, and those have been quite reliable.
Hmm that's not great. I don't have a 100W charger and my laptop is the only thing that I have that could draw that much, the 140W GAN charger I got from them is a total and only does 65W per C port.
I'll keep it in mind if I decide to grab a 100W charger, thanks for the heads up.
I guess we really can't be sure from product to product with Anker and will just have to take each product on reviews or test and return.
Sorry what do you mean by "symbol interpolation" and "interposition" in this context?
Natively I would assume you can just take the sections out of the shared object and slap them into the executable. They're both position independent so what's the issue?
If PIE allows greater assumptions to be made by the compiler/linker than PIC that sounds great for performance, but doesn't imply PIC code won't work in a PIE context.
PIC code would work where PIE does, but likely perform worse. In shared libraries, calls to any non-static function can't be assumed to be the same function at runtime, since another library linked or using LD_PRELOAD may also define the symbol. Thus all calls to non-static functions must go through the shared library lookup machinery. This prevents inlining opportunites as well. Functions in an executable can't be overwridden in this manner, and override the symbols in shared libraries. Thus PIE code can have cheaper function calls and freely inline functions.
Its not that you couldn't use the PIC code, but it would be better to just recompile with PIE.
jjui is the best VCS TUI I've ever used. It's even smoother than magit, but I think most of that is because of jj itself. Spinoff and absorb are both native jj features (jj rebase and jj absorb, respectively)
Completely agreed. I've been evangelizing jjui even more than I do jj!
And, you're right, it's powers largely come from the underlying jj - it mostly just runs jj commands behind the scenes, parses the output, and displays it. But it's all so beautiful, seamless etc..
I can't wait to really dig into the big additions released yesterday in v0.9.0 - themes, vim-like leader key shortcuts, other shortcuts etc...
Wondering the same. I've been using magit for a long time now and never use the git cli anymore. Going back to manually typing in commands doesn't sound appealing. The unified index/workspace non-stash-workflow does sound somewhat nice, though.
I am not a magit user but from doing a little bit of reading, all of these commands are essentially first-class citizens in jj. Spinoff seems to be `jj split` (or in most cases literally nothing because the default is to edit a new, empty revision off the trunk), absorb is probably `jj rebase` or `jj squash`, and the auto-backup is either the evolog (which tracks file changes that haven't been explicitly commmited) or the op log (which lets you reset the entire repo to what it looked like before or after any operation).
magit-merge-absorb is one of rebase (if that's what you want), or new (which gets you a merge when you specify multiple parents). The 'delete the branch' part of it doesn't really apply, because jj doesn't have branches; though you might need to delete a tag.
Note for other readers: jj also has a literal `jj absorb` command. That one does what you'd expect from mercurial, i.e. moves diffs from the current commit into the most recent ancestral commit where that file was changed.
Note also that jj does have branches, they are just anonymous. You don't checkout a branch or edit a branch, you edit a revision or make a new one. One revision with multiple children is a branching point, one revision with multiple parents is a merge.
You name them with bookmarks which are sort of like branch names except they don't follow along automatically as you make new revisions. You can point an existing bookmark at a later revision when you're ready to push new changes.
Yup, but that leads to io-uring devs complaining that people dislike software using io-uring because it doesn't run in containers/etc blocking io-uring entirely
It literally is their job. One of Mozilla's roles is to give their opinion on proposed web standards. It's one of the factors that determines what actually becomes a standard. WebUSB is Chrome (and derivatives) only at the moment. You can not like where they landed, perfectly valid, but they were asked.
Yes, but instead of saying "this spec is shit and full of vulnerabilities. Let's work on improving it", they just refused to participate in the discussion. What a childish POV.
I don't think that's a fair summary of Mozillas Position on the WebBluetooth/WebSerial/WebUSB specs. Interacting with arbitary devices has arbitrary consequences, mozilla seems to assume users are not able to understand these consequences and therefore cannot consent to it.
Well, the reason is in the links I provided, and the reasoning doesn't scream arrogance to me.
Personally, I think choice is great. Why be upset when you can download chromium (it is supported by pretty much any platform FF is) and use it to do all sorts of stuff with WebUSB, if you are into that?
Still, I would like to see FF disable these features by default and allow opt-in. I don't see a great reason to avoid implementing them behind some "wall" (other than to avoid an increase in a concealed attack surface).
You are completely missing the point just like Mozilla.
This is the same a surgeon saying they refused to perform life-saving surgery on you because they don't believe you understand the consequences of the possibility of dying in surgery.
The average person cannot be an expert on surgery or on browser security it's up to the people that have the education and work experience in there to make those decisions and handle them.
Mozilla as another poster said has taken their toys home because they didn't get what they want.
So, basically, they noticed some potential insecurities in the implementation proposed by Google. Instead of negotiating modifications to the spec like adults, they threw their toys out of the stroller and refused to participate.
What a bunch of idiots. They seem to have a completely misguided concept of what a browser is. They still have a 1990s mindset of the browser being a window into the Internet, instead of the universal UI that it has become today.
I don't miss the X11 days where I had to patch restoring window positions out of every application that did so. Good riddance.
Just that last time I had the application on a side monitor doesn't mean it should move itself after launching. Its especially bad if you often reconfigure monitor layout (for example laptop sometimes using external monitors).
I've bought cables from them that dont work with their own chargers. Bought multiple of each so was not a one-off. Their 100W cables fail when used with chargers that can do 100W.
