7 ms·

While Signal is pretty awful on desktop(not to mention this[1] thing), it is my goto messenger on my phone. Brilliant security and props for being one of the ve

While Signal is pretty awful on desktop(not to mention this[1] thing), it is my goto messenger on my phone. Brilliant security and props for being one of the very few to extensively use Rust in production. I was really sad to see they hire in the US only. [1] https://github.com/signalapp/Signal-Desktop/issues/1630 https://github.com/signalapp/Signal-Desktop/issues/1630

deleted 6y ago
[deleted]
godelski 6y ago
This might help https://aur.archlinux.org/packages/signal-desktop-beta-bin/ https://aur.archlinux.org/packages/signal-desktop-beta-bin/
ruph123 6y ago
I disagree. Signal on Fedora works very well for me. Even video/audio calls work surprisingly well. And it is available as a Flatpak.
yuvadam 6y ago
I find it odd that packaging for a specific distro is an upstream effort. I never understood why upstream source should include Debian/Fedora-specific files. The way that Arch Linux approaches packaging makes much more sense to me - a single bash-like PKGBUILD file that describes how the upstream source should be transformed into a package that the distro knows how to deal with.
- gspr 6y ago
  > I find it odd that packaging for a specific distro is an upstream effort. I never understood why upstream source should include Debian/Fedora-specific files. This is generally frowned-upon in Debian too. Upstream's effort are nearly always wrong from the distribution's point of view, and extra busywork has to be done to get rid of upstream's attempt.
  - kelnos 6y ago
    On the flip side, I definitely do appreciate when upstream includes a debian directory, as that means I can easily self-build my own package with the latest source, even if I'm on Debian stable or whatever and don't expect and update or backport.
    - viccuad 6y ago
      That's also the case if there's an official Debian package; you can build whatever package from whatever distribution (you may be missing dependencies, but it would be the same with an upstream debian directory). If one is going to contribute a debian directory, maybe it's more efficient to contribute it to Debian directly. Note also that making "a" .deb package is not the same as making an official Debian package that satisfies the Debian Policy and passes the automated linters (lintian, piuparts, autopkgtest, etc). The second will have the minimum quality that Debian expects.
      - kelnos 6y ago
        > That's also the case if there's an official Debian package; you can build whatever package from whatever distribution Yes, I can `apt source foo` and then spend annoying painstaking time dumping in the new version of the upstream source, fixing any weirdness with the build system, updating dependencies, etc. I've done this every now and then and I hate doing it. It doesn't help that Debian's packaging tools have worse UX than git, inscrutable errors, and nearly nonexistent detailed documentation. In contrast, if upstream has its own debian directory checked into their source repo, I can usually expect it to work; all I'll need is a `sudo apt build dep . && dpkg-buildpackage -uc -us` and it should build without any futzing on my part. And if an even newer version later ends up in the official Debian repository, it'll get seamlessly updated with no further work on my part. (Meanwhile I also appreciate being able to grab upstream Linux kernel source, copy in my local config, and run `make deb-pkg` in its root to get a perfectly-functioning, updated kernel that installs things to the right places and properly integrates with dkms and update-initramfs. Even just rebuilding Debian's shipped kernel is usually not that easy.) > Note also that making "a" .deb package is not the same as making an official Debian package that satisfies the Debian Policy and passes the automated linters (lintian, piuparts, autopkgtest, etc). The second will have the minimum quality that Debian expects. I frankly do not care about that one bit. All I want is something that I can trivially build, installs on and integrates (reasonably) well with my system, will get upgraded automatically if a newer version shows up in an official Debian repo, and I can easily remove with `apt purge foo`. A debian directory checked into the upstream ticks all those boxes. Trying to shoehorn newer upstream source into an existing Debian-maintained debian directory usually very much does not. If your experience differs, all the more power to you, but this has been my experience using Debian for many years now.
- gravitas 6y ago
  Arch PKGBUILD packaging is basically identical in design to RPM packaging, and can contain more than just s single build script (patches, pre/post scriplets in another file, etc.). Arch packaging feels familiar and "normal" if you're coming from any RPM based distro, including the SUSE family. It is the DEB format which is generally unlike most others in architecture and design, you cannot toss "Fedora/Ubuntu" into the phrase and be honest, they are quite different and have different design goals.
