altfredd

> GOPATH and modules mean that the tooling has to handle two different cases...

No, the main thing, that GOPATH meant, is that Google (and everyone else) had to make their Go libraries open-source — since entire logic of GOPATH revolves around building stuff, downloaded from Github.

Once Google management decided to be serious about pushing Go to masses, they hurriedly rushed to erase GOPATH from history (just like they erased "Don't be evil" slogan from Internet after getting serious about doing business).

> Not all webservers support/enable it

Could you provide an example of server that does not?

AFAIK, Range is supported by all major CDNs, so not supporting it in web server would be a death knell for it's real-world adoption.

This is a slippery slope fallacy. Your government has enough power to detain and execute you. Does that mean, that you should give them even more power?

Even if one OS component (Google Services) is centrally controlled and can be used to attack you, this does not mean, that you should make other parts less secure. Real-world attacks are complex and backdoors are fragile and prone to being detected. Embedding a backdoor in proprietary code of Google Services is easier than embedding it into AOSP. Hijacking a specific application is easier yet.

This isn't about Google's control over OS. Of course, Google fully controls Android it, so they can compromise it anytime. But if such compromise gets detected, Google will lose trust.

The move away from developer signing towards Google's signing will makes it harder to detect such event.

> in theory, since Google controls the OS, it can also make it lie to you

Google controls Android, but it does not control every other OS and every piece of hardware.

If someone downloads an apk with their own custom Google Play client, running on their own computer, they can check whether it was tampered with. In the past a tampered apk from Google servers would have been signed by wrong key (because the proper key is controlled by developer), pointing to Google as culprit. Now it will be signed by "developer's" key (shared with Google), creating plausible deniability for Google and US intelligence services.

> "Super Secret Messaging App" asks the OS to load encrypt.so, its custom encryption library, and the OS can deliver a no-op library and say "Here it is!". The app wants to check the file's hash, the OS can intercept the hash method's return value

This sounds extremely labor-intensive. Who will write all those no-op libraries? Who will pay for it?

SQLite can promote connections, but it does not demote them back to read-only. As I understand, when a database connection is tainted by a single write, it's lock on SQLite file in promoted to write lock, which prevents other processes from opening any kind of connection to it.

Our Django setup needs multiple processes to work around the Grand Interpreter Lock. Disabling connection reuse in Django config slightly changed the behavior we observed, but didn't solve the performance problem.

> you can have any number of concurrent readers, but only a single writer

Only if your readers and writers are cleanly segregated.

Most languages and web frameworks don't have SQLite drivers out of box (or have extremely bad ones). Unlike SQLite, most databases don't really care about distinction between read-only and writable connections. So there is a good chance, that you will always open writable connection by default, because this is what your framework/ORM does. Furthermore, seemingly read-only web middleware often ends up writing to database on each request for one reason or another. If you try to reuse/pool connections (which is also important under high load), you need to be wary of keeping open writable connections in cache — again, something that does not matter to all major databases other than SQLite.

I was involved in maintenance of a small web app (db size < 5 Mb), written in Django, that had to serve ~1000 dynamic requests per second (the contents of each response were dependent on IP address of caller). The app worked with PostgreSQL, albeit poorly, but immediately ground to halt under load with SQLite — which was our default database choice for historical reason.

We ended up briefly caching results of most database queries in memory, which removed most of load from database (we also did a lot of other optimizations, but this was the decisive one). Eventually the app was able to withstand up to 9000 requests per second, but none of that was an achievement of SQLite — we just evaded database, Django and Python altogether on majority of requests.

While we are on this topic, the most widespread OS in the world, Android, also has extremely low-quality SQLite drivers — despite shipping SQLite as default database for many years. Android has a broken-by-design Cursor implementation (the devs admitted it themselves [1]), that always tries to count query results, even if you don't call getCount(). And a broken connection cache, that does not support read-only connections [2] (that method used to have a "TODO", but eventually they forgot, why they wanted it, so they removed it).

1: https://medium.com/androiddevelopers/large-database-queries-...

2: https://android.googlesource.com/platform/frameworks/base/+/...

> you end up doing a lot of horizontal scaling to read block quotes

what block quotes?

Linux entropy pool is designed to accept and mix different low-quality entropy sources and has explicit workarounds for problems like these.

