Not to get into a discussion regarding what constitutes a "Release" for any specific project, whether it's tagging, pushing, announcing[0], updating documentation, creating release notes, publish a release blog post and so on.
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.
While interesting in and of it self, it seems to have seen no changes since mid-2013, looking at its GitHub repository (https://github.com/greedy/scala)
> This branch is 211 commits ahead, 10086 commits behind scala:2.12.x.
Is there any new context / development that makes this extra interesting right now?
> if you find something on SO that does exactly what you need then yes, just paste it.
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.
So I just took the coffee cup STL and loaded into the latest Cura myself, rotated in 90 degrees so it was standing upright. Without changing anything else, I ended up getting the layer changes on a few difference places over the print (I'm seeing this just by analyzing the G-Code using http://gcode.ws), depending on the layer height. It starts to the right of the handle and after a while seems to sort-of stabilize almost on the opposite side of the handle and on the right side of the actual handle, before the handle separates from the cup body.
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)
It certainly raises some good questions, and the Printrbot is a great machine at the price point (I have a Printrbot Simple RepRap clone myself). His looks pretty well calibrated as I've seen a lot of Z-wobbling artefacts on the prints from several Printrbot (Simple Makers, not necessarily the metal one).
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.
I've never ever received a message from AWS when they've had outages that have been affected us significantly. On the contrary, there's been multiple cases where we've experienced issues, contacted them and it's taken a few hours before they realize they're actually having infrastructure problems. Many of these don't even get an entry on their service status pages. So there's still a lot of room for improvement on AWS's side of things as well.
This likely has a lot to do with how they do detection.
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.
How I'm reading this, both up-front reservation fees and the hourly rates are lower for a lot of instance types.
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.
"Bitcoin Exchange Had $63.6 billion in Outstanding Debt"
.. 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.
Ouch. App stores often take 30%, which means that only 52.5% (0.7*0.75) of what the user pays goes to the developer. That is quite a significant number.
We had a radio in our old Chrysler Voyager that required a pretty insane secret code being entered (turning it off and on again 5 times in a row or something like that was part of it) in order to enable to tune to regular EU frequencies...
Norway pays around $16.09 monthly and still has around the same amount of songs that are unavailable as well. It's getting better -- a year or so ago around 7-8% of the top 100 everywhere were unavailable to us. Still cost the same.
Same story with Netflix. Costs more here than in the US, but the content is waaay worse. It's often 2-3 years behind the original airing of the episodes in US, so it's not in any way useful to stay current.
From an end-user perspective it seems to behave very transparent as well. In what way does it come up short?