- godelski 6y ago
  For those kinda newish to linux, one thing I learned when I didn't have a deb/rpm file is to go look at the arch aur pkgbuild as a guideline of how to build the packages from source. Arch has surprisingly been a good guide for general linux questions.
harry8 6y ago
Disagree. Signal on desktop works very well for me and is very useful for quickly sending files from desktop to phone and back, especially when the phone isn't handy.
- fsflover 6y ago
  Except you must have it installed on a spyphone at the same time, which destroys all privacy it has...
  - Mediterraneo10 6y ago
    There are efforts to get Signal working on the PinePhone and Librem phone through Anbox. Signal also does not require Google Play Services, it can run with completely libre software all the way down. So, Signal is becoming a viable choice on a device that meets Free Software standards and is not a “spyphone”.
    - Vinnl 6y ago
      I think (but haven't tried myself) that you can nowadays even confirm your number on desktop, i.e. receive a text message on a dumbphone if need be, and then enter the confirmation code on your desktop.
      - fsflover 6y ago
        That would be really good if true.
      - everdrive 6y ago
        That I wasn't aware of. It would be quite nice, if true.
  - gtsop 6y ago
    Except I have it installed on grapheneos
- simias 6y ago
robert_foss 6y ago
The only terrible thing about is it being Electron based. Most mobile IMs have no desktop client at all.
thewojo 6y ago
Yeah it's so odd to me that Signal has such top tier engineers and they can't manage to get a presentable desktop app. It looks and feels like a boilerplate Electron chat app with no styling and subpar performance (oh but they have stickers :eyeroll:).
- vorticalbox 6y ago
  It also annoying when you set up a new client that is has to sync all your messages then for security reasons not show any of them.
Kihashi 6y ago
> While Signal is pretty awful on desktop Weird. I find the desktop app pretty good. I see people complaining about it being slow, but that's not been my experience. My main complaint with the desktop app is that I really want it to sync message history with the phone app. If you, for example, don't use your laptop for a while, you'll have to re-authorize it and it won't have any messages from when it was off. I realize all of that is a trade-off for their security design, but having access to all my messages and being able to search them is important to me.

deleted 6y ago

[deleted]

godelski 6y ago

This might help https://aur.archlinux.org/packages/signal-desktop-beta-bin/ https://aur.archlinux.org/packages/signal-desktop-beta-bin/

ruph123 6y ago

I disagree. Signal on Fedora works very well for me. Even video/audio calls work surprisingly well. And it is available as a Flatpak.

yuvadam 6y ago

I find it odd that packaging for a specific distro is an upstream effort. I never understood why upstream source should include Debian/Fedora-specific files. The way that Arch Linux approaches packaging makes much more sense to me - a single bash-like PKGBUILD file that describes how the upstream source should be transformed into a package that the distro knows how to deal with.

gspr 6y ago
> I find it odd that packaging for a specific distro is an upstream effort. I never understood why upstream source should include Debian/Fedora-specific files. This is generally frowned-upon in Debian too. Upstream's effort are nearly always wrong from the distribution's point of view, and extra busywork has to be done to get rid of upstream's attempt.
- kelnos 6y ago
  On the flip side, I definitely do appreciate when upstream includes a debian directory, as that means I can easily self-build my own package with the latest source, even if I'm on Debian stable or whatever and don't expect and update or backport.
  - viccuad 6y ago
    That's also the case if there's an official Debian package; you can build whatever package from whatever distribution (you may be missing dependencies, but it would be the same with an upstream debian directory). If one is going to contribute a debian directory, maybe it's more efficient to contribute it to Debian directly. Note also that making "a" .deb package is not the same as making an official Debian package that satisfies the Debian Policy and passes the automated linters (lintian, piuparts, autopkgtest, etc). The second will have the minimum quality that Debian expects.
    - kelnos 6y ago
      > That's also the case if there's an official Debian package; you can build whatever package from whatever distribution Yes, I can `apt source foo` and then spend annoying painstaking time dumping in the new version of the upstream source, fixing any weirdness with the build system, updating dependencies, etc. I've done this every now and then and I hate doing it. It doesn't help that Debian's packaging tools have worse UX than git, inscrutable errors, and nearly nonexistent detailed documentation. In contrast, if upstream has its own debian directory checked into their source repo, I can usually expect it to work; all I'll need is a `sudo apt build dep . && dpkg-buildpackage -uc -us` and it should build without any futzing on my part. And if an even newer version later ends up in the official Debian repository, it'll get seamlessly updated with no further work on my part. (Meanwhile I also appreciate being able to grab upstream Linux kernel source, copy in my local config, and run `make deb-pkg` in its root to get a perfectly-functioning, updated kernel that installs things to the right places and properly integrates with dkms and update-initramfs. Even just rebuilding Debian's shipped kernel is usually not that easy.) > Note also that making "a" .deb package is not the same as making an official Debian package that satisfies the Debian Policy and passes the automated linters (lintian, piuparts, autopkgtest, etc). The second will have the minimum quality that Debian expects. I frankly do not care about that one bit. All I want is something that I can trivially build, installs on and integrates (reasonably) well with my system, will get upgraded automatically if a newer version shows up in an official Debian repo, and I can easily remove with `apt purge foo`. A debian directory checked into the upstream ticks all those boxes. Trying to shoehorn newer upstream source into an existing Debian-maintained debian directory usually very much does not. If your experience differs, all the more power to you, but this has been my experience using Debian for many years now.
