Sure you can. The services just need to agree protocols. The tech & cryptography part is not difficult these days. We've had guaranteed E2E for email since PGP in 1991, though not many people cared enough to use it.
None of the services you listed do it, but that's because they don't want to, not because it can't be done. It's a business decision problem, not a technical problem.
It's also a technical problem, the overall security model of these apps isn't just the E2E encryption, but e.g. Signal not saving attachments to local storage, message expiry (which inherently requires clients to cooperate).
Actually, F-Droid has quite strict requirements on the apps it will accept, and it enforces them.
Low-effort spammy apps with ads and in-app purchases are unlikely to be accepted.
Standard Android in-app purchases, efficient notifications, or ads which use Google services, won't be accepted at all, though FLOSS versions of those things are ok in principle.
> All applications in the repository must be Free, Libre and Open Source Software (FLOSS) – for example, released under a GPL or Apache license.
> Every effort is made to verify that this is actually the case, both by visual inspection of the source, and by building the application from the published source.
> We cannot build apps using Google’s proprietary “Play Services”.
> We cannot build apps using proprietary tracking/analytic dependencies like Crashlytics and Firebase.
> We cannot build apps using proprietary ad libraries.
> The source code for the application must be maintained in a publicly accessible Version Control System which we have support for
> The original app author has been notified (and does not oppose the inclusion).
> one of the reasons WhatsApp has done so well is that they basically supported every platform under the sun
Not really. There's still no iPad version.
My friend installed Whatsapp from the App Store for their iPad, to find it didn't behave quite as expected, and didn't match their phone and desktop experience.
That turned out to be because it was an app from some random third party with its own features. It used Whatsapp in the name, and had a similar logo.
When my friend realised they were unexpectedly using a third party app, from a provider they'd never heard of, they were worried they'd accidentally given away access to their account full of sensitive messages to someone they didn't trust.
I was surprised my cautious friend would install the wrong app by mistake, as the Apple app store is normally good for well known services.
While scrolling through Whatsapp apps, it took me a while to realise the top search result, which my friend had installed, wasn't actually from Whatsapp (but looked similar). Even though the logo was a little different, I assumed that was just a quirk. It's just so unexpected to find that what you get on iPad isn't the real thing, when searching for Whatsapp gets you the real thing if you're looking from an iPad or Mac.
Linux in Android is GPLv2 not GPLv3. The v2-v3 difference is a big deal to some.
Linux developers made an intentional decision to stick with GPLv2 and to remove the "or later version" option, so you can't include it into GPLv3 projects as you can with most other GPLv2 software.
GPLv3 avoidance is why Apple ships ancient versions of Rsync, Bash and Make on its current OSes instead of the current versions, and replaced Samba with its own inferior SMB service.
The gprof profiler was used long before 1993. It dates back to 1982.
I did game engine dev professionally in 1994 (and non-professionally before that). We profiled both time and memory use, using GCC and gprof for function-level profiling, recording memory allocation statistics by type and pool (and measuring allocation time), microbenchmarking the time spent sending commands to blitters and coprocessors, visually measuring the time in different phases of the frame rendering loop to 10-100 microsecond granularity by toggling border or palette registers, measuring time spent sorting display lists, time in collision detection, etc.
You might regard most of those as not what you mean by profiling, but the GCC/gprof stuff certainly counts, as it provides a detailed profile after a run, showing hot functions and call stacks to investigate.
It's true that most of the time, we just changed the code, ran the game again and just looked at the frame rate or even just how fluid it felt, though :-)
But was that in Watcom? I don't think gcc was on DOS until DJGPP v1 which was...1992? I don't remember if gprof was ported. iD did use DJGPP for Quake in 1996.
I'm guessing they used gcc on NeXT but profiling that platform probably didn't make much sense, different compiler, different CPU, different OS...
The game was written on a TurboColor which had a Motorola 68030 (?) that ran at 33MHz and supposedly only ran at 15FPS (probably as slow as a 386DX/33 at the time)
I was a game engine dev at the same time. We definitely profiled heavily. Microsoft had a profiler of some sort, and I believe we had a third party one too.
The compact one-liners below are similar but avoid adding duplicate items to PATH, so are fine to call in various init scripts.
In Bash:
path_append() { local p; for p; do [[ :"$PATH": =~ :"$p": ]] || PATH+=:$p; done; }
path_prepend() { local p; for p; do [[ :"$PATH": =~ :"$p": ]] || PATH=$p:$PATH; done; }
In portable POSIX shell:
path_append() { for p; do case :"$PATH": in *:"$p":*) ;; *) export PATH="$PATH:$p" ;; esac; done; }
path_prepend() { for p; do case :"$PATH": in *:"$p":*) ;; *) export PATH="$p:$PATH" ;; esac; done; }
> once you can get a startup off its feet, the VC money from seeds easily makes up for that downtime
The depends a lot on the startup. Many startups don't take VC money.
Of those that do, in my experience as first non-founder employee, the founders were paid very little compared with employees, on the hope of future success with their equity instead, even after the startup got decent pre-seed and seed investment. Both rounds of investment were enough to pay some key employees well, but not to pay everyone well for long enough. So the founders felt they has to continue with low pay for themselves.
If I want to download a multi-hundred-gigabyte anything, I switch to my mobile and turn on it's Wi-Fi hotspot. It's a really noticable speed improvement, with the caveat that speed varies a lot according to location and time of day.
My phone, a mid-range Android from 3 years ago, usually downloads over 4G much faster than any of the wired or fibre networks I have access too, including the supposedly newly installed dual fibre links at work, or the "superfast broadband" zone at my local library. It's also much faster than the 4G router at home.
I've downloaded terabytes over my phone, including LLM weights, and my provider's "unlimited" data plan seems fine with it. (They say 3TB/month in the small print.)
I just heard of it from this thread and took a look. It looks great! I'd love to get one, but from the FAQ:
> "The only apps that won’t work are ones that require the full Google Play Store and all it’s requirements. This includes some banking apps"
Sigh. It looks like I'd have to carry two phones.
Banking and credit card apps are essential daily apps for me. I can't even log in to some of my accounts on a desktop browser without their phone app to authenticate, and quite often individual payments require phone app confirmation. Unfortunately I'm not in a position to switch accounts for a freer user experience.
Separately from finance, I also have to use the Google suite for my main job, and I've had to use Discord for another job. I guess those can run in a browser with reduced functionality, though. Not so for the banking/credit card apps, unfortunately.
This isn't a complaint about Waydroid or FLX1. I appreciate the work and creativity! I've long dreamed of owning (and building) a completely FLOSS phone, and seen how much work is involved. I owned two Nokia N900s back in the day.
But times have changed, and I wish and hope a way can be found to run the apps or protocols daily life seems to require now, on top of (or side by side with) a base FLOSS system.
const is different in C++ from const in C. const variables in C++ are proper compile-time constants. In C they are not (the nearest equivalents are #define and enum values).
So in C++ "const x = EXPR" would make sense to request compile-time evaluation, but in C it wouldn't.
Ouch, but thanks. I learned something today - something I'd long forgotten. I like your example, it shows the point well. (Though, there are circumstances when a compiler can unroll such a loop and infer a compile-time constant, it wouldn't qualify as a constant expression at the language level.)
It's been so long since I used C++ for serious work that we weren't using C++11, so neither auto nor range-for were available. It would be uncommon to see "const type = " with a non-reference type and a non-constant initialiser.
Even with your example, some styles avoid "const auto item", using either "auto item" or "const auto& item" instead, because the "const" matters when taking a reference, not so much with a copy.
But I appreciate your point applies to const variables with non-constant initialisers in general, in the language.
There was once a big deal in literature about const in C++ being the "better" alternative to how #define is commonly used with C for constant values, and it seemed applicable to the thread as a key distinction between C and C++, which the parent commenter seemed to have conflated by mistake.
But I'd forgotten about const (non-reference) variables accepting non-constant initialisers, and as I hadn't used C++ seriously in a while, and the language is always changing, I checked in with a couple of C++ tutorials before writing. Unfortunately those tutorials were misleading or too simple, as both tutoruals said nothing about "const type x = " (non-reference/pointer) being uwed in any other way than for defining compile-time constants.
It's bit embarrssing, as I read other parts of the C++ standard quite often despite not using it much these days. (I'm into compiler guts, atomics, memory models, code analysis, portability issues, etc.). Yet I had forgotten this part of the language.
So, thanks for sending me down a learning & reminder rabbit-hole and correcting my error :-)
None of the services you listed do it, but that's because they don't want to, not because it can't be done. It's a business decision problem, not a technical problem.