altfredd

It's pointless to provide examples, because Google will quickly "recall" anything that is being searched by multiple different people.

Unfortunately, it is no longer possible to use Google Search for searching in Internet. You are only allowed to look up viral memes and query neural networks, trained by other people's searches. Searching for rare and unique things will quickly get you banned. An interesting side-effect: using modern Google to check if name is vacant is meaningless. I used to google for names to see, if something else used them, but Google's search repeatedly returned me 0 results, even when there were multiple pages with that particular name in title, many of them years old. Searching for the same thing couple of weeks later have suddenly returned hundreds of hits.

I wonder, how much it costs to actually query Google's database instead of some distant neural network approximation. Apparently, Google's own employees can't afford it anymore — some of them are using DuckDuckGo instead (they even added it to Chrome, lol)

Sussman isn't "getting edits approved". He is literally bribing other editors in open.

Ever wrote anything on Wikipedia talk pages? Unless you are commenting on article with hundred thousands of daily views, your comments will remain ignored for years. Nobody is going to "implement your suggestions" or "accept corrections", —at best you will be ignored, and at worst you will be told to f##k off in Wikipedia's politically correct newspeak.

Who are the people, implementing his changes to pages? A certain number are of course bots and sock puppets. But relying on those exclusively is risky, and he would eventually get discovered and singled out by mods and check-users. So some of his editors got to be real people. Does he have an actual team of editors working on keeping articles updated full time through series of proxies? Probably not, — would be too expensive and also prone to ban.

Let's perform a mental experiment: you are a poor sod in Cambodia/North Korea/Thailand etc. who have recently discovering a beauty of Wikipedia. You look at the talk page of "Facebook" article and stumble upon comments of some guy, who says, that he is a representative of dedicated PR company. You make some quick calculations: your daily wage is several orders of magnitude smaller than average US wage, and the guy is probably getting paid A LOT of money by Facebook and the likes; going to darknet to regularly buy a new bunch of "proxies" (hacked computers in US residential areas) will costs you $XX per month; if you get him to pay you $YY, the rest of money will be your net profit...

You can guess the rest.

It is not: https://danielpocock.com/what-does-democracy-mean-in-free-so...

The current Debian "developers" have reached uniform agreed that:

1) Neither of them will participate in election

2) People outside of "developer" circle (including major contributors, who do most of actual work on Debian) can't participate in election

The whole "crisis" is artificially created. Not like that matters, — most of decision making is already done by corporate employees, not some fictitious "community leader".

He isn't necessarily lying, and there won't be a lawsuit.

The "self-driving" will be made available, both in hardware and software. It just won't be usable on roads (because every state will immediately outlaw it).

Few owners, brave enough to try it in spite of regulations, might discover some notable flaws... But hey, — no one promised you a perfect self-driving! You will be able to "self-drive" in couple of dedicated cities or around wilderness in the middle of nowhere (with modest risk of damaging vehicle), and that's supposedly what everyone has paid for. Musk won't be held responsible for restrictive laws, — he most likely anticipates that and hopes precisely for that.

> This is (RFC) valid JSON:

You mean, "valid, according to the latest 2017 RFC". Such young RFC is still to raw, too immature to adopt, especially if it concerns data interchange formats. IPv6 was created in 1995, and it apparently still too young!

I fear, that a proper full-featured JSON spec, with comment support, mandatory UTF-8 and strict prohibition of hex-encoding won't be created and implemented by most JSON parsers till at least 2090. At that point the JSON format itself will likely become insufficiently hip for general use (just like XML suddenly stopped being hip enough in early 2000's).

The article seems heavily influenced by author's personal preferences.

He starts from presenting false dichotomy (bit stream vs self-documenting text) and proceeds to apply his personal experience with proprietary GPS trackers to well-documented NTP protocol. He describes his favorite approach without mentioning it's downsides — and that approach is JSON! JSON!

