I don't think calling it a race is all that strange. It's perhaps more strange to talk about winning the race or beating another country though, as that implies some finality/conclusion to the endeavor.
This can be looked at as a continuous race to see who can build the highest-throughput computer, where the competitors' positions in the race are decided based on a well-defined set of benchmarks. The periodic updates don't indicate who's won -- they're just a snapshot of what everyone's positions are in the race around the time of publication. So it's more apt to say one competitor is ahead of another in the race, but talking about winning or beating someone maybe gets more clicks.
Ah, tt-rss... After Google announced that Google Reader was going the way of the dodo, I spun up my own instance of tt-rss, and used their (paid) Android app too... until I decided to file some bugs on their Redmine bug tracker.
There were a few bugs I had encountered (can't recall if it was on the mobile app, or on the browser UI), and decided to report to them. I opened a few reports (maybe 2 or 3?), and continued on my merry way. Checked in a not long after, and discovered that the developer didn't bother to really read my bug reports, and instead, berated me (if my fuzzy recollection is to be believed, something to the effect of "I don't know what you're talking about" and "you're stupid go away"), followed by closing the bug reports. No effort on his side to try to understand, no further digging for more information if something was unclear.
Being a software developer myself, I'd like to think I'm generally familiar with reporting reasonably useful bugs (repro steps, observed behavior, expected behavior, etc.), and even if I didn't include all information, I'm more than happy to provide more as requested/directed. But being effectively ignored and then berated for trying to help? Ridiculous.
tt-rss worked okay for my needs (lacked polish), but still, no software is perfect, so if I were to continue using tt-rss, I'd undoubtedly run into other bugs. Going by my experience with abrasive/abusive behavior of the developer (I saw similar examples in other bugs in the tracker at the time), I decided to jump ship on the first sign of a reasonable alternative. Thankfully, Feedly came along, and I hopped on for the ride.
After Google Reader, I tried a bunch of different ones. Feedly was the best I could find but there were a number of things that just annoyed me. I had an issue with one of my feeds and got very little help from their support.
That was the last straw and I decided to revisit alternatives. I somehow stumbled upon BazQux, and I noticed the same issue with the one feed on that platform as well. The developer was incredibly helpful in pointing out an issue with the way I was generating the feed. That level of support instantly had me hooked (along with how much it functioned like Google Reader). I bought a life time subscription then and there.
One of the best parts is the ability to add any FB, Instagram, Twitter users as a feed. BazQux automatically converts the user's feed into RSS and serves it up.
No more having to go to FB for updates from various organizations that don't have any other mechanism for publishing announcements! :)
Yes, I had a similar experience with the maintainer when trying to contribute back to tt-rss (two pull requests closed with rather rude explanations that suggested my submissions had barely been glanced at).
Still, tt-rss offers killer features for me that other options don't: self-hostable, being able to write my own scraper plugins (the big one in this discussion), and a solid Android app. So I continue to use it and just keep any code improvements to myself.
Feedly's mobile app has pretty bad UX (or at least that's been my experience every time I try installing it on Android).
For example, in the article list view, there's a single basically-identical swipe left/right gesture to...
* mark single article as read
* mark single article as unread
* mark all articles on page as read
* mark all articles on page as unread
The difference between marking a single article and marking all articles seems to be based on how far you've swiped, but if (for example) you don't release your swipe and keep moving your finger further after it's marked all as read, it suddenly does the opposite and marks all articles as unread. The direction of the swipe (left or right) doesn't seem to control whether you're marking read/unread -- it's (in my experience) been completely arbitrary what it decides to do, regardless of swipe direction. It's ridiculous how painful it is, and it's basically been this way for as long as I can remember.
The app has really poor bulk management of articles, so I just turn to other apps. Currently I'm using News+, which has superior bulk management capabilities... but it hasn't been updated in forever (and is buggy in other ways).
Minor quibble, but CyanogenMod's Privacy Guard was a glorified UI on top of App Ops that Google had already been developing.
Also, IMHO, it's a bit of a stretch to say that the Google Now shortcut was inspired by PA's Pie controls. One is just a shortcut to an enhanced search feature, and the other is... not unlike iOS's Assistive Touch feature on steroids. The only commonality is that they occur near/around the home button.
EDIT: And in fact, my Galaxy Note II had a "long-press menu button to trigger search" since the dedicated search button was removed -- nothing particularly unique about that paradigm.
While Cyanogen Inc. may well have been Google's biggest "threat" when it came to control of Android, it wasn't even that big a threat to begin with. They were always beholden to Google's source dumps, as was any other ROM distribution. I'd argue little has changed in terms of how much control Google has over Android's destiny, and Cyanogen Inc.'s (impending) death doesn't really move the compass in any meaningful way.
> Minor quibble, but CyanogenMod's Privacy Guard was a glorified UI on top of App Ops that Google had already been developing.
ApOps was removed by google[1] .
I agree with the little has changed bit. But I think we should give them credit for innovating quite a bit on the platform.And with Google's version of the OS, there were little outside options.which will reduce more drastically atleast till all Custom ROMs start forking of LineageOS.
[1]: Minor quibble, but CyanogenMod's Privacy Guard was a glorified UI on top of App Ops that Google had already been developing.
It wasn't removed; it was simply hidden because it was a work-in-progress piece of infrastructure wasn't ready for end-user consumption[1]. The same underlying code was still used by Privacy Guard[2], so it still wasn't CyanogenMod's innovation. App Ops would eventually make a user-facing comeback in 6.0 Marshmallow, with a very similar UI, just with the additional runtime popups for on-demand permissions.
I agree that CyanogenMod did bring innovations to the table -- I'm in no way trying to diminish that. Just clarifying attribution where due.
Speaking more generally, there is no doubt that custom ROMs answered needs/demands that Google just couldn't satisfy in the same timelines. Custom ROMs deserve tons of credit for prototyping and "market testing" concepts/features for Google. The good news is that -- by and large -- most of the low-hanging fruits have already been incorporated back into mainline Android. Nowadays, I've personally found fewer and fewer reasons to use custom ROMs (outside of the ever-important need to extend device lifetime anyway -- probably the biggest thing remaining that Google likely won't ever attempt to satisfy).
I find it amazing how some people can make uninformed claims about something, and when their "knowledge" is called into question, instead of backing down, they choose to double-down and insist that they are in fact informed. All the while, plainly verifiable evidence is staring everyone in the face that they don't know what they're talking about.
Maybe the author wasn't wrong in the facts presented. But maybe he wasn't giving the another perspective that would alter your perception or understanding of whatever picture he was trying to paint. If you aren't given the full context, then you haven't fully understood the situation.
If partial truths always lead to the correct conclusion, we would never have wrong convictions in courts caused by incomplete evidence.
Or to bring the analogy closer to home, if we know only some (but not all) of the use cases, we can't know if our solution truly and completely solves whatever problem we're trying to solve. Maybe Floegipoky knows of another "use case" (insight) here that Dan Lyons happened to leave out.
µBlock and µMatrix are parallel offshoots of gorhill's earlier HTTP Switchboard. They're refactored forms of HTTP Switchboard, where each extension focuses on different forms of blocking (µBlock for pattern-based filtering, µMatrix for matrix-based filtering).
I'm still of the opinion that the space at the top makes sense. I sometimes drag windows to the top to maximize, and like the inverse operation of dragging from the top to restore -- behaves consistently like any other regular Windows application that doesn't mess around with their titlebars.
You say that as if these guys wouldn't have touched Tor if Kim Dotcom didn't intervene. This is just what they do, whether or not they were given the vouchers. If not today, eventually they would probably have set their sights on Tor anyhow.
This can be looked at as a continuous race to see who can build the highest-throughput computer, where the competitors' positions in the race are decided based on a well-defined set of benchmarks. The periodic updates don't indicate who's won -- they're just a snapshot of what everyone's positions are in the race around the time of publication. So it's more apt to say one competitor is ahead of another in the race, but talking about winning or beating someone maybe gets more clicks.