Systemd is literally the only software, that has this problem. I am not aware of any other software, that uses rdrand and expects high-quality cryptography-grade randomness. Precisely, because is does not work. Intel CPUs used to have very similar issues with rdrand and so did AMD. Furthermore, CPU implementation of rdrand is a very attractive targets for state backdoors, so most sensible developers either follow the "GNUPG way" (ask for randomness from user) or simply read from /dev/random.

The rdrand instruction is great for games, because it allows to make white noise without complex algorithms and system call overhead. It is also handy for few situations, like interrupt handlers, when you needs to create some semi-random value without using stack space or calling into outside code. Unfortunately, when it was introduced, rdrand was documented to generate "cryptographically strong random numbers" (did Intel developers ever knew, what that means?) Of course, most actual cryptography experts didn't buy into that. As a consequence, and because multi-platform software needed to have it's own RNG anyway, the instruction remained largely unused for actual cryptography. Unused = untested and sometimes broken. If I were in systemd developer's place, I would not hinge bootability of my systems on something like that.

It seems, that many RedHat developers have rather unique world views.

When PulseAudio introduces random crackles and scratches in sound output, they claim, that I have a misbehaving sound card. It does not "misbehave", when I use the same applications with ALSA, but whatever.

When rdrand fails to produce high-quality entropy — again and again, over and over — Poettering complains about buggy CPUs.

I hope, that this particular group never ends up working on network hardware.

Orwell's book actually described 3 super-states, all of which share same ideology and, presumably, have their own "ministries of truth".

> Shouldn’t those offenders face jailtime instead of censorship when inciting violence?

How can they face jail, if they are FBI operatives, acting on direct orders?

I means, are we supposed to believe, that FBI — the same FBI that surveils entirety of Internet and have backdoors in FAANG — fails to catch a whiff of ongoing revolts?! And police just yields Capitol to bunch of protesters?!? And they say, that Russian FSB is heavy on theatrics...

In my experience, descriptions of the so-called "foot cannons" within Git are exaggerated by people, who don't understand Git and didn't use it much.

It is virtually impossible to lose data, committed to Git. Between reflog, lazy garbage collection and ability to grep history for strings there is literally no way to corner yourself. I have never lost anything after years of using Git. Meanwhile, I have lost data at least once with most conventional filesystems and storage mediums: f2fs, ext4, ntfs, hard drives, SSDs, CDs, VHS tapes...

Incidentally, when I tried to use Mercurial once (because the job demanded it) and immediately went for Mercurial Queues, the bug in implementation of Queues caused me to actually lose some data (an insignificant amount, but still!). Unstable internal storage format + implementing history editing via third-party tool = bad news.

You have forgotten to type a handful of zeroes...

> What are the state-actor-level attack implications of this? Before this was revealed, a party that compromised (or was able to be issued) a certificate for a website could be reasonably likely to be detected and have that certificate revoked

This is a convenient fiction. CA system never protected anyone against state actors. Never did, never will. Subverting a single CA is enough to compromise entire system. And there are hundreds of them.

Security is always grounded in knowledge and physical control — understanding and exercising your capabilities to preserve them. A blind, deaf and fully paralysed person can't be expected to safeguard their own physical security, and neither can an average user — their TLS security. Especially against state actors. More so, when the parties they have to rely on are commercial enterprises whose entire existence revolves around getting paid to issue certificates.

> There is no intrinsic reason that "AJAX" apps need to be slow -- you can do a database roundtrip in less than 10ms.

This is a wishful thinking. You can't expect consistent 10ms (or even 100ms) response times from network-driven autocomplete. Nevermind a fixed speed of light (which already makes 10ms figure impossible for transatlantic users), you will have to account for all kinds of temporary bottlenecks in network. DNS can take a lot longer than 10ms, and many hosts use short DNS TTL by design. There are some totalitarian countries (Belarus, Great Britain etc.) that use DNS-based website blocking — each time you send a DNS request, it will have to be compared against a bunch of censorship lists. Then there is an ISP throttling/AQM, that will add small delays to each SYN packet... As result, if your autocomplete responds in under 10ms during local testing, it may take between 100ms and 900ms for most of your users.

> Which completely overlooks how bad search results were 20 years ago compared to now.