By design, JSON format lacks any capacity for extensions. It's creators figured out, that backwards and forwards compatibility is more important that anything else, so they froze the specification at version 1 and refused to introduce new features or extension support. And thus JSON can't...

1) contain comments;

2) properly encode non-Latin text (no, — hexadecimal encoding is even worse than no encoding);

3) have more than one top-level element;

4) have any data types, except ones in JSON spec.

Each of those limitations has lead to creation of at least one incompatible JSON-like format, that can't be processed by spec-compalient JSON parsers. Pick a random piece of JSON from the wild, and you may find, that it isn't actually "JSON", but one of those quasi-JSON formats. To make matters worse, JSON spec didn't mention maximum supported number size/precision, so JSON payloads from one implementation may not properly decode on another implementation.

If he wants to design JSON-based NTP protocol, he is welcome to do so. But widely adopting such thing would be unwise — we already suffer from traffic amplification attack via NTP, and bigger packet lengths would make those worse.

> It is a shame that you are being downvoted. I (like a lot of people here) disagree with you, but you have a point of view shared by a lot of people.

People are notoriously bad at acting in their own best interest. I recall reading a forum, where a guy asked for medical advice, because he was diagnosed with fibrosis (his lungs basically got scarred all over). His work required him to continuously inhale toxic exhaust, and he wanted a way to avoid further health complications (but keep a work!) because "the pay was good".

Fibrosis causes you to cough non-stop and significantly increases probability of dying from lung infection. Compared to that, using Google's products does not result in any visible long-term effects on health. Therefore, it is natural to conclude, that using Google's sites and services is safe, healthy and should be widely encouraged. It does not matter, that Google uses anti-competitive practices to monopolize market, restrict user freedom and lead us to future, when we won't be able to refuse shoehorned "services", shoved in our face, right?

Please stop with those creepy "understanding" antics. Encouraging self-harm is bad, and wishing to view advertisements is definitely a form of self-harm.

I got the "love", because it was (and still is) advertised on google.com. Most non-technical people readily install malware when prompted. If malware is advertised on google.com, they will install it more quickly.

Microsoft have been stalling IE development for years, which allowed Mozilla to gain huge marketshare. This resulted in a lot of people learning, how to install a third party web browser. By the time Chrome was unveiled, Mozilla have coincidentally slowed Firefox development to a crawl. I remember the point, when the stable Firefox version was close to unusable, while everyone technologically proficient used a development release. It have been so bad, that some addons simply recommended not using the stable Firefox version. Btw, things have only gotten worse since then.

Chrome's dazzling success is result of it's aggressive advertising as well as sabotage and mismanagement, that killed off alternatives.

> Those arguments are invalid.

Your individual statements are correct, but they do not add up to valid argument in this case.

Kazakhstan forces their citizens to install government-issued certificate to use SSL. This allows Kazakhstan to track their citizens. Which proves, that a regime can track it's citizens even in presence of SSL encryption. In other words, using SSL/PKI does not inherently prevent tracking by powerful entities. You need to create your own government for that.

It is naive to think, that regimes like egypt/syria/US can't track people, while at the same time being able to exert overwhelming physical force over the exact same people. If you can force someone to hand over encryption keys, you can track them. Different countries do the same thing, everyone just picks their preferred ways: physically controlling Certificate Authorities in case of US, handing over encryption keys in case of Great Britain.

> Compare that to yum/rpm which use secure https and signed rpm and signed metadata

No, using more "secure" technologies does not amount to better security.

> you are now letting everyone know what possibly vulnerable packages you have.

Erm, what?

The number of people, who can listen to (much less — modify) your traffic is very small. It is basically your ISP (who is supposed to offers you services in good faith, not spy on you) and a number of engineers, who maintain Internet backbone. That's far from "everyone". Some SSL evangelists make it sound like everyone's traffic is permanently broadcasted to everyone else in the world, but it is not.

As for "vulnerable packages", the most certain sign, that someone does not install security updates, is lack of traffic between them and update servers. But that's orthogonal to use of encryption.

Actually, you can. This is called "spam".

