The one thing that bothers me (which is not Caddy's fault at all) is the plugin system. If I understand correctly, I have to recompile Caddy for every plugin I want to use, right? Sounds like a limitation with Go which is really unfortunate.
833 karma · joined May 12, 2015
> but Whatsapp might very well be simply MITM-ed by Facebook
As long as you're not inspecting the binaries you use for Telegram (or build the applications by yourself) however, you can't guarantee it's not MITM-ed by someone either. Maybe you do, but most users certainly do not. When downloading the Telegram app from Google Play, there is not much difference to the WhatsApp app. You're basically trusting small groups that they provide the "real" binary to you. Not much of a difference to trusting Moxie's words, is it?
Link 0 was to remind you of the link I posted before and the other links might not provide specific (or effective) attacks, but they point out flaws in Telegram's protocol (1,2,3) and the way they test / value the strength of their encryption (4). More flaws are very much plausible for a homebrew crypto solution.
Please read the link I provided before[0], it features links to a bunch of people saying Telegram is not secure[1][2][3][4]. It's not just Moxie. I actually have not seen any expert saying that Telegram is secure, but I'm interested in such thing. As the Telegram protocol is open, everybody is able to see how flawed it is. We know that. With a closed client that allegedly implements a secure encryption method (we also know it's good because it's open as well) there's a chance it doesn't work the way it's supposed to work, but there's also the chance it's working as intended. I'd rather take one percent chance over zero.
[0] https://security.stackexchange.com/questions/49782/is-telegr...
[1] https://eprint.iacr.org/2015/1177.pdf
[2] https://unhandledexpression.com/2013/12/17/telegram-stand-ba...
[3] http://www.alexrad.me/discourse/a-264-attack-on-telegram-and...
[0] https://security.stackexchange.com/questions/49782/is-telegr...
> Yeah, it's possible to have security like Signal [...]
Actually, WhatsApp has implemented Signal's encryption and they worked together with Moxie Marlinspike (the developer of Signal) who verified those claims (or something along these lines. I'm not 100% sure this is how it happened, please take it with a grain of salt). So at least one popular messenger implements security that is better than Telegram.
edit: If you're already using a specific command to tell the application to stay alive (e.g. nohup), you can use the "new" systemd command as well. nohup never related to a "session" scope because that didn't really exist before systemd. A new command _does_ break historical behaviour, but thanks god we do that from time to time. That's how innovation works.
[1] https://www.indiegogo.com/projects/roundcube-next--2#/update...
I think it's even worse because they won't patch or remove it. They could, but they do not consider it a problem. Ubuntu just imports everything from Debian. Things not relevant to the core team at Canonical are just thrown at the community basically saying "if you want a safe OS, you have to support this by yourself now". All the while Canonical is building their in-house, partly closed-source solutions to already solved problems.
> Source0: The full URL for the compressed archive containing the (original) pristine source code, as upstream released it. "Source" is synonymous with "Source0". If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory.
But the only URL that is available is <Project URL>/archive/v0.1.1.tar.gz. The SPEC file is therefore defining a file named v0.1.1.tar.gz although I downloaded my tarball as foo-0.1.1.tar.gz. The packaging process looks for v0.1.1.tar.gz, fails to find it in my SOURCES directory and aborts.
I'm not blaming GitHub here in any way, I just wish I had a bit more flexibility for the tarball URL. Would be neat.
[1] https://fedoraproject.org/wiki/How_to_create_an_RPM_package#...
If only. That's by far my biggest irk with GitHub releases because they only use the tag as name for the tarball (e.g. v0.4.tar.gz). Building RPM packages with those tarballs is a bit of a pain because RPM building tools expect all tarballs in one directory and you don't know which tarball belongs to which software. Maybe I'm just being ignorant here.
> We don't roll our own crypto.
> There are two parts of the code base in which "we roll our own crypto": the transfer protocl and encrypted library.
That's just ridiculous.
> We are a Chicago based team of developers, dedicated to creating useful, intuitive software that helps people better integrate digital computing into their daily lives
The GitHub repository also proves it's not "we": https://github.com/agajews/ApricityOS/graphs/contributors
He is styling himself and the OS as a professional project (at least that's the vibe I get from the website[2]) and he is actually asking for money[3] while he is putting his users in serious danger (as the current top post[4] illustrates) caused by his "rookie choices". This is deceptive and prompts unsuspecting users to install a High School project on their personal computers in the mistaken belief that they deal with someone skilled. I have very little sympathy for that.
Don't get me wrong, I'm young and I put up my projects as well, but I don't style myself a professional or ask for financial support for my half-assed code while keeping silent about the real nature of my project. Thinking about it, I might take down some code on GitHub or at least put up a big disclaimer.
[1] https://github.com/agajews/ApricityOS/issues/11
[2] check the "about the team" section, for example
[1] https://www.reddit.com/r/unixporn
[2] https://www.reddit.com/r/unixporn/comments/3r85qh/bspwm_ligh...
[3] https://www.reddit.com/r/unixporn/comments/3og32q/bspwm_wip_...
[4] https://www.reddit.com/r/unixporn/comments/3xen3g/bspwm_func...
[1] https://www.redhat.com/en/about/press-releases/red-hat-and-c...
> I don't know whether or not RedHat actually contributes to CentOS
CentOS is part of Red Hat (for like 1 - 2 years? Not sure).
I'm kinda irked by your original post because it seems to imply you cannot get Red Hat technology without the EULA or only by paying. That's just wrong as both CentOS and Fedora prove.
The more apt Red Hat equivalent seems to be Fedora here, which is 100% free as in speech & beer as well. Or CentOS, if we're talking about developing Enterprise software. It's a binary-compatible RHEL rebuild after all.
But for example, GNOME 3.18 on my Fedora 23 installation has an application called "(GNOME) Software" which automatically notifies me about new updates available and allows me to easily install them. It also summarises all non-application updates as "operating system updates". If you're interested in Linux UX, you really should try out a recent Fedora version in a VM - I think it has come a long way.
And honestly, Ubuntu is a terrible example for the Linux Desktop. They have dropped the ball long ago.
To add to that point: Linux exposes a lot of information in general. That's great for me as an experienced user, but is certainly overwhelming for the "normal" computer user.
GNOME is trying to de-mystify the Linux desktop and I think they're on the right track, but they don't have widespread support among the Linux community. A lot of people use and/or like it, but a very vocal group (is it a minority? I don't know) is opposing their approach. They (this certain group that's well represented on e.g. /r/linux) sometimes seem to dismiss any work on UI or UX as not relevant or limiting their freedom.