Care to elaborate? Do you have examples of today's "good results" as opposite to "bad results" of old?

> It’s just that all the stories I’ve heard about Ransomware in the past ask for sums of at least $500, often much more.

That's when they target corporations and governments. Such small amounts are nothing when those are concerned.

Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.

According to the article, Amnesty International assumes, that the Journalist in question was targeted by http-MITM attack. This assumptions nicely fits into popular "http is bad, https is good" narrative, but it is just a guess (and probably is far from truth). Modern browsers support multiple network code paths, several HTTP versions, dozens of TLS versions and boatload of ciphers. All of that code has RCE bugs.

Besides, delivering vulnerability payload via advertising network is far more reliable — with http-only exploit chain police would have to wait and hope that Omar will someday visit an http-only site. I would expect a pricey exploit toolkit, used by governments, to be more robust than that.

If your primary use case is Linux, xpra is very good.

Unlike RDP, xpra defaults to passing over individual windows — it acts as windows manager for it's own Xorg process on server. This can completely side-step the hassle of wrapping and interacting with existing desktop environment, it's login screens etc. Xpra uses unmodified Xorg server from your distribution with xf86-video-dummy driver to achieve this. Mirroring existing Xorg session is also supported (but slower).

The actual alternative is PhantomReference, which exists since ancient times. Cleaner simply provides safe way to use PhantomReferences, which are rather tricky to use (by Java standards).

Impact of Android 10 on Termux usability is already old news.

What worries me more is behaviour of Termux developers. They make dubious claims and effectively sabotage their own application (more on that below).

The solution to Android 10 problems — a software wrapper called "proot" [1] — has already been found. That solution would allow to keep all of Termux functionality and preserve existing package managers (such as apt). Proot allows Android user to compile C code in Termux (which they currently can do) and does not require major changes to Termux itself.

Termux developers refused to adopt proot as solution and even removed it's mention from their wiki on Github. Instead they are insisting that all Termux packages should be distributed in Android apk files, published on Google Play. That "solution" has major usability issues, does not scale (it uses shoddy Android PackageManager to track all Termux packages) and would prevent users from using Gcc and other compilers in Termux. The only claimed upside of using apk files is that it would better comply with Google's policies.

Termux developers justify their actions by following arguments:

1. Termux packages require a lot of bandwidth to host, and Termux does not have money to pay for their mirrors; hosting packages in Google Play would be preferable. That statement is nonsense — even fringe Linux distributions like Artix can find FREE mirrors, willing to host their packages. This is usually done by contacting curators of existing servers, that host Linux packages, and asking them for support. Termux is more popular than some of Linux distributions, but it does not look like Termux devs even TRY to do that — they apparently just sit on their hands, occasionally begging their sole mirror provider (JFrog) for more bandwidth.

2. Termux currently does not comply with Google's policy and it's developers are afraid, that this will result in removal from Google Play. They are technically right, but they are making mistake by downgrading experience of their app in attempt to pacify Google Play censors. They are making even bigger mistake by displaying guilt about that — Termux does nothing wrong, and the display of guilt is a better excuse to punish them than their actions.

1: despite it's name, proot does not require root access

> If this flag is specified, the preadv2() system call will return instantly if it would... wait for a lock.

Doesn't this sound a bit different from ordinary short reads?

Receiving EAGAIN usually happens under fairly specific conditions (signal interruption), but I'd imagine, that filesystem code has a great deal of locks.

For example, FUSE filesystems can support signal interruptions via EAGAIN, but they are not guaranteed to. You can end up in situation, when FUSE filesystem hangs, and you can not interrupt the thread, which reads from it. I suspect, that RWF_WAIT is a "fix" for similar situations and not the opposite of default behavior.

> A search engine is optimizing for billions of queries. Most of which are on the long tail.

Citation needed.

As far as my personal observations go, Google is NOT optimized for long tail at all. It is always trying to return most popular results from cache of most popular results. Once the cache is exhausted, Google starts to return completely irrelevant trash (anything after first two pages of search is pure spam and meaningless keyword soup).

If you try to look up some obscure keyword and find nothing, try again after couple of months. There is a very high likehood, that you will see dozens of "new" results — most of them being from several years old pages. Perhaps, the actual long-tail searches still happen somewhere in background, but you are not going to see their output right away — instead you need to wait until they get committed to the nearby cache.