When someone stops visiting your site, make sure to send them a email. Ask them to return! You have their email address, right?

The real answer is that releasing source code means uncovering (some of) their cards. The company, that relies on selling identical hardware under vastly different prices, won't ever do that. Using game-specific speed-hacks to "fix" games, purposefully written to violate standards, is another issue. Especially, when those games were made with help of Nvidia engineers. Why give up such ability?

I also suspect, that they make use of multiple patented technologies, both in hardware and software. When Java has been re-licensed to GPL, one of the most prominent pain points, that caused endless whining on part of OpenJDK users, happened to be it's font renderer. And we all know, that font smoothing is tricky business, and all font-smoothing tech in existence is patended by MS/Apple/Adobe. When you start replacing closed-source code with free replacement, those patented pieces tend to quickly come up — especially when open-source projects go to great length to work around patent issues instead of shoving them under the carpet.

"Nouveau and amdgpu were always barely working" — nah, you are spreading misleading information and lumping together completely unrelated projects at different stages of development.

Noveau has been almost close to usable at some point... Until Nvidia started the whole signed firmware nonsence. Then it quickly became intolerable due to Nvidia, supplying no signed firmware or heavily crippled firmware. These days you are actually better off using software renderer/llvmpipe (which at least might benefit from a powerful processor). "amdgpu" is a name of the modern AMD kernel driver, that replaced "radeon" driver. Both drivers were developed with direct help from ATI/AMD. Unlike it's older predecessor, current amdgpu versions include the "display core" code, that was designed to be shared between Linux and Windows AMD drivers (not sure, if that part has worked out yet). All Linux drivers for currently produced AMD cards are open-source, both kernel and userspace parts. AMD also has a "value-adding" package, that is based on their own userspace driver (which is open-source) and simply adds few closed-source components to it.

"amdgpu" is not barely working — AFAIK, it is the only currently available AMD kernel driver, and it worked great for me, both 2D and 3D.

"Other app stores" do exist, but Google went to great lengths to destroy them. Publishing clients for alternative stores in Google Play/Android Market have been prohibited by Google's ToS for years (don't know if it is still prohibited). The "allow alternative app sources" checkbox (unchecked by default!) has been deterring users from installing from non-Google sources till Android 8. It still exists, but Google have ruled, that third-party marketplace apps are better than malware-riddled piracy websites, so Android 8+ allows to whitelist specific marketplace apps while still keeping the checkbox unchecked. And let's not forget about Google's war to banish alternatives to their services from Android devices, while using their own Google Services packages as leverage.

Google's overall approach to building it's walled garden is not much different from Apple's. They give some fake "choice", because they know, that tech-illiterate consumers won't be able to make use of alternative options.

Isn't "keyless entry" basically same concept as "not locking a door"? You can trivially implement it on every vehicle without using any electronics at all.

There is nothing wrong with publishing rewritten package with same name under full supervision of original developer. Transferring control generally implies full trust, and Dominic haven't established any trust with new developer. He didn't even ask them for their real name!

NPM repository is not "open source community". NPM is controlled by commercial organization ("npm, Inc."), which is fully capable of establishing rules, preventing package authors from selling to black hats (or even gifting for free to black hats). The author of the package could have formally given his Github repository to new maintainer without transferring package control . He didn't. Why? — presumably, because there is nothing in NPM ruleset, preventing him from doing so. It does not matter if he was bribed or not — there is an obvious glaring hole in notion, that widely-used digital assets may be covertly "gifted" to third parties.

This isn't the first time that has happened — the story with Google Chrome extensions being sold to hackers should have tought NPM, composer etc. a lesson. Maybe someone should finally sue them to drive the point home?

I don't believe, that Dominic (the former maintainer, who gave the control of package to complete stranger) is the sole party to blame here. The biggest responsibility lies with so-called "administration" of NPM, who have systematically failed to promote security and robustness in their package system.

