Hacker Newsnew | past | comments | ask | show | jobs | submit | adidalal's commentslogin

There's `brew uninstall --zap $application`[1], and there's pretty decent coverage, but it's by no means comprehensive. If you feel inclined to contribute, the process is quite streamlined, and there's a helper script[2].

I used Appcleaner[3] for many years, and it's still perfectly serviceable

I'm keeping my eye on Pearcleaner[4], which is additionally open-source and written in Swift.

[1] https://docs.brew.sh/Cask-Cookbook#stanza-zap

[2] https://github.com/nrlquaker/homebrew-createzap

[3] https://freemacsoft.net/appcleaner/

[4] https://itsalin.com/appInfo/?id=pearcleaner


I followed a similar path as you did about a year ago. Having tried a bunch of options, I can recommend strongly Strongbox - fantastic native apps for iOS and macOS, with your choice of sync mechanism (local-only is also a first class citizen), and it uses the KeePass file format so you can use your client of choice on other operating systems/no worries about lock-in. Good system integration and autofill extensions. I also appreciated that there was an option for a one-time purchase.

https://strongboxsafe.com


For those interested in self-hosting the home server, I would recommend https://github.com/spantaleev/matrix-docker-ansible-deploy - the documentation is fantastic and it’s very well maintained.


I'm personally waiting for Dendrite. Apparently the beta is usable now, setting it up has been on my to-do list.


I self host Synapse for personal use, what are the expected benefits of Dendrite? Is it mostly the performance gain of Go versus Python, or are there other reasons to be looking forward to Dendrite?


My main issue with self-hosting has been federation bandwidth requirements. I joined the very quiet `#homeowners:matrix.org` announcement room, but because almost 600 other people are in there my server was inundated with presence messages (just in case I wanted to know which of those 600 were online right now).

Oh, and there's no way to prevent receiving these messages. They arrive on the same endpoint as non-presence messages, and you can't signal to the sender to stop sending them.


I’ve been hosting my own matrix server for just a few months now. I have a small handful of users. Bandwidth hasn’t been a problem for me, as I’ve only served 5GB in the last 30 days. It’s the sheer number of requests that the server handles that I find staggering. In the last 30 days, my server has handled 1.3mm requests!

It seems like everything polls for data, which I see as wasteful. I recently saw they were adding socket support in a recent MSC... hopefully that will help.


Unfortunately not a solution for federation with other servers, but you can disable presence on Matrix servers you control.

For this playbook, use these variables:

  matrix_synapse_use_presence: false
  matrix_client_element_enable_presence_by_hs_url: {"https://matrix.yourserver.com": false}


Thank you. I had that set for my server, but I just wish there was a way to tell other servers not to send them. Disabling them on my server turns them in to a no-op, but it still has to process all those requests.


The minute you mention Github, you lose 98% of human beings? This is clearly aimed at those who just want something to work out of the box, surely? HN is not the target audience I guess.


Because


Just wanted to highlight that as of this release, all the core code for Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into the Brew codebase. This should allow for tighter integration between the two and a renewed focus on making installing GUI apps as painless as possible!

From a user/developer perspective, we've created a command line utility (`cask-repair`) to make version bumps as painless as possible. Would love to see more people using it [0], and we welcome suggestions and PRs (we have a few long-standing issues that have gone unaddressed, and fresh eyes are always good!)

[0] https://github.com/caskroom/homebrew-cask/blob/master/CONTRI...


Looking forward to checking this out. One issue I have run into with homebrew is that due to varying packaging choices as a project grows, I've seen stuff move back and forth from brew core to cask to neither, and the old ones stick around at the outdated version so you have to be careful when you tell people to install the thing (seen this happen with terraform for example, which a month ago when I last checked existed as a year-old version in a cask, a few months old version in core, and the current version wasn't available in either).

It might be cool to also allow some kind of process for marking packages as deprecated and showing a warning or confirmation prompt if you try to install it, for the cases when maintainers start packaging in some different way that can't be supported by homebrew.


We do have a `deprecated` caveat, but we rely on users to bring up that fact, as there's no way the maintainers can keep track of the status of every Cask.

There's also a fairly large push and discussion about removing duplication between Homebrew core and Homebrew Cask, so you should see things improve. There should also be Formula -> renamed Cask migration at some point, the issue has been raised in brew-evolution. (We have basic Cask <-> Formula support already).

Re: terraform specifically, looks like it's now in core, and `brew cask terraform` will know to do `brew install terraform` automatically.


If you have a Mac you can use AppleScript to delete things programmatically by simulating clicking in Safari.

I also found this upon a quick search, no idea if it is fully functioning: https://github.com/IonicaBizau/reset-your-facebook-account


Just added to Homebrew Cask, feel free to `brew cask install qbserve`

(I'm one of the maintainers of Homebrew Cask)


Thank you!


In this case, yes, as it verifies the download against a (best-effort) known-good checksum. It's not a perfect system, but did work out in this case.

GPG verification where available and refusing to install Casks without a checksum is also in the pipeline.

(I'm one of the maintainers of Homebrew Cask)


If you installed/updated via Homebrew-Cask [1], you should not be affected. 2.90 was not always compromised, and looking at Caskroom history, the checksum was only updated for the 2.84 -> 2.90 bump once [2].

It is updated and at 2.92 now, also [3].

(I'm one of the maintainers of Homebrew Cask)

[1] https://github.com/caskroom/homebrew-cask

[2] https://github.com/caskroom/homebrew-cask/issues/19504#issue...

[3] https://github.com/caskroom/homebrew-cask/pull/19508


Homebrew Cask is awesome, but I still think security is an issue here because you still have to trust the upstream binaries are safe, each built and hosted by totally different people. Verifying checksums is certainly better than not checking them, but you still haven't escaped from the trust-whatever-binary-you-downloaded-from-the-internet-style of doing things. I really wish package managers like Homebrew Cask offer some level of trust by building applications from source and signing them, like Debian.


You are absolutely correct. Homebrew-Cask favors convenience and availability of as many applications as possible, though we make reasonable efforts to avoid malicious actors by verifying checksums, download links, and (soon) GPG verification where possible.

You may be interested in https://www.macports.org for a build-from-source solution for OSS projects.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: