itsame

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.

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).

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).

[1] http://www.androidpolice.com/2013/12/11/googler-app-ops-was-...

[2] https://www.xda-developers.com/protecting-your-privacy-app-o...

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.

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.

Depending on which streaming service you use, possibly a non-issue when you can simply cache whatever music you want for offline access.

µ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).

See:

https://github.com/gorhill/uMatrix/wiki/Changes-from-HTTP-Sw...

https://github.com/gorhill/uMatrix/wiki/Using-%C2%B5Block-wi...

HN discussion on the first point from a while back: https://news.ycombinator.com/item?id=7831355

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.

Not a lawyer, but as I understand it, trademarks often cover only specific market categories. That is, someone can in some cases use a trademark in a market category that the original trademark owner does not operate (e.g. Company1 using BrandA sells only consumer electronics, some Company2 can actually later use BrandA to sell baby diapers). As long as BrandA isn't sufficiently famous and there is no risk of confusion or brand dilution, then Company2 isn't necessarily going to get in trouble.

Of course, determining where the line gets drawn probably isn't always a matter of checking off items in some checklist (gray areas, etc.). Nevertheless, in the case of Newegg's Shell Shocker deals, it doesn't seem to me like it overlaps with this site's intent (vulnerability testing). Only overlap I see is that it's something that's operated over the Internet. Would be far-fetched to say that this site is capitalizing on Newegg's brand goodwill to... get people to test for server/machine vulnerabilities.

Also... "It is not necessary for a trademark owner to take enforcement action against all infringement if it can be shown that the owner perceived the infringement to be minor and inconsequential. This is designed to prevent owners from continually being tied up in litigation for fear of cancellation."[1] So just because Newegg has a trademark doesn't mean it immediately and invariably has an obligation to enforce it at the threat of losing it.

[1] http://en.wikipedia.org/wiki/Trademark#Maintaining_rights

<spoiler-alert>They made a silly mistake on their question 13 (Geant4 and V517) implementation. Even though I clicked on the second sC0Min1Max, they marked my answer as incorrect -- it should be correct whether the first sC0Min1Max or the second sC0Min1Max is clicked.</spoiler-alert>

Effectively. Seems to use node-libspotify's ability to pipe the raw PCM stream to a file handle, after which it proceeds to convert to WAV->MP3(320kbps). Provides wrappers on top for playlist handling, etc.

Not sure how you concluded that that was my assumption. To have a "unique position" is completely irrelevant. The point is that Google users are sticky and valuable because Google keeps them engaged, and knows more about the users, and so the ads can be more targeted and thus more relevant to the user. In other words, ads shown to Google users by way of Google's ad service are (theoretically) more likely to be acted upon. That the users stick around using the Google services for long enough to potentially see the ads is icing on the cake, and Google's services being as ubiquitous as they are doesn't hurt either. Whether there exist other services in the same position as Google's has no bearing on the intrinsic value of the user base.

On the other hand, your argument that Schmidt's post is "b.s." hinges on the assumption that catering to users is a completely separate business model distinct from catering to their direct revenue sources (e.g. ad publishers). It's not.

To play along with your analogy: patrickaljord's point is that if sales decreases, then you get less commission. Decreased sales in this case is decreased number of ad viewers that comes as a result of decreased number of Google users.

So yes, ad publishers may not care about Google users in and of themselves, but they care about volume, and Google making its users happy and engaged keeps that volume high. By transitivity, ad publishers should (theoretically or indirectly) care about whether Google treats its users well as it would have some positive correlation with their viewership volume.

You're trying to draw a false dichotomy between the two -- they are not mutually exclusive goals. Just because Google is building for the users doesn't mean it's not building for the ad publishers. By building and improving their products for the users, they are increasing the stickiness and value of their users for the ad publishers.

If you had to choose between advertising at a location where people just breeze right through, and advertising at a location where people stick around to browse the goods, which location would you rather pick? Obviously the latter where people stick around, as it's more likely that they'll notice your advertisement. Google improving their products for the users makes it more likely that their users will stick around to notice the ads.

EDIT: jeroen's post (https://news.ycombinator.com/item?id=8093790) links to a better article.

tl;dr (as PeterWhittaker suggests): "Keep Bananas Fresh Longer by Separating Them and Wrapping the Stems in Plastic Wrap".

----- ORIGINAL GRIPING SESSION -----