The practice of handing control of open-source packages to new maintainers is old and well-established. You can go to Sourceforge and request to take control of any old, low-impact, unmaintained repository and Sourceforge administration will likely grant it to you after a considerable delay and some investigation (at least they used to do so in the past, not sure if they will continue to after all this mess). The responsibility to ensure, that new versions of packages haven't been subverted by malicious actors, have always lied with people, who brought those packages into distribution — the package maintainers. Unfortunately, NPM does not have any "maintainers" in the traditional sense — package authors can't be trusted to remain impartial, and "administrators" just sit on their backs, waiting for devs to fill their repository with quality software. There is zero oversight — you can do anything with your packages as long as it does not outright contradict local law, including openly selling them to hackers, openly incorporating backdoors, and even sabotaging entire package ecosystem by unilaterally deleting hundreds of popular packages.

Covert transfer of control should not even be possible in centralized repository like NPM. If you want to give your package to someone, that act should be registered with repository administration, and future users of package should be warned of it — just like users of services and goods are commonly informed when an existing company changes it's organizational structure. It is one thing to privately give access to Github repo to someone. It is entirely different thing to hand over a repository package — which is automatically distributed onto large number of computers around the world. In later case authors, who failed to announce the change of ownership to repository maintainers, should bear full monetary responsibility for their actions.

The most alarming part about this story is that DeepMind's involvement is largely unneeded and their "accomplishments" are superficial to say the least:

> DeepMind Health went on to work with Moorfields Eye Hospital, with machine-learning algorithms scouring images of eyes for signs of conditions such as macular degeneration

Sorry, but "scouring images of eyes for signs of conditions" on a scale of single hospital is a task for two CS graduates, easily accomplished with freely available machine learning tools. The hospital in question could have done that themselves at minuscule cost. Are UK hospitals legally prohibited from hiring non-medical staff or something? Instead they are partnering (conspiring) with international companies to... do what again? Write Android apps and feed images to neural networks? In exchange for their entire medical data??

Is UK becoming another India or something?

I have a heavily-patched version of less-popular sandboxing program (appjail). When I want to handle some files from questionable origin, I create a directory (~/jailboxes/gregs_avi_files) and use appjail to switch to that directory in terminal. Unlike firejail, appjail defaults to full $HOME isolation (and have knobs for Xorg support, so X11 apps work out of box without access to parent /home). There are command-line switches for X11-based and pure terminal environments. It is also possible to whitelist/blacklist individual files in /dev etc. from command line.

I don't use Flatpak etc. — all of my jails use system-wide libraries and executables. They are just launched inside sandbox environment.

Well, I have used it for years, and never encountered any issues. If you want to share a file between sandboxes you can hardlink it. Or use descriptor-passing. Or… But it feels like you are just looking for theoretical flaws in my personal workflow for the sake of coming up with flaws.

Of course, it is silly to sandbox your bread-winning software. I don't sandbox Android Studio. Or ffmpeg. Or VLC. Personally, I believe that nobody has a right to decide, how to sandbox software on other people's computers. I think, that such decision should be left to users of that software. Unfortunately, it looks like Flatpak does not make that easy.

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop.

I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before.

Programmers like to come up with clever ways to solve nonexisting problems. I say — give user a way to bootstrap a sandboxed environment into a directory of their choice (no, using auto-generated directory names is NOT allowed!), and the "problem" would no longer exist.

Wrong. Splitting logic into separate threads is not necessary. In order to make the engine independent from FPS, you have to decide, how to handle excess/missing output. You can buffer, transform, average or simply drop excess frames. Missing frames can be worked around by repeating previous frames or reducing effective resolution (often done with a bit of blur — hi, Nvidia!). In either case there are limits to what can be achieved with those workarounds — eventually you'd have to throttle the fastest producer (renderer, physics engine or player input). All of that can be done just fine without threads — using asynchronous programming (incidentally, this is why many advanced rendering APIs are asynchronous).

