471–480 of 516 posts
Earlier quoted context omitted.
What makes you think it happens silently or without your consent?
Silently: it does not print any indication it is transmitting activity data when it does so. Without consent: it does so automatically, without prompting the user to opt-in to such spying.
Earlier quoted context omitted.
Re. [0]: how does anonymous telemetry (number of unique installs per package) constitute spyware? Re. [1]: GitHub pays the bills for (a large part of) the infrastructure we’re using. They reached out to us, explained the problem and asked us to unshallow. Honestly, what would you have done instead of complying?
Ad "Re. [0]": If some program is calling a third party without explicitly asking the user in the first place (especially when we're talking about a compromised company such as Google), that's spyware. Debian has solved it in a user-friendly manner in their ``popcon``: they just ask you kindly if you want to report stats to them. It's hard for me to imagine someone putting opt-in telemetry in good will… Ad "Re. [1]":…
You can’t imagine package maintainers would want to know unique install counts per package so maintainers can prioritize work? In good faith?
Opt-in is not a choice. It would render the numbers largely meaningless.
Earlier quoted context omitted.
If Gentoo makes your particular computer goal easier to achieve, I don't think it's "hostile". Most people will never need Gentoo or want to use it, but for those with either a need or a desire for a meta-distribution, Gentoo does a pretty good job. I don't think calling it "user hostile" is quite right. I think it's been partially supplanted by other package managers now like Nix/NixOS and even (IMO) XBPS/Void, but…
I used Gentoo for a while and mostly liked it. There was one reason I stopped using it -- dependency conflicts. Every time you update, there's a new set of conflicts that you have to personally untangle. By any other metric, I would consider it more user-friendly than average. For example, I was very favorably impressed when (not knowing what I was doing), I gave the command to uninstall libc, and after confirming th…
The community feel was pretty good. Excellent documentation/wiki. And it was by far the best Linux education I could have ask for back in those days. I’m happy ...
Earlier quoted context omitted.
MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts. All the naming in HomeBrew was just too confusing too me.
I've never used MacPorts. Go figure, I just realized that "MacPorts" means "bsd ports for mac". I'll have to try it sometime and see if I prefer the look and feel of MacPorts.
Earlier quoted context omitted.
MacPorts seem to be very “user” friendly for people with Unix and/or Gentoo (maybe a bit Arch too) background. I have experience with all three and when I needed to decide in between HomeBrew and MacPorts, it was very simple choice. I tried both to get the actual experience and stuck with MacPorts. All the naming in HomeBrew was just too confusing too me.
Gentoo is probably the most user hostile Linux distribution I can think of other than ones purposely austere for learning (LFS) or parody (Suicide Linux). If Mac Ports requires that level of knowledge to be user friendly it’s no surprise they lost.
Earlier quoted context omitted.
It saddens me as I see this massive infusion of developer time and energy being donated to one of the biggest tech companies around. If that effort had instead gone into making Linux better, which Homebrew obviously builds on, where would Linux workstations be now? Would I get a nice Linux laptop from my company instead of being forced to use a MacBook?
Contributing to Linux also helps the biggest tech companies around - namely IBM and Oracle amongst a host of others. When you contribute to free and open source software you should know and understand you're providing your labor for free to tech behemoths. For most it's a labor of love and aligns with their passion and so everything is cool but you run across a few who's feelings get hurt and feel like they're gettin…
Earlier quoted context omitted.
It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.
Are you sure about that? I currently have it installed in ~/brew and commands link from ~/brew/Cellar into ~/brew/bin and there is a .git directory in ~/brew. I used to put it in /usr/local and it irked me that there was a /usr/local/.git. That was the main reason I stopped putting it there.
I personally found Homebrew to be really helpful when I looked at MacOS as a unix environment and tried to engage in local development as if it were a unix environment. [Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for w…
I'm interested in this workflow, some questions: - When you say "local editor, remote runtime", are you referring specifically to VS Code's remote development features? - Is the remote runtime a Linux VM on the same machine, or running on another machine? - Do you run git locally? - Do tests run locally? - Do you have a link to an article detailing this workflow?
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...
Earlier quoted context omitted.
It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.
It used to turn /usr/local into a Git repository, at least until that got locked down with SIP.
Earlier quoted context omitted.
Silently: it does not print any indication it is transmitting activity data when it does so. Without consent: it does so automatically, without prompting the user to opt-in to such spying.
There is a prompt. It’s impossible to miss.
It also only occurs once, on install, and is silent thereafter on each data exfiltration.