That reminds me of this gem from the Cygwin FAQ (through Dec 2009, since removed for political correctness):

I'm hoping the Maui Project (which uses Wayland) can continue to gain momentum as Wayland does and that it becomes a viable option in the next few years.

From what I can tell, GCC is still the better compiler. It is better supported (lots of things won't work on clang or llvm-gcc) as well. LLVM/Clang tends to compile a bit faster (which doesn't matter unless it's an order of magnitude) while the binaries that GCC produces tend to run more efficiently. There's a nice benchmark comparing GCC 4.7 to Clang 3.1 (in Apr 2012) which demonstrates this.

I'm sure LLVM has been well designed and perhaps can do better with JIT and similar concepts (which you'd have to compare to e.g. GNU Lightning), but GCC is still king. Stallman's complaint is that it's getting attention and therefore it may become better than GCC over time, which he argues would be bad for developers on the assumption that eventually a game-changing feature is released for LLVM that is nonfree and then everybody will be forced to pay for it, a fate that the GPL'd GCC cannot suffer.

Covered at The Register: http://www.theregister.co.uk/2014/01/24/google_plus_gmail_down/

Netizens are complaining that Google's social network Plus is knackered and the webmail service Gmail is completely offline. In a painful twist of fate, the systems went down just as Google's crack site reliability team was preparing for a live question'n'answer session on Reddit. And it comes after strangers' email addresses started appearing in Google searches for "gmail".

This will help find exact matches by exif data. It will not find near-matches unless they have the same exif data. If you want that, good luck. Geeqie has a find-similar command, but it's only so good (image search is hard!). Apparently there's also a findimagedupes tool available, see comments above (I wrote this before seeing that and had assumed apt-cache search had already been exhausted).

I would write a script that runs exiftool on each file you want to test. Remove the items that refer to timestamp, file name, path, etc. make a md5.

Something like this exif_hash.sh (sorry, slashdot eats whitespace so this is not indented):

#!/bin/sh
for image in "$@"; do
echo "`exiftool |grep -ve 20..:..: -e 19..:..: -e File -e Directory |md5sum` $image"
done

And then run:

find [list of paths] -typef -print0 |xargs -0 exif_hash.sh |sort > output

If you have a really large list of images, do not run this through sort. Just pipe it into your output file and sort it later. It's possible that the sort utility can't deal with the size of the list (you can work around this by using grep '^[0-8]' output |sort >output-1 and grep -v '^[0-8]' output |sort >output-2, then cat output-1 output-2 > output.sorted or thereabouts; you may need more than two passes).

There are other things you can do to display these, e.g. awk '{print $1}' output |uniq -c |sort -n to rank them by hash.

On Debian, exiftool is part of the libimage-exiftool-perl package. If you know perl, you can write this with far more precision (I figured this would be an easier explanation for non-coders).

This will help find exact matches by exif data. It will not find near-matches unless they have the same exif data. If you want that, good luck. Geeqie has a find-similar command, but it's only so good (image search is hard!).

I would write a script that runs exiftool on each file you want to test. Remove the items that refer to timestamp, file name, path, etc. make a md5.

Something like this exif_hash.sh (sorry, slashdot eats whitespace so this is not indented):

#!/bin/sh
for image in "$@"; do
echo "`exiftool |grep -ve 20..:..: -e 19..:..: -e File -e Directory |md5sum` $image"
done

And then run:

find [list of paths] -typef -print0 |xargs -0 exif_hash.sh |sort > output

If you have a really large list of images, do not run this through sort. Just pipe it into your output file and sort it later. It's possible that the sort utility can't deal with the size of the list (you can work around this by using grep '^[0-8]' output |sort >output-1 and grep -v '^[0-8]' output |sort >output-2, then cat output-1 output-2 > output.sorted or thereabouts; you may need more than two passes).

There are other things you can do to display these, e.g. awk '{print $1}' output |uniq -c |sort -n to rank them by hash.

On Debian, exiftool is part of the libimage-exiftool-perl package. If you know perl, you can write this with far more precision (I figured this would be an easier explanation for non-coders).

Each employee takes, at most, one bus each way every day. Google sends buses back and forth all day long, even into the night and weekends. Yahoo and others have separate buses rather than pooling resources, so there are plenty of wasted seats compared to a unified bus system.

As to congestion: Buses can't maneuver as well as cars, and cars tend not to roost next to bus stops waiting for their turn (even if they did, they'd fit, rather than blocking traffic nearby), so yes, they cause congestion. Read the Kos article for further detail.

I think you've missed the point. Dozens of companies in the peninsula have their own dedicated bus lines. The bus-to-person ratio is quite high, and this is not as eco-friendly as you might think. It also causes congestion in the city, and confusion at the shared bus stops (which are owned by the city of SF), both of passengers and of citizens looking for a bus they can actually ride.