Most games can simply "drop frames", when renderer isn't up to speed with engine. The result is minor loss of visual fidelity, which usually isn't too bad, unless FPS are horribly low. Things are more tricky for terminals, because 1) they need to maintain scrollback history 2) their output is more blocky, so "dropping frames" leads to horribly-looking ASCII animations.

There are some terminals, that do start dropping output, when rendered can't keep up. Others (for example, xterm) do refuse to do that by default, because they assume, that underlying program may do better job at handling low framerate, than general-purpose terminal emulator.

Either way, if you want to achieve fluid, visually pleasing rendering, you renderer should be as fast as possible.

> Content creators often look for middlemen to represent them.

Oh boy. Bees are looking for badgers?!

Content creators are looking for support and high reliability. "The middleman" can sometimes deliver those things... Until they suddenly boot you out, because their algorithm determined, that your videos don't deliver enough bucks in advertising revenue to keep them afloat.

Of course, "the algorithm" is merely poor excuse for carefully orchestrated scenario, which might have as well resulted from manual intervention (and most famous precedents are indeed backed by staff-approved decisions). Google have put great deal of effort into pretending, that their services have no support teams and no living humans behind them, but in practice places like YouTube are censored to hell and back, — and all of that censorship happens at expense of "content creators".

"Configure often detects features by compiling a binary and executing it" — I am not sure, where this impression comes from. Autotools as whole have excellent cross-compilation support. Autoconf has feature-detection routines, checking for presence of headers, exported symbols and pkg-config files. None of those trigger "execute the binary" part when cross-compiling. In addition, custom-written host-side checks can easily be skipped when cross-compiling (either by code of check itself or by user via environent-variable overrides). Do you you know of any build system, that handles this better?

Cmake and several other buildsystems either don't support cross-compilation at all (because their primary audience is Windows) or use pkg-config only. Few others are nightmarish parody of autotools with much worse support. Most don't have ounce of autotools features.

I know many projects, that offer horrible autotools "support": for example, glib2 autotools scripts can't be cross-compiled to Android without ample application of hacks. But those issues are caused by incompetence and lack of testing, not some innate fault of Autotools. When such projects migrate to something else, their cross-compilation process becomes WORSE.

This post explains it: https://news.ycombinator.com/item?id=12282894

TL;DR: modern email providers don't care if you are in blacklists. If your IP/domain does not have established reputation, they will drop half of your email in spam folder. If users whitelist it or reply to it, your reputation automatically improves.

If your send too much email or your receivers blacklist you (delete without reading or manually move your email to spam), your reputation takes nose dive. Some providers (for example, Yandex) openly describe that logic in their FAQs.

> WHOIS is extensively relied on by spam fighters like Spamhaus

Does anyone of importance still use those? Google and other major email hubs have long switched to AB testing and building user profiles as their primary filtering tools. They want to gather that data to improve efficiency of their targeted advertising, so I trust them to be good at it.

Smaller players might not have resources for that, but how do those opaque third-party blocklists help them? In the best case, those "anti-spam communities" do nothing. In the worst case, they act as data-harvesters, potentially leaking information to (lol) _spammers_. Why should we care about their future?

100% renewable as in "100% likely to be stolen or heavily subsidized with taxpayers' money".

> web apps are clunkier and provide a worse experience because they are not well supported by the OS

No, they are clunkier and provide a worse experience, because most "web apps" are ported version of desktop bloatware, targeting devices, permanently plugged into wall-mounted electric outlet.

What are "web applications" anyway? Something, that requires permanent internet connectivity? Something with DOM APIs? Something with built-in Javascript interpreter? Something with CSS support? The defining qualities of "web" have absolutely nothing to do with mobile devices. If anything, "web" has bad supported for OS. This is why all hybrid frameworks are about exposing additional OS functionality to browser, not the other way around.

Just accept, that you are looking at wrong tool for the job.

> Any full uninstall of a system app would require remounting /system as rw.

Why do Google Apps have to be installed to the system partition anyway?

I have tried several email clients and image viewers from Google's app store, — all of them work fine without being system apps.