gravitas 6y ago
Arch PKGBUILD packaging is basically identical in design to RPM packaging, and can contain more than just s single build script (patches, pre/post scriplets in another file, etc.). Arch packaging feels familiar and "normal" if you're coming from any RPM based distro, including the SUSE family. It is the DEB format which is generally unlike most others in architecture and design, you cannot toss "Fedora/Ubuntu" into the phrase and be honest, they are quite different and have different design goals.
godelski 6y ago
For those kinda newish to linux, one thing I learned when I didn't have a deb/rpm file is to go look at the arch aur pkgbuild as a guideline of how to build the packages from source. Arch has surprisingly been a good guide for general linux questions.

harry8 6y ago

Disagree. Signal on desktop works very well for me and is very useful for quickly sending files from desktop to phone and back, especially when the phone isn't handy.

fsflover 6y ago
Except you must have it installed on a spyphone at the same time, which destroys all privacy it has...
- Mediterraneo10 6y ago
  There are efforts to get Signal working on the PinePhone and Librem phone through Anbox. Signal also does not require Google Play Services, it can run with completely libre software all the way down. So, Signal is becoming a viable choice on a device that meets Free Software standards and is not a “spyphone”.
  - Vinnl 6y ago
    I think (but haven't tried myself) that you can nowadays even confirm your number on desktop, i.e. receive a text message on a dumbphone if need be, and then enter the confirmation code on your desktop.
    - fsflover 6y ago
      That would be really good if true.
    - everdrive 6y ago
      That I wasn't aware of. It would be quite nice, if true.
- gtsop 6y ago
  Except I have it installed on grapheneos
simias 6y ago

robert_foss 6y ago

The only terrible thing about is it being Electron based. Most mobile IMs have no desktop client at all.

thewojo 6y ago

Yeah it's so odd to me that Signal has such top tier engineers and they can't manage to get a presentable desktop app. It looks and feels like a boilerplate Electron chat app with no styling and subpar performance (oh but they have stickers :eyeroll:).

vorticalbox 6y ago
It also annoying when you set up a new client that is has to sync all your messages then for security reasons not show any of them.

Kihashi 6y ago

> While Signal is pretty awful on desktop Weird. I find the desktop app pretty good. I see people complaining about it being slow, but that's not been my experience. My main complaint with the desktop app is that I really want it to sync message history with the phone app. If you, for example, don't use your laptop for a while, you'll have to re-authorize it and it won't have any messages from when it was off. I realize all of that is a trade-off for their security design, but having access to all my messages and being able to search them is important to me.