The city taxing the bus services allows maintenance to be applied to the extra load of the stops as well as planning for the increased traffic these systems create. I think it is quite reasonable.

Daily Kos had a good explanation of the problem back in April.

No. While there is room for improvement, the article is good and Bennett is not "shitting up /." I was suggesting that Bennett disregard the highly negative tone of that comment. I did not say that the article was perfect or that the criticisms of this thread were entirely without merit.

While I agree that "length does not equal insight," I think that there is insight in the article and that its length is fine. Sure, it could benefit from more concision, but most articles fall in that category. The prose is a bit "bloggy" but not unacceptably. Again, there is room for improvement but that's not enough to make this a bad read.

ML is the way to go, the trouble is that it's really really hard to do. I like the idea of having users categorize items so that you can use the hand-classified data to train on and then scale up with machine learning, but that's only a part of the puzzle. It's more difficult to properly curate what is and is not headline-worthy without catering to a basic popularity contest. Good luck with that, and may you continue to be optimistic!

I've always hoped that Slashdot itself could use ML to extend comment moderation: allow five points for human moderation, two for meta-moderation (given enough reinforcement), and three for a third system based on ML (trained by meta-moderation-confirmed moderation). Average the direct moderation (-1 to 5) and the indirect moderation (meta+ML, -1 to 5), adjust by +1/-1/-2 for AC/karma/user-conf, and round up or down based on achievements. Alternatively, make it a ten point system and add them rather than averaging them (fold achievements into karma). I'd start with the ML system as a moderator within the current system, then once it's proven, migrate to the averaging system, then migrate to the ten point scale.

Bennett, please disregard that. People do like summaries and quick reads, which is what the quoted first paragraph you provided delivers. Slashdot's audience is a little too accustomed to having to click on links to see the real article ("mindless link propagation"). Coupling that with the fact that nobody actually RTFA, you get comments like what we see above.

Frankly, I'm happy to see original content on Slashdot (well, beyond book reviews and Ask Slashdot). Thank you for contributing a real story directly to this site rather than posting it elsewhere and linking it in a Slashdot article.

(That said, I do agree with krauch aum that "length does not equal insight," I just happen to have differed in opinion about whether this article has insight. I'd also agree that this reads a little more like a blog than I'd personally like; I'm happier with items that are more like news articles than op-eds. I'd still rate this as a good write-up overall.)

The problem is that they're trying to make the manufacture process cheaper in order to eek out a slightly higher profit. Plus, multitouch is increasing the amount of space necessary to devote to the touchkpad.

I really like the keyboard on my Thinkpad X201s, whose only isue is the Escape key being above the F1 rather than to the left of it, but at least it's at the upper-leftmost corner of the keyboard, so it was easy to adapt to (also, I mapped F1 to Esc in a lot of programs). The other problem with this laptop was the small touchpad. It supported multitouch, but it's tiny, measuring about two inches wide by one inch tall.

Clearing a row of keys obviously translates to increasing the vertical size of the touchpad. I get that, it just needs to be done more intelligently. The X1's touchkpad is about four rows of keys tall and has no buttons. The X201s's touchkpad, including keys, is about 3 1/3 rows tall. There are two rows of function keys up top which are each about two thirds of a row tall. Removing one of them solves the space problem to the millimeter. Don't get rid of those keys though! I think I could survive with that top (function) key row turned into a capacitive row the way the X1 does ... so long as there is still a normal Esc key on its far left (above the tilde, which is to the left of the digits).

How about:

• - Backspace must be the rightmost key on the digits row.
• - Esc must be the upper-leftmost key, one row above the digits' row.
• - Power is fine at the upper-rightmost key.
• - Also retain the standard positions for tilde (left of digits), CapsLk (under Tab).
• - The top row can remain "adaptive" as long as its end keys, Esc and Power, are real.
• - Give a non-multitouch middle-click option, either via emulation (right+left) or three spots at the touchpad's top.
• - Grow down instead of up:
  • - Bring back the numeric keypad's 0-9 and dot (default NumLk off) for 4 rows of arrows/numbers. This places PgUp/PgDn, Home/End, and Ins/Del.
  • - New buttons (like Fn and Compose) can go under each Alt key for easy thumb access
• - Fn is a hardware button, but if you add Compose, it's software (allow setting it as another bucky bit like Hyper or Option)

I've mocked this up and posted it in ascii art (mostly to scale) to pastebin at http://pastebin.com/sEECJKrh. If any laptop keyboard designers are reading this, it's free for you to use. I just want it to be used.

Hm, interesting; According to Copyright.gov, games cannot be protected under US copyright law. I had thought the same applied to patenting game mechanics, but I've lost my reference to that one.