NOTE: Just for context (so this comment doesn't look quite so silly as it now does :))... The post originally linked to awareness-time.com/?p=4195

-----------------------------------

So... am I right in my assumption that the picture of the bananas is a demonstration of this "simple way"? (With the intent of covering the stem with plastic wrap being for the purpose of minimizing exposure to gases that speed the process up?)

It's not made explicitly clear in the blog entry. In fact, the entry is very poorly structured. It...

1. gives an anecdote about the bananas turning brown

2. says there's a better way to slow the browning

3. immediately jumps into a section it marks as "optional"

4. starts the optional section with an ad

5. begins actual optional content with a short blurb

6. finally shows the picture (is this optional??)

7. follows it all up with the actual "optional" science

All without at least a short text explanation of the "simple way". You don't need complicated words to explain that processes occurring at the stem speed up the ripening effect, and that an easy way around that is to cover the stem with plastic wrap... so why is such a simple explanation omitted? Yes, a picture may be worth a thousand words, but when placed poorly, makes for a very confusing thousand words.

I've used AutoIt fairly heavily in the past and can say from experience that, in many ways, it is indeed very convenient for rapid Windows development.

Still, to more directly answer the "question" presented in the article title, I'd say that there is no connection between AutoIt and malware -- at least no more than any other malware authors' languages of choice. It's unfortunate for legitimate developers that malware authors (unsurprisingly) find the convenience to work for them as well. That doesn't excuse anti-malware vendors for labeling executables as malware just because they were developed using AutoIt. The UPX packing that comes out-of-the-box with the AutoIt "compiler" doesn't help either -- it's like a one-two combo for false-positives, since anti-malware software also frequently get tripped up by EXE packers like UPX.

AutoIt-based stuff that I've distributed in the past have fallen victim to AutoIt+UPX false-positives, and it's teeth-grindingly annoying for your stuff to be perfectly fine for a long stretch of time, only to find people knocking on your e-door the next day grilling you about distributing malware just because the anti-malware vendors updated their signatures to block AutoIt -- again.

To be fair, the article explicitly states the following:

> TL;DR I cannot in good faith recommend Vim to a new developer, even though I use it.

Since you're already familiar with vim, you clearly aren't in the target audience.

Admittedly I can only make guesses as to the actual implementation. It may well be through the cloud, through some Bluetooth/Wi-Fi communication, or maybe even a mixture for all we know. Nevertheless, my point is that the concepts and the high-level integration in and of themselves are not particularly novel.

Again that's not to discount what Apple has achieved here. In typical Apple fashion, their excellent execution of existing concepts is where their value proposition lies, and this is no exception.

I don't quite see when in the keynote Apple demonstrated the run-anywhere applications that's discussed in this blog entry. These are all different implementations of applications running on their respective platforms, integrated through the cloud. It's nothing new at the most basic level, and nothing new at the application level. What Apple's done is integrate everything in a fairly seamless fashion. Certainly Apple gets kudos for their execution (the proximity stuff was cool), but in the end, integration through the cloud and being able to pick up where you left off is something that has already been demonstrated by Google (along with other companies) with stuff like Chrome syncing and the Google Docs suite of applications.

Well... sure, I guess, but although I wasn't direct about it in my above comment, the whole discussion was about mouse control right?

If we want to discuss keyboard shortcuts, then Ctrl+Tab/Ctrl+Shift+Tab/Ctrl+W/Ctrl+T are quick tab management shortcuts that bypass mouse control as well, and that one pixel at the top that makes tab switching by mouse annoying for talles would be rather moot.

Is that really a bug as others are saying? I've always thought of it as making the inverse of the Windows 7 drag-to-top-of-screen-to-maximize (restoring the window) easier, and prefer it that way. More generally, it makes it easier to drag the whole window around again after maximization.

In some sense, it makes Opera at least somewhat more consistent with other regular Windows applications that don't mess around with the titlebar. I actually find it annoying that there's no quick way to manage the maximized browser windows in Chrome or Firefox other than to click that button in the standard window chrome to restore the window, and then proceed.

Something that always annoys me about these articles is the ambiguity behind what constitutes "usage". Idling in pocket (but actively connected to phone network)? Data, text, or voice calls? Voice calls using phone directly to ear, wired headset, or wireless (Bluetooth) headset?

Judging by most articles I've seen, the studies appear to be very typically limited to voice calls using the phone directly to ear, which isn't a common use case in for me.

Relative to each other they make sense. I guess they chop off the right-hand side of the bar at around 20% for effect, so it looks like a larger portion of users are blocking than in reality. Makes marketing sense given the solution they're selling.

As I see it, the point is to set a minimum bar to filter out people who know nothing and end up coming back to complain. Presumably tinkerers who know at least the basic stuff would be willing to put the time into learning/doing the DIY hacking.

To set the bar any higher reeks to me of elitism (i.e. creating an "exclusive" club of "hackers"), which doesn't seem like his intent.