I tried to switch to nushell full-time but couldn't stick with it.
Ironically, the main friction point were not old-fashioned tools (which `from ssv` usually handled nicely) but the 'new generation' of core CLI tools like eza or fzf. They have really nice visualizations, but they do not output structured data as a middle step, so all the colours and lines only play havoc with nu's parsing.
Since I need to "ls" a lot more often than I need to do data manipulation, the tools won and I went back to zsh. Still keep nu around for the occasional config/data file wrangling though.
It doesn't stop Android Auto from doing whatever with the car data, but it's sandboxed to have no more default privileges than a regular app, so it can be denied access to your phone's data by default (apps, contacts, etc.). Wireless AA will only work if you grant it extra privileges; wired AA does not need them.
You can also "firewall" AA via something like TrackerControl, this would let you block connections to eg. Google Analytics servers without denying network access altogether (which would likely cause AA to stop working). I've only used AA with short-term rentals so I didn't spend too much time exploring these options.
> Beyond that, this is a laptop that is running a really shitty, 'apps only, no you cannot do anything useful with this' operating system. I have an awful lot of complaints about MacOS's relatively restrictive use cases, but it's still at least a General Purpose OS. Android on laptop is very much not.
Android 16+ offers a built-in integrated Linux VM that can be enabled from Developer Mode, and if this[0] third-party site is accurate, "Android on laptop" will have it enabled by default.
So it should not be too different from working on a Windows laptop with WSL2, or on an OSTree distro where you use distroboxes to work with non-sandboxed programs.
(fwiw, I would still refuse to have one of these for personal use because Google is a shameless data robber. Unless someone were to de-google Aluminium like LineageOS and GrapheneOS did for Android, but that would probably take years.)
> It’s such an annoying question because the honest answer is I eat what the locals eat, which is to say the most authentic Japanese cuisine is what you find in a Japanese supermarket. That’s what the people of Japan are actually eating.
Well, that's only true if you also observe what Japanese customers are buying and do your best to mimic their habits.
You could go into any Italian supermarket and fill your cart with weißwurst, avocados, and Camembert cheese - and they're all right there in the meat, fruit, and dairy areas respectively, not in an 'ethnic' corner - but it would be hardly a good representation of what the locals typically eat.
> so something that 95% of the users of Zed will end up doing?
Will they? I downloaded it for a test run, and there was no pressure to create a Zed account. I got the impression that it's something you'd do if you wanted to use their cloud AI services, and I can't really see why you'd want a third party involved instead of just bringing your own subscription to your favourite model.
By "release infrastructure" I didn't mean gain admin access to github.com, I meant gaining the credentials to push out a release of that particular package.
That's correct. In practice we would often rephrase to avoid the double 'la', not because it's grammatically incorrect but because it is awkward to read (less so in speech). Compare:
French: C'est une citation de De Gaulle.
German: Das ist ein Zitat von Von Neumann.
Both correct, but one would probably add "Charles" or "John" between the two 'de' or 'von' just to break them up.
The cooldown is a defence against malicious actors compromising the release infrastructure.
Having the forge control it half-defeats the point; the attackers who gained permission to push a malicious release, might well have also gained permission to mark it as "urgent security hotfix, install immediately 0 cooldown".
Even in that scenario, having the duress pin option does not make things worse. It's functionally equivalent to smashing the phone, just easier to do with one hand.
i.e. whatever they do to you if you wiped the phone via duress PIN, they would already do to you if you managed to smash the phone.
> Other Email providers such as Tuta which also offer encrypted emails, were forced to install a backdoor. As soon as the police arrive, every future email sent to the account in question is copied unencrypted without the person being informed.
Important caveat: Tuta was required by a court to provide police with access to a customer's _unencrypted_ emails (ie regular SMTP mail). The police had also asked for a backdoor to Tuta's E2E emails, and that request was rejected by the courts.
> I always wonder why people bother with providing source under a source available license. [..] There's little to no benefit to outside users. Any work they do on the code is effectively free work they do for you that entitles them to nothing.
Don't need to make PRs to benefit from the source being available. Running software whose source code has been under public eyeballs, and that I have compiled myself (or that a trusted third-party has compiled) is far more secure than running a binary blob that may or may not do what the developer's marketing page promises.
> If something like Bun (recently acquired by anthropic) becomes orphaned, we'd still have the git source code and a permissive license.
Closed-source apps have had source-code escrow clauses for a long time, exactly to avoid that problem. "If my company shuts down, you get all the source code and can do whatever you want with it."
Such clauses can, and should, be brought over to source-available licenses, where they would also be trivial since you don't even need a physical escrow.
There's nothing any UniversalBlue image tweaks that you couldn't tweak yourself. It's just adding/removing packages, adding/removing drivers, a few configuration scripts, and a bunch of tweaks to fix well-known gaming-related issues.
But the point is that, if you want to game on Linux, you probably want to perform exactly or almost exactly the same tweaks that Bazzite already does. So why bother doing them yourself?
It's not even a linux-from-scratch situation where you'd do it for the sake of learning. Googling "my controller doesn't work right", finding some discussion threads, and copy-pasting a bunch of fixes isn't particularly interesting.
It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version?
Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.
Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.
Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?
Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.
(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)
One quick improvement would be to style the number boxes to include decimal separators. For a few answers I was squinting to check if I had typed six or seven zeroes, for example.
Ironically, the main friction point were not old-fashioned tools (which `from ssv` usually handled nicely) but the 'new generation' of core CLI tools like eza or fzf. They have really nice visualizations, but they do not output structured data as a middle step, so all the colours and lines only play havoc with nu's parsing.
Since I need to "ls" a lot more often than I need to do data manipulation, the tools won and I went back to zsh. Still keep nu around for the occasional config/data file wrangling though.