Another alarming change, that happened relatively recently (4-5 years ago), is tendency to increase number of results at expense of match precision. A long time ago Google actually returned exact results when you quoted search phrase. Then they started to ignore quotes. Then they started to ignore some of search terms, if doing so results in greater number of results. Finally, Google gained horrifying ability to ignore MOST of search terms. OP's example probably has the same cause — Google's NLP knows the meaning of word "without". But Alphabet Inc. can't afford to hose all those websites, that use AdWords to sell you STRIPED SHIRTS. This would mean a loss of money! THE LOSS OF MONEY!!!

> there is no real-time dependency on online systems for use of physical currency

You are underestimating degree of our reliance on banking. Stores, restaurants and repair shops don't have enormous vaults with cash — they store money in bank accounts. If banks make cash transactions infeasible, businesses will suck it up. If your local coffee shop stops accepting cash, you will have to find another one, possibly located in different district (or even different country...). Many countries enforce mandatory use of bank accounts for business — companies are literally not allowed to operate in pure cash. When banks conspire to make cash undesirable (via high cash collector fees, shunning low-denomination bills etc.), local entrepreneurs begin go "cashless", a trend already seen in many places.

Never mind that, ­— even if your local legislators force shops to accept bills, who cares about them? Brick and mortar stores are deteriorating all around the world. A lot of things already can't be bought offline, unless you take an international flight each time you want to purchase. When your local electrical parts shop closes down, will you open your own? Or just order parts online and pay with VISA like everyone already does?

In not-so-distant future you will be able to spend your cash on bread and not much else. Until the backer becomes unable to spend his.

No, Spectre is always about reading your own memory. Your link is about exploiting MDS aka Zombieload — a separate hyper-threading vulnerability, specific to Intel CPUs.

AMD does not "patch" Spectre. Spectre has to be patched by developers, who execute untrusted code within the trusted address space (e.g. browser and OS developers). I am taking AMD press release to mean, that this "attack" — note how researchers consistently use this word instead of "vulnerability" — is simply proof-of-concept for well known Spectre flaws or possibly even expected behavior of the CPU cache (in non-SMT case).

Many Spectre-type flaws are essentially about an OS process reading/writing it's own memory — which it is naturally expected to have access to. Of course, browser developers weren't prepared for that, but they also were not prepared for gzip-bombs...

I assume, that mitigations [1] suggested by AMD in 2018 are sufficient to protect against this (and all other) Spectre flavors on AMD CPUs, in which case there is really nothing new going on here.

1: https://developer.amd.com/wp-content/resources/90343-B_Softw...

> Do you know of an example of an attacker "easily demolishing" Cloudflare's free DDoS protection

I can name dozens of websites, that folded under Cloudflare's supposedly flawless DDoS protection (at the time when they were still using it). Of course, the ones who fold are always websites themselves — Cloudflare itself is never affected, because when the DDoS gets particularly bad, they just detach websites from their CDN and expose it to attackers.

> why are relational databases not able to tell you how many rows are in a table without a full table scan

This is unrelated to database being relational or not. Any mutable database will have hard time with that challenge.

Can you remember how long you have lived in seconds? In milliseconds? Why are you not keeping track of such obviously useful information?

Of course, it is theoretically possible to create a database, that can count rows very quickly — under very specific conditions. Are week-old results acceptable? What about year-old results? A nanosecond-old results?

Locking is hard. Your computer has multiple CPUs, which constantly execute out-of-order instructions, — such as other transactions, mutating the same table. In order to count results of read operation those CPUs will have to take a stop (no matter how insignificant) and agree on linearity of events. Some of CPUs may have to perform pending work (such as sending recent transaction contents over PCIe bus) before they declare themselves ready to sync. In the worst case you may have to wait for some preempted threads to be brought back to life by OS scheduler. And you have to do that during every read — otherwise your results will automatically be outdated!

If you can accept outdated or outright invalid results (duplicates, remains of incomplete transactions), you can always use weaker DB transaction isolation level ("READ UNCOMMITTED" etc.) or simply cache results in Redis/Memcached. But for obvious reasons that isn't a default.