My main gripe with them is that they reset at midnight (plus every now and then), and take 5 minutes to adjust themselves.

Unfortunately I’ve caught them a few times just showing a seemingly arbitrary time as well. This has always corrected itself after a few hours, but still..

It’s very nice looking clocks, but the reliability is just too low for my liking, as I don’t feel confident enough just looking at them that they currently show the exact actual time.

From an end-user perspective it seems to behave very transparent as well. In what way does it come up short?

Scrolling is pretty choppy and it doesn't support smooth/inertial scrolling.

So 3/5 of his listed issues exist on the Linux version.

A final build of 1.3 was tagged with an accompanying changelog and announcement post. I found it weird that it had no more ceremony, nor any prior submission on hn, and as it had been announced through the kubernetes-announce mailing list for 17 hours, I figured its existence would be interesting to the community, so I submitted it in good faith.

In any case, kudos to everybody working on it and congratulations on the release, whether it's this week or the next.

[0]: https://groups.google.com/forum/#!topic/kubernetes-announce/...

Comments URL: https://news.ycombinator.com/item?id=12022215

Points: 185

# Comments: 92

    > This branch is 211 commits ahead, 10086 commits behind scala:2.12.x.

I think you should be very careful about doing this without an explicitly stated license with reasonable proof of author copyright for the code snippet. It's one of the things that can easily compromise the legal security of a codebase.

All in all, it will likely have come out decent, but certainly not under the handle as you have. This I guess is because Cura will start the new layer close to where it finishes it's previous layer by default. In other words: it depends on infill percent/pattern and model location on the build platform.

I figure this is because you've added support. This causes the print head to get a "closest" start of the new layer exactly under the handle (because that's where the support material are). So going as far as calling it "lucky", no. The support placement actually helps Cura put the Z-scars in a good place on this model. On another model, it might be the exact opposite.

(PS: I use Cura for all my slicing and I like it a lot -- but I don't feel like the software actually gives me much control about the Z-scar placement)

Worth nothing is that things like the Z-scar being on the side of the cup instead of under the handle is something that's decided by the slicer (the software that translates the 3d model into printer commands).

Different open source slicers that are regularly used produce different locations for these scars -- and I'm not sure if it's actually possible to position/hint this Z-scar manually in any of them. They often do try to be "smart" about it, but the end result may vary.

You cannot just "buy a second 2xlarge" and then recombine them into a 4xlarge. The 2xlarge reservations and pay attention here need to match on their purchase date and hour. I.e they have to be bought within the same clock hour on the same day.

If you reserved a 2xlarge at 2014-12-01T22:59:59Z, you couldn't even combine it with one bought at 2014-12-01T23:00:01Z. Yes Amazon is that picky about it. While you might be able to muscle that through a sales contact, it's not even available to customers on business level support, so anything more than a day apart and you're likely out of luck in any case.

(See: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-modify..., particularly bullet point #6)

Swift uses the .swift extension, which is pretty unique, so detection is as simple as checking for the file extension with a very low risk of a bad classification.

Some of the older, more popular languages uses more common file-suffixes, which may be shared between multiple programming languages, which has a negative impact on classification accuracy.

I expected this to be a part of the extension settings / options, but ah well.

Is it adding "whitelist *" somewhere or something similar?

For example:

Now: m3.xlarge $1266 $0.105 per Hour $1922 $0.086 per Hour

April 1st: m3.xlarge $886 $0.074 per Hour $1345 $0.06 per Hour

It sounds weird if Amazon is actually going to keep charging the higher rate to existing customers, as they've already paid the higher reservation fee as well.

.. and ..

"...that Mt. Gox had outstanding debt of about ¥6.5 billion ($63.6 million)"

... right under.

These numbers are off by a factor of 1000, so which one is it? It's pretty horrible journalism and/or editing to get simple things like that wrong and expect me to pay them for the privilege of reading the remaining of the article I now I don't really trust the numbers in.