Amazon AWS Free Usage Tier - <AUTHOR> http://aws.amazon.com/free/ <comment><USER4> I think it would be better to make these available to everybody, not just to new users.

I talk to people at Amazon frequently enough to know that they don't take existing customers for granted... but doing things like this certainly doesn't help with their image in that respect.

<comment><USER5> It is a marketing campaign designed to generate reg. Marketing is about getting the right message to the right people in a way that they prefer to hear that message. In this case existing users are not the right people. People who have been thinking about trying AWS but don't want to shell out any cash are the right people.

It is not really alienation. They are investing money in converting people to their platform. Offering this to existing users makes no sense from that perspective. It is pretty standard across many industries to offer exclusive deals to new customers.

<comment><USER6> _Marketing is about getting the right message to the right people in a way that they prefer to hear that message. In this case existing users are not the right people._

That's why it's a mistake. Existing users (the wrong people) hear the message much louder than potential users, and possibly in greater numbers.

<comment><USER7> I'm sorry, but I'm unable to understand why an existing paying user should in any way, shape, or form expect to participate in a promotion to attract new users to the platform. No matter how you look at it, this is a promotion for new users. Period.

These expectations are analogous to you being a paying member on some platform, and they announce a "30 days free" promotion for new members, and you demanding that you should get to participate in that promotion. Shenanigans.

And just because AWS is pay as you go doesn't make this any different.

<comment><USER8> Why is that "shenanigans"? I've asked to be put on promotional pricing many times as an existing user of other companies and you know what... they often give it to me. Why? Because I'm free to give my money to someone else.

It's a way of showing appreciation and that they don't take you for granted. Period. (sorry, I had to)

If you aren't negotiating better terms for recurring services, then you are giving money away. Promotions are just a nice bit of leverage in negotiations.

<comment><USER9> So you believe every Amazon customer should get in the promotion of X amount of free service for a whole year without any retention mechanism?

In comparison if you ask your internet provider to bump you up from 1mbps to 2mbps (or to lower the price from 50 bucks to 40) because they have a promotion for new users, and they give it to you, providing you sign a contract for another 12 months, is not equivalent to telling the internet provider that because they are offering a free year of service (up to lets say 5 gigs of downstream bandwidth) to new customers you should do to and without a contract specifying that you're staying with the company afterwards.

</comment></comment></comment></comment></comment></comment><comment><USER10> Tucked away in the offer terms is:

 _You will become ineligible for the Offer if, during any 3 month period, you do not [..] (b) incur fees for use of the service that exceeds the free usage amount provided under the Offer_

So it is free as long as you exceed the free quotas. Hmm.

[ <http://aws.amazon.com/free/terms/> ]

<comment><USER11> They appear to have deleted that from the page.

<comment><USER10> Cool. Looks like Shlomo got someone to investigate: <http://twitter.com/ShlomoSwidler/status/28063124182>

</comment></comment></comment><comment><USER12> This is mind-blowingly great, not only for them -- compete with Google App engine, and get people hooked on AWS early -- but also for young entrepreneurs, who can get a professional dev env for $0 and a year to see if their idea works.

I think this will also open the gates to developers outside the US -- $50/month for hosting might not seem too much to an American, but in other countries it can be a real barrier.

<comment><USER13> Having dealt with GAE for a while, I can say that EC2 and GAE don't create much competition for each other. Granted that user-facing result is the same - applications, yet both are a completely different model of doing applications. To that extent, I imagine developers choosing their respective platform out of these two will have different mindsets or requirements.

In GAE, you have the privilege of bypassing the administrative stuff - creating/deleting/configuring instances, choosing software, amongst other things. Quite useful for some app categories, like web-apps/web-services for verticals, where you want to concentrate on the business logic and the rest doesn't matter as long as the app works.

EC2 is great too, and attracts developers who require more freedom in terms of software architecture, and choice of components, but comes with a the non- trivial administrative costs. (I do imagine EC2 consultants being in-demand, sooner or later.)

I think both models have potential to succeed, and should be able to nicely co-exist. This free-to-jumpstart approach is perhaps targeted just to stir up AWS demand.

<comment><USER14> There are many instances of overlap. An Amazon user will use that and an GAE user will choose GAE for essentially the same projects a user of neither may consider both. "Toy projects" will often be in the last category. The parent is saying that subsequent projects might be in the first categories.

</comment></comment></comment><comment><USER12> Of course, any moment now there will be a blog post from somebody who signed up for 300 disposable credit cards and used 300 disposable email addresses to get a supercomputer for free.

<comment><USER15> If you have a Bank of America credit card, you can just use the ShopSafe feature. Log in to your account online and you can generate temporary card numbers to purchase something online (allocating as much allowable spending as you want), so you don't have to expose your real card number online. These are temporary numbers that get a new number, new expiration and new CCV...but behind the scenes they're tied to your real card, so they show up on your bill like normal.

<comment><USER16> I tried that once. They cut me off after 5 temp numbers in one day. I wasn't even trying to cheat -- I was just buying a bunch of stuff from different vendors.

</comment></comment></comment><comment><USER17> Sadly, there is one thing missing. They need to allow you to run a micro instance of RDS. Then the circle would be complete and you could deploy a full application for free to the cloud. (The problem now is you'd have to run the database yourself on your one micro, which is do-able but quite lame.)

<comment><USER18> Perhaps Amazon would argue that they're giving you some free units of SimpleDB, but access to a small MySQL environment would certainly allow a huge number of open source apps to be deployed without modification.

</comment></comment><comment><USER19> What is the dollar value of all this free stuff?

<comment><USER12> 750 hours EC2 linux micro = $15

750 hours ELB = $18.75

15GB ELB data processing = $0.12

10GB EBS, 1 month = $1.00

1 million EBS I/Os = $0.10

1GB snapshot = ? (varies a lot, but less than a dollar)

5GB S3, 2000 PUT, 20000 GET = $0.79

30GB transfer ~= $4.20

The remaining items are always free.

Total: $39.96

(Marketing value: priceless)

FYI, you can calculate any bill here: <http://calculator.s3.amazonaws.com/calc5.html>

<comment><USER20> available for 12 months: $479.52

<comment><USER12> Oh of course, thank you.

</comment></comment></comment></comment><comment><USER21> Wow this is remarkable. This is simply the best time in history to be starting a new business, particularly an Internet based business. The barrier to entry is extremely low and the ability to change & improve is as flexible as Mr. Fantastic.

<comment><USER22> _This is simply the best time in history to be starting a new business..._

... except in the future, when it will be even easier :~)

<comment><USER23> From wikipedia: "History [...] is the study of the human past"

</comment></comment></comment><comment><USER24> I'm curious how Linode and Slicehost will respond. This is pretty hard to beat.

<comment><USER25> this is my thought/fear too, as I'm in the same space.

Now, I tried 'free' before and I just about lost my shirt. I got a bunch of jerks signing up with fake names and then running up my bandwidth bills with torrents, then at the end of the month, nobody, ah, "converted" so _I_ am not going to respond with 'free'

One of my responses could be to push my larger domains (which are quite a bit cheaper than the competition) or continue focusing on the international market. (I haven't read the fine print of the amazon offer, but I'll eat my hat if they give free accounts to, say, Brazilians.)

So yeah; my current attitude is "wait and see" - as of today I'm still selling out servers as fast as I can put them up... if that changes, I'll change something.

As for slicehost/linode, my personal guess is that they will both tout their substantial customer support advantages over amazon.

<comment><USER26> If you make your services any cheaper, I will personally unsubscribe, since I will no longer think you're in it to make a living, but offering a charity.

<http://prgmr.com/xen/>

You really have everyone beat on price, by a mile. Too bad, there aren't enough cheap, unix-gurus to make use of it :-) People these days want an ajax console with drop-down menus for shell commands.

<comment><USER25> hah. well, I am making a living off of it.

the thing of it is, really, prices for this sort of thing should be falling with Moore's law, right?

Also, there seems to be enough cheap UNIX people to keep me busy... I've been selling out hardware about as fast as I can put it up. at this point the bottleneck is pretty solidly me.

Of course, I'm charging prices that would be pretty high margin if I was 'at scale' and, well, I'm not even close, at the moment, so I don't have as much wiggle room as I would have otherwise, but rest assured, it's profitable, at least when I don't screw it up. I've set a (I think realistic) goal to double in the next 6 months, which

<comment><USER27> The 8$/month machine sounds very interesting.

I'm quite new to VPS. I recently deployed a couple of project for customer in Linode. I am very happy with them, but at the same time, I have some hobby projects of my own that I dont want to host in a 20USD/month machine.

How are your VPSs compare to Linode?

<comment><USER25> they have better CPU than I do (and this is unlikely to change... but you know? very few things my customers do are CPU bound.)

I also give you fewer VCPU on the lower-end instances. they give you 4, I give you 1. the idea here is to optimize for the worst case (if there is contention, and you have 4 vcpus, that's more context switching and more cache flushes. on the other hand, cpu is usually mostly idle, and in that case more vcpu is more performance. My large instances have more vcpu.) I'm experimenting with my vcpu policy and may bring that more in line with linode. But really, I regard this as relatively unimportant because VPSs are rarely CPU bound.

Our disk quality is likely about the same (I use 7500rpm "enterprise" sata, which is about as good as sata gets without getting into the expensive 10K stuff, and if linode was using 10K disk, they'd be advertising the fact.) My ratio of disk to ram is 4 disks in raid 1+0 for every 32GiB ram/8 cores I'm not sure what Linode's ratio is. But Linode has better mechanisms for limiting heavy disk users than I do. (heavy in terms of performance rather than in terms of space... limiting by space is trivial.) My understanding is that they keep iop counters or similar, and first warn, then limit you if you use a lot more iops than most people. I don't do this, and sometimes overall disk performance suffers because of it. But I do plan to emulate Linode in that regard at some point.

And, of course, my most noticeable deficiency is that I do manual provisioning, and Linode has a nicely automated setup. but I'm (very slowly) catching up.

Now, I'm about half the price, too, but you already knew that.

</comment></comment></comment></comment></comment></comment><comment><USER28> Wow, the list of excuses to not attempt a startup is getting shorter and shorter. Ideas? Check. (See HN the past few days) Page design? Check. (Web page templates with free samples) Hosting costs? Check. Now Free for a year with AWS without being tied to a specific language/framework.

</comment><comment><USER29> This is very competitive with the free Azure services Microsoft is offering to MSDN subscribers: <http://msdn.microsoft.com/en- us/subscriptions/ee461076.aspx>

<comment><USER30> [Disclaimer - I work on Windows Azure]

Microsoft also offers a free promotion to all new subscribers (click "view details" link under "Buy Now" button): <http://www.microsoft.com/windowsazure/offers/>

From the site:

Included each month at no charge:

* 25hrs small compute instance

* 500MB storage

* 10,000 storage transactions

* SQL Azure 1GB Web Edition database (3months only)

Any monthly usage in excess of the above amounts will be charged at the standard rates. This introductory special will end on March 31, 2011 and all usage will then be charged at the standard rates.

<comment><USER31> The difference is, Azure locks you into a closed platform.

<comment><USER32> If, by closed platform you mean Windows, how is that different from EC2, which locks you into either the closed platform of Windows or the closed platform of Linux?

Either way, it's a pretty big platform to be locked into. Kinda like saying your new laptop locks you into a closed platform.

<comment><USER25> how is Linux a closed platform?

Is it as easy to move from Azure to a co-located windows box as it is to move from ec2 to a co-located Linux box? (e.g. install the image on the new box and replace the kernel?)

</comment></comment></comment></comment></comment><comment><USER33> > Now a someone who's purely back-end can actually take software he's written, > and just throw it on some EC2 instances and sell it directly to consumer > internet companies. There's no need to take a job with these companies now > and...there's no need to release your software. > <http://news.ycombinator.com/item?id=1788558>

That was in cloud vs. opensource... but I hereby humbly propose _8ren's amazingly wonderful Open Service concept_ :

The cloud is the future, not only for the backend, but also components within it - including middleware. Theoretically, _arbitrary functionality_ can be a service - literally, any "function" (in the math sense - or stateful). That is, anything that was previously open source.

It might even get to the point where the economics make sense to use an "open service" instead of hosting it yourself, analogous to conventional open source. This would require hosting that is: (1) practically free; (2) very high performance; (3) very high availability; (4) security/privacy mechanisms. We may be closer than you'd think - eg. if EC2 hosted "Open Services" for free, which would _naturally be faster for EC2 paid services_ , making those paid services more attractive. Then the competition needs to match it... Google might do it too (already does, within its app engine).

To qualify for this amazing free hosted Open Service? Be open source.

<comment><USER34> You might be interested in Jeff Lindsay's Public Open Source Services idea :

[http://blogrium.wordpress.com/2009/10/29/public-open- source-...](http://blogrium.wordpress.com/2009/10/29/public-open-source- services/)

<http://poss.gliderlab.com/>

<comment><USER33> Thanks, I like his market payment model esp how demand modulates supply - <USER2> I believe that just the fact of payment adds admin overhead/transaction costs, and slows adoption - you might as well charge a little more and make it a business.

I think my suggested payment model makes Open Services easier to adopt, because it has no admin overhead. The API is there, you call it, done. It is paid for by amazon/google, because it benefits their paying customers - <USER3> indirectly pay for it. Note that they would be paying for its hosting anyway, if they deployed that open source themselves.

\- There would be admin savings from having just one deployment (more efficient for everyone).

\- And it would be just as fast, if deployed in the same cloud (theoretically - I'm assuming a coarse-grained IPC world, where apps are built by assembling services anyway, which is where we're headed. I'm thinking of it like static method calls in Java, that so get JIT inlined/stitched into one big lump at runtime, even though they are in separate modules (class files)).

\- Plus, these free Open Services act as an advertisement and enticement to non-EC2 users (or free users) - and once you've started using EC2-hosted Open Services, the easiest step up is of course to move to becoming a paid EC2 yourself. There's a bit of lock-in. So it is in Amazon's interest, too. So it's economically a _little_ bit like advertiser-subsidized TV. And technologically, it's like Google's many free API's (eg. map API), but the case is more compelling for the supplier, because it costs the same to provide, but more directly pulls in paying customers.

\- I agree there would sometimes be issues with how much processing power it gets (Dos attacks, abuse in general), but this is a complex issue, and I think you'd need to actually run it for a time to discover the real issues and experiment with solutions. But the vast majority of open source projects are not used by anybody - these aren't using any resources (apart from memory, which is close to 0 cost), and so their cost is negligible.

\- once one hoster provides it, it gives them a competitive advantage, and other hosters need to match it to stay in the game.

\- over time, with Moore's law, the hoster's cost of providing these Open Service approaches zero.

I think it's inevitable for Open Services to begin and spread (or something functionally similar).

</comment></comment></comment><comment><USER15> Interesting that it lists 30GB data transfer (15 in/out) as one of the items. All inbound data transfer is currently free anyways for everyone. It's been due to expire at regular intervals, but they keep extending this further (presumably to compete with Azure). I wonder if this indicates they will finally eliminate free inbound data transfer for customers...hopefully not.

<comment><USER4> The free incoming is currently set to expire on November 1st, exactly when this starts. I'd like to see the free incoming continue, but this timing looks like a bad sign. :-(

</comment></comment><comment><USER35> I'm not a web developer but somewhat curious, so please excuse this potentially inane question: How much can I actually _do_ with one Micro Instance? Is it comparable to, say, a VPS in terms of handling and capabilities?

Or is it an entirely different animal?

<comment><USER36> This is pretty comparable to a Linode 512 slice, but with a little more memory. The configuration is VASTLY different however. EC2 instances are basically writable CD images -- which is to say, whatever you 'imprint' it with as the image is what it will be every time it's rebooted. You can store /tmp and /dev/null content on the instance just fine, so long as you know they won't be there when you reboot. You are free to take 'snapshots' of important changes (like, I just deployed my new app, let's create a new image).

To supplement this, they're also offering Elastic Block, which is an on- demand, resizable static partition. This is your long-term disk, but it's sold seperately, and has different usage / pricing metrics.

Generally speaking, you allocate your storage, then build your EC2 image, then create a mount, set up your application / server configuration / etc, then take a snapshot. That snapshot is the image you'll boot in the future.

<comment><USER35> Thanks.

Is it feasible at all to (ab-)use this free Micro instance as a real development machine for running little experiments? Assuming I keep one instance running at all times, without adding any new ones, it seems like I could just ignore the fluid snapshot system and treat it like a bog-standard VPS.

<comment><USER36> So, the reliability may not be there for that. If an instance crashes, or becomes unavailable, or is, at the whim of Amazon, turned off, you've completely lost your settings.

You can still use them as a standard VPS, of course, if you just take a little care and mount a static file system up front, then use that for all dynamic content/database store/uploads/etc.

The only real difference is that your persistent file store is completely separate from the instance, which threw me for a big loop when they were new, but has become old hat since then.

I don't know what the reliability is nowadays, but there used to be (when it was very new) complaints that the instances would crash or come offline without notice, and that as with all things, it would happen at very inconvenient times. With care, and forethought, it's preventable, of course; but what happened then was people trying to do exactly what you suggest, only to be thwarted by the unreliability of the system.

Of course, the beauty of it, if planned for, is that it doesn't NEED to be reliable. If you use the Elastic Load Balancer, you can spool up pre- configured instances at the drop of a hat that service demand, and if one crashes, it's easy enough to replace with a brand new instance. The instances can all share a persistent file store, they can all be dynamically registered with the load balancer. They can all function on their own with relative autonomy (which is how businesses like CloudKick make their money.)

If nothing else, I'd advise you take advantage of this deal and play around with it. It's a neat little system, and their elastic IP addresses are something of a thought exercise at the beginning, and nothing short of brilliant after you've figured it out. You'll learn something, and that's always worth something.

</comment></comment></comment></comment><comment><USER37> This is an absolutely brilliant move. Trying to figure out pricing estimates often discourages me from launching more stuff on AWS. Knowing I can get a feel for it, for free, is a real game changer. This gives my projects a strong base to start with.

A few observations: \- I wonder if you could create a new account for each of your projects (er.. startups) or if Amazon would frown on that. \- They seem to be extremely generous with this offer, except for the Amazon S3 limits. 20,000 GETs? That's nothing for the kind of resources that S3 is best at hosting.

<comment><USER38> It does say you need a valid credit card, which should deter most people who aren't out to ruin their credit rating. Maybe businesses can mint multiple CCs without dinging their rating but it would be riskier for them...

<comment><USER37> Couldn't you use one of those rechargeable temporary credit cards? The ones they use to grant people with bad credit a semblance of a normal life..

</comment></comment></comment><comment><USER39> They need to clarify the terms, it is unclear if this minimum usage is free or if they will cancel your account if you go over. These are both in their agreement:

"You also will be charged AWS's standard rates for any use that exceeds the free usage amount provided under the Offer."

"You will become ineligible for the Offer if, ... (b) incur fees for use of the service that exceeds the free usage amount provided under the Offer. ..."

</comment><comment><USER40> 1995: The best deal I could find was $1500 a month for 1mbit, (I was spending (in 1995 dollars)) $4500 for 3mbit, and I spent 5k or so building the server for what would become planetquake.com

What is happening now in both available (and free!) cloud computing resources and the entire lean startup mentality is so far beyond my comprehension I don't even know how to compare the two startup worlds of 1995 and 2010.

Lordy!

</comment><comment><USER41> Great, I just signed up for a new account yesterday. Are secondary accounts not allowed?

</comment><comment><USER42> Wow that's... Cool but not that great of a deal. You need to create a new account, and you only get 30gb of bandwidth. If you exceed any of the limits it all converts to paid services. Plus, it's only for a year. Good for learning ec2, but I'll stick with heroku or google app engine for my freebies.

As an aside, I realize how crazy it is to say that a year lease on a vps for free is not a great deal. This is an amazing, magical time for web developers/programmers.

<comment><USER29> _If you exceed any of the limits it all converts to paid services._

That's not how I read: "You also will be charged AWS's standard rates for any use that exceeds the free usage amount provided under the Offer."

<comment><USER42> Maybe I mis-read it. I keep coming back to this line which seems to imply otherwise: When your free usage expires or if your application use exceeds the free usage tiers, you simply pay standard, pay-as-you-go service rates

<comment><USER39> It looks like the 2 different terms are contradictory. We may have to wait and see if they clarify whether you just have to pay the extra fees or if you are completely switched to a paid account if you go over.

<comment><USER42> Of course, it would make sense if you only paid for the 'extra' charges if you went over. It would be kind of sneaky if they charged you for the whole thing if you went over. I hope they do clarify this.

</comment></comment></comment></comment></comment><comment><USER9> This is a great move that will hopefully have the side effect of VPS services reevauting their current plans. Slicehost/Rackspace for starters should have done so a long time ago. Linode is a slightly better option, but they are still going to be under pressure to make a better deal now. A great move by Amazon to help make the entrance into web based software easier. Sadly my needs require around 17 instances so I'm out of luck :P

<comment><USER43> No, I don't believe a $20/month base plan on Linode is a true barrier for anyone seriously considering deploying a real app.

If you can't be sure that $20/month makes sense then you've wasted a lot of time building an app. If you don't have the $20/month then surely anyone capable of developing an app can work for a few hours on a project for someone and make more than enough to cover a year's hosting.

If you just want a shell account to dick about with then Linode isn't for you and I don't think it's unfair to suggest that us folks running businesses off Linode instances don't want your eggdrops and IRC servers on there either.

<comment><USER9> Excuse me, but what exactly are you disagreeing with? I said three things:

1) This move by Amazon is good because it will probably force Rackspace, Linode, et cetera to reevaluate their plans and make better offerings. This doesn't only affect the $20 plan, it affects all the plans. Hell with my requirements I'd be spending $1360 a month in Linode, in which case wouldn't you like paying a Benjamin or two less if you where in a similar position?

2) Anyone that doesn't have any infrastructure in place yet would be a fool not to take advantage of this promotion to help bootstrap their app. Hell if it doesn't work out you saved the equivalent $360 the experiment would have costed you in Linode.

3) That sadly I can't use this promotion because I already have an infrastructure in place consisting of 17 instances and other Amazon services.

Where did I suggest anything about eggdrops and IRC servers? So are you implying Linode is not for me because I need 17 servers? Did you even read the comment before trying to refute something I haven't said?

</comment></comment></comment><comment><USER20> I'm not sure what the Elastic Load Balancer is for when it's only a single EC2 instance.

<comment><USER44> I'm assuming it can load balance to paid EC2 instances also. Even if not, it would let potential customers learn how to use it.

</comment></comment><comment><USER45> Somehow they should work it out so that a credit card is not required. Google keeps spam under control by verifying real people through SMS.

<comment><USER46> I don't think the credit card is meant to reduce spam. It's meant to let them seamlessly charge you for overage.

<comment><USER45> GAE manages to give you the option of not having overages at all.

</comment></comment></comment><comment><USER47> I wonder what this would do for the startup community. Free hosting for a year means, all you really need is an idea.

<comment><USER48> And the ability to turn that idea into an actual product, lest we forget.

<comment><USER47> I was alluding to the initial dilemma of where to host, how to host etc. Ideas without the implementations are just that, ideas.

</comment></comment></comment><comment><USER49> Interesting. Didn't expect that from Amazon. Nice gesture indeed.

</comment><comment><USER50> So how do I deploy RoR onto AWS? </complete-sys-admin-novice>

<comment><USER51> <http://tinyurl.com/2bc43be>

<comment><USER52> That was awesome......it's an even better response than RTFM!</comment></comment></comment>


Ask HN: Quintessential readings for software optimization - <AUTHOR> What are some of the best resources for getting more familiar with stuff like playing nicely with branch prediction, instruction pipelines, and building data to fit well in with CPU cache? <comment><USER2> The best resource in my opinion is still "What every programmer should know about memory." It is now over ten years old but still the most comprehesive and comprehensible post I know about that topic.

[https://lwn.net/Articles/250967/](https://lwn.net/Articles/250967/)

AFAIK there have been no major breakthroughts since that time in memory technology (Transactional memory could be one). While modern processors may be build a bit different (e.g. added shared L3 chache) you will have no problem understanding them.

There is also this github :

[https://github.com/Kobzol/hardware- effects](https://github.com/Kobzol/hardware-effects)

for programs which should show such effects. (I haven't used them yet but they may be interesting for you to play with.)

IT Hare has published a nice article about those costs including rules of thumb costs.

[http://ithare.com/infographics-operation-costs-in-cpu- clock-...](http://ithare.com/infographics-operation-costs-in-cpu-clock- cycles/)

Then there are the Agner tables. Giving you latencies and reciprocal throughput for your instructions.

[https://www.agner.org/optimize/instruction_tables.pdf](https://www.agner.org/optimize/instruction_tables.pdf)

If you are through these you have to read the intel and AMD optimization guides. (ARM may or may not have something similar.)

The paper by Kazushige Goto ("Anatomy of a High Performance Matrix Multiplication") is an example of Cache and TLB considerations in a non- trivial example.

[http://www.cs.utexas.edu/users/pingali/CS378/2008sp/papers/g...](http://www.cs.utexas.edu/users/pingali/CS378/2008sp/papers/gotoPaper.pdf)</comment>


Our startup from idea 'til launch - <AUTHOR> http://blog.observu.com/2014/01/observu-from-idea-till-launch/

<comment><USER2> I'm an early user of Observu. I find Observu a convenient service for monitoring website availability. It is easy to use and thanks to the Observu monitoring dashboard you can drill down quickly to find the reason why your website is slow or even not available.</comment>


Ask HN: How would you teach Java to at risk youth? - <AUTHOR>

I recently had the privilege of being picked to teach Java to at risk youth, but I feel like I am in need of some advice as per where to start.
I'm not having an issue with dealing with the kids, it's just what angle should I start with? Should I start with the basics of what happens when you type "System.out.println()"? the JVM? OOP? Should I just go into how to do variables, loops, and if statements and let them build a slow understanding through use of the language?
thanks so much! <comment><USER2> Show them useful or interesting examples first. If you start on mechanics before application, you'll lose their interest.

Games a great way to do this. It's harder to impress kids these days (to whom "game" is "Call of Duty 4" with a multi-million development budget), but it's still a great way to make the mental connection between "I like games" and "I can make games".

</comment><comment><USER3> That's really commendable.

It'll be easy to bore the kids with tons of details about variables, loops, and structures. At-risk kids are usually less curious and more interested in usefulness (I think).

First, get their attention by giving them the fastest route to a simple working program. Basically just show them that they can make programs that can be useful, then help them build by being a local expert.

You can teach variables, loops, structures as your students need them to make their programs work correctly - that way they'll have a good reason to want to learn.

<comment><AUTHOR> It's not going to be a one day thing. It's going to be a 3 month, twice a week, 2 hours each.

A real course

</comment></comment><comment><USER4> I've done a lot of online self learning. I have to say that udacity's cs101 course has been the most useful resource I've encountered thus far. During the course of the program we built a very basic search engine. I think structuring the program around the goal of a functioning program that's actually interesting was really motivational for a lot of us. Yours could be a web app or a game or whatever, but I think it would be good to have an interesting end goal to build up to from the basics.

</comment><comment><USER5> Does it have to be Java?

I think it's best to start with something that doesn't requiretoo much boilerplate, allows kids to create something cool with a few lines, and has quick feedback. Like turtle graphic in logo or python.

I've heard processing for java allows for writing simple programs without boilerplate, and has nice einvironment. But I didn't used it, so I don't know if it's good for kids.

</comment><comment><USER6> I'd be inclined to go for "cool" fast - games or websites built with really bad imperative code and printf (println?) debugging.

</comment><comment><USER7> You might want to start with the general concept of how algorithms work, what a computer program does, code being a set of instructions that is read by another computer program, flowcharts, and the like.

It depends on how much time you have. If you are only meeting them one day for a few hours, give them a page of code that does something and run through how it works from start to bottom, then give them the basic control and data structures like loops and lists and a simple goal like a blackjack program or number guessing game. You may also want to make (or find online) a cheat sheet of the language keywords and what they do, and hand a copy to everybody.</comment>


Ask HN: How to ask thoughtful questions? - <AUTHOR>

I've been granted one hr with three people who have been very successful in my career. What's the best way to make the most of this? <comment><USER2> Start by practising: try to make this question better, discuss what you think and what you found researching about asking good questions.</comment>


The World's Cheapest Oil Is Already Close to $20 - <AUTHOR> http://www.bloomberg.com/news/articles/2015-12-14/never-mind-35-the-world-s-cheapest-oil-is-already-close-to-20 <comment><USER2> Call me crazy, but I think there's something else going on here. What if Saudi Arabia is having a fire sale?

There's a ton of science that says that we can only pull up half of our current oil reserves to cap climate change at 3 degrees (2 degrees isn't even feasible)[1][2]. That combined with the political and economic tides starting to shift in favor of renewables/nuclear and electric vehicles[3], peak carbon is starting to look like it will happen around 2020 (only 5 years away)[4].

So, if the world will only pull up half of what it already has in reserves, it's a great strategy for Saudi to drive down price and try to make sure most of that half is from their pool. I'm in renewables, and there's a common question we always ask: will oil die at a high price or a low price? It looks like it's going to be a low price.

[1]: [http://www.carbontracker.org/report/wasted-capital-and- stran...](http://www.carbontracker.org/report/wasted-capital-and-stranded- assets/)

[2]: [https://en.wikipedia.org/wiki/Carbon_bubble](https://en.wikipedia.org/wiki/Carbon_bubble)

[3]: [http://www.npr.org/sections/thetwo- way/2015/12/12/459464621/...](http://www.npr.org/sections/thetwo- way/2015/12/12/459464621/final-draft-of-world-climate-agreement-goes-to-a- vote-in-paris-saturday)

[4]: [https://www.iea.org/newsroomandevents/pressreleases/2015/jun...](https://www.iea.org/newsroomandevents/pressreleases/2015/june/iea- sets-out-pillars-for-success-at-cop21.html)

<comment><USER3> This does not match any of the Saudi press statements on the oil situation. The Saudi position and their motivations have been consistent for months with thousands of articles documenting this. In summary, publicly, they are not reducing oil output because in the previous oil crisis, they cut production and suffered heavily vs those who did not. The private reason they are still pumping is that they intend to bankrupt/destroy the US Shale industry. They've done an excellent job at this. These articles with inside information never mention "climate change" or "renewables" as the reason for the situation.

Unless you can show sources showing the price change is because of climate change, this just a delusional conspiracy theory.

<comment><USER4> Why would you assume a market actor is being straightforward about their strategy, especially if others being aware of this strategy would put them at a disadvantage? Deception is a competitive strategy!

<comment><USER3> I never made this assumption.

</comment></comment></comment></comment><comment><USER5> Last time oil dropped so abruptly the Soviet Union fell apart. I wonder what will happen this time.

<comment><USER6> Russia is still looking very vulnerable in that respect. Rosneft's heavy debt burden combined with high inflation in Russia (probably 15% for 2015) is hammering their ability to invest in expanding capacity. Reduced investment also means costs of production are on an upward trend. Then add in the Saudi's moves to increase market share in Northern Europe and it's not looking too good.

<comment><USER7> Do you think Russia is going to break before Venezuela? I would not ever want to bet against how stoic the Russians can be.

<comment><USER8> The socialst government of Venezuela already 'broke' and was voted out in favor of conservatives, due to various reasons, one of them that the socialists could no longer pay for everything with petro dollars.

What more would you assume "break" means for Venezuela?

Russia's government is still in place.

<comment><USER7> We will see what all the voting amounts too in practice in Venezuela. Even if it does mean a change in government and policy there is not much they can do given their financial situation.

</comment></comment></comment></comment></comment><comment><USER9> I have no idea how it can be sustainable, the low prices have frozen all investment on new fields/fracking/exploration, and when we will have a production slump in a few years, it will be followed by a sharp rise, that will be really painful.

<comment><USER7> That is the Saudi plan - knock out the frackers and renewables then jack up the price. Let's hope they don't succeed. They are racking up a lot of debt right now trying to keep a lid on their population problems so they might find their ability to borrow breaks first.

<comment><USER6> Completely agree, to be honest their current strategy is probably the right way to go but that's just because the alternative strategies are even worse. The problem with knocking out fracking is that the frackers can ramp production back up again fairly quickly. Also because the frackers aren't a state run operation and aren't a systemic risk to the Us economy, if the current fracking companies go bust the damage is contained to those companies shareholders. In fact that's largely already happened. Other companies and investors will just move in, take over their operations at a market adjusted discount, and be ready to start producing again when the conditions are right. This will likely put a much lower long term cap on the oil price than we've seen in the past.

<comment><USER7> The history of the airline industry would suggest you are right. A long term low oil price is not very compatible with intent of the Paris accord though.

<comment><USER10> According to a friend who works in politics & energy, the general consensus is that almost all oil will eventually be used. The real battle is over coal, and wether the world will manage to leave some of it in the ground.

<comment><USER7> Oils ain't oils these days. Fracking and oil sands have broken down the division between what is oil and what is not. God help us if we get close to burning even half the coal.

</comment></comment></comment></comment></comment></comment><comment><USER11> It's nothing more than a market share grab. They're simply bullying competitors out of the market. They have deep pockets and it's an ideal time to strike. So they take a calculated loss for the next 2 even 3 years and they gain more market share.... the costs will rise again and so will their payoff.

</comment><comment><USER12> What does ISIS charge? I can't imagine they're in a position to charge much. Then again, I know nothing.

<comment><USER13> There is a Planet Money podcast about the financials of ISIS. They did talk about how the oil is exported, but I don't remember if it included a specific price point.

[http://www.npr.org/sections/money/2015/12/04/458524627/episo...](http://www.npr.org/sections/money/2015/12/04/458524627/episode-667-auditing- isis)

<comment><USER14> They never mentioned a pr. barrel price, but they did say the experts where surprised at how little money they where making given how much oil they where selling.</comment></comment></comment>


Ask HN: Using HTTP GET with request body - <AUTHOR> We are doing a RESTful service that is non-public.  For a request that is read-only and potentially uses 20+ parameters, we are planning to implement it as a GET request that will pass these parameters in the body.
I have seen the well known announcement by Dropbox in 2015: https://blogs.dropbox.com/developers/2015/03/limitations-of-the-get-method-in-http/ and the response in Hacker News: https://news.ycombinator.com/item?id=9133469
As I understand it, there are three potential issues with a GET with request body:
(1)  Not all servers will support this.
(2)  Not all tools will support this (POSTMAN added support this year: https://github.com/postmanlabs/postman-app-support/issues/131)
(3)  There is not yet a consensus on GET with request body.  (For example, is Dropbox still using a POST)
I am not finding too many recent statements about this, I wanted to open up the question here and see what the current opinions are.
I heard that ElasticSearch is using GET request parameters in the body.  It sounds like there are some who are against this approach: https://stackoverflow.com/questions/36939748/elasticsearch-get-request-with-request-body
(1)  Does this make sense for a private server?  (The answer here seems to be yes -- unless I am missing something)
(2) Does this make sense in general?  If the tools needed support it, what is wrong with implementing a RESTful service that requires GET request parameters in the body? <comment><USER2> I'd recommend sticking to POST requests with body that fetches the data you need. I know it's semantically odd because the POST request not creating a "resource" on the server. But it's practically very useful as it'll work well with client libraries, load balancers etc.

You can get some inspiration from GraphQL for your use case. All GraphQL queries are POST requests with body specifying what data the client needs.

<comment><AUTHOR> Thanks! This is exactly what we have decided to do.

Cheers.

</comment></comment><comment><USER3> While there's nothing stopping you from doing so I would be wary about it. Even though the service will be internal you might still need to use third- party software/tools in the future that will be incompatible because of this.

For example, will you need to use a 3rd party request library? Will you need to set up some sort of proxy (NGINX, HAProxy, etc.)? Will you need to use a cloud load balancer (I'm not sure if they would send a request payload for GET requests)?

For open-source solutions you might be able to fork them to add this behavior but why do so to begin with? Is there a specific reason why you don't want to use query parameters?

<comment><AUTHOR> At this point, we have tested all 3rd party request libraries that we will be using. It is possible that DevOps could change start using a new one in the future that would not support a GET request with body.

I agree that it is well worth keeping this in mind and checking on the state of third party support.

Would you happen to know which popular 3rd party tools do not currently support a GET with request body?

</comment></comment><comment><USER4> If you need to have lots of query parameters (I'm assuming that's what you're referring to) then something is wrong in your design. Start by dividing your problem into simpler parts and go from there.

A dumb idea would be to encapsulate various options into a single query parameter. Compressing query parameter's names and values and encoding them in base64 (or some other base of your choice) might also help. But all of this will just add tons of needless complexity to it.

Do you really _NEED_ 20+ query parameters?

I am curious, though. What are you actually trying to achieve here?

<comment><AUTHOR> The purpose of the service is data retrieval based on up to 2,000 ids where the data retrieved can then be aggregated as a csv file. The current service does one id at a time which prevents optimizing the retrieval. Allowing 20+ ids enables 20+ data items to be extracted in a single database retrieval call instead of 20+ separate ones which is currently being done.

So, from my view, the question is whether it is better to use a GET with a request body or use something such as a POST even though the request is read only.

<comment><USER4> Hrmm, I see. Using GET with a request body is undefined behavior as per RFC. What this means is that there's a very high likelihood of things breaking in the future, because each software vendor as their implementation. You'd probably need to test the software you are using internally.

Can't you use a range for said ids? Like

GET /blah?from_id=0&to_id=2000

Or are these said ids distinct from each other, like

GET /blah?id1=v&id2=v&idN=v ...

until id2000?

If the latter is what you're dealing with then this looks like bad design, IMHO. You might need to redesign this if possible, otherwise you'll be building on a house of cards. It's just a matter of time.

<comment><AUTHOR> Each id is distinct so there is no way to list them other than to actually list each id. Typically, this will be 200 ids that are alphanumeric and where a range would include the wrong ones.

Based on the discussion here (thanks to everyone!), we have decided to use a POST instead of GET. :-)

The reasoning is that while GET works fine now, there is always a chance that it will not work in the future either because of security decisions by DevOps or because of use of a third-party tool that does not support GET with request body.

</comment></comment></comment></comment><comment><USER5> I think that only request methods that can use a request body can use a request body. (However, it is only private use, then might not matter.)

One alternative way is to use a different protocol rather than HTTP, if that is applicable for your use. Another way is to make up a new LONG_GET method.

<comment><AUTHOR> As much as possible, we are trying to keep things simple and implement our service in a standard way.

One suggestion was to use a POST instead. On the surface, it seems like a Get with request body seems like such a straight forward approach that I am hoping that this will eventually become standard.

As far as I can tell, the only argument against this approach is that it is not standard. If it was a common approach and there was consistently 3rd-party support, would there be a problem with this approach?

</comment></comment><comment><USER6> Convention should always be adhered to unless you have a really good reason for not doing so. This is especially true for things like REST where convention is the whole point.

</comment><comment><USER7> Keep it simple and just use a POST. Sure, you're read only, but using a request body with a GET is "weird" and non-standard.

<comment><AUTHOR> Yes, that seems to be the alternative. That is what we probably will do if there looks like a reasonable chance that devops will move to a 3rd party tool that does not support GET with a request body.

</comment></comment><comment><USER8> RFC of http protocol allows body content on GET.

</comment><comment><USER9> Another idea. PUT the list of ids and get an ID to that "blob" and in a second request do a GET with the blob ID.

</comment><comment><USER10> I think you should be wary of doing this - it may do weird things with a cache

<comment><AUTHOR> I've heard this. I am clear why it is true. I would appreciate it if you could explain. :-)

I'm not clear why using parameters in the GET request body would do weird things with the cache but using parameters in the POST request body will not hit these issues.

<comment><USER11> In general: GET can have caching, POST should not. However, if you are dealing with internal only systems, it doesn't really matter. Browsers and some tools have optimizations and expectations around what can be done with different HTTP verbs. Maybe your load balancer could see the same GET request and serve a cached value (as long as it counts the body in its caching logic). If you are not hoping to take advantage of GET caching, just stick with a POST.</comment></comment></comment>


Walmart wants you to let delivery people into your home while you're away - <AUTHOR> https://techcrunch.com/2017/09/21/walmart-partners-with-smart-lock-maker-august-to-test-in-home-delivery-of-packages-and-groceries/ <comment><USER2> A lot of older homes in Seattle have a separate entry way/tiny porch that can be locked. When I was looking I didn't really understand the utility, but this would make a lot of sense. I don't think I'd be comfortable letting someone into my house to put away groceries, but I am a little paranoid on that stuff, plus having dogs makes it a tough proposition.

<comment><USER3> Sounds like a "mud room". Or, is it something different? Wish I had one in my house.

So, if you have a mud room (or whatever), put a mini-fridge in it, and you're all set? (Well, added power consumption aside.)

</comment></comment><comment><USER4> The article title is actually

Walmart partners with smart lock maker August to test in-home delivery of packages and groceries

</comment><comment><USER5> Stick one of the consumer security cams in your house and this becomes pretty convenient?

You could even watch them on your phone if that's your thing.

Not that this won't be a tough sell, but (for people without pets), this doesn't seem completely crazy.

Could have a cost edge over chilled delivery boxes.

Not really a thing I want, but I would continue to bet on the general population choosing price and convenience over privacy and security.

</comment><comment><USER6> > This test will also include online grocery orders, which won't just be > placed inside the house like the packages, but will be put away in the > fridge and freezer, when appropriate.

0_0

<comment><USER7> Yeah, I think not. I could see letting them drop the delivery onto an enclosed porch and maybe putting a refrigerator (or ice chest) there, but the idea of giving delivery people the run of my house is a nonstarter.

Have to believe that's true for most other people, too.

</comment></comment><comment><USER8> First they laugh at you, then, actually, they keep laughing at you.

</comment><comment><USER9> I can't imagine anything that could go wrong.

Oh, and what about the dogs?</comment>


Support.cloudflare.com down - <AUTHOR> Trying to resolve an issue regarding CF ECDSA certificate for the last 15+ hours and now can't check the ticket:
This page (https://support.cloudflare.com/hc/en-us) is currently offline. However, because the site uses CloudFlare's Always Online™ technology you can continue to surf a snapshot of the site. We will keep checking in the background and, as soon as the site comes back, you will automatically be served the live version. Always Online™ is powered by CloudFlare | Hide this Alert
I loved CF until 8/24/16 when they issued a new SSL cert for my domain.  I know CF loves ECDSA but they did not check if my server supported ECDSA before changing the cipher suite.  Just roll back to whatever algo was being used before if sane, but for the love of Pete, before issuing the certificate:
 1) check to see if the server supports the proposed algo,
 2) notify the user if the user's server does not support the algo
 3) allow the user time to investigate and implement options
 4) potentially issue a certificate that works on the customer's server (just like it did for over a year).
Normally not a big deal, but this domain is hosted on a shared host (it was more of a test to check out Cloudflare).  I don't have anyway to update the server to use ECDSA, though I put in a support ticket with the host and they said, "No. We will not support ECDSA but do support a list of other EC algos".  Obviously, I am going to move away from this host...and CF.
In any case, their support response is slow, but this site was using the free plan...and now their support site is down.
Any suggestions for CF alternatives?
[edit: the support site is now up 10:48PST] <comment><USER2> CloudFlare to Origin supports algorithms other the ECDSA. Sounds like you're having issues, not CloudFlare.

CloudFlare only support ECDSA on the free plan from client to CloudFlare. If this is what you're having issues with, then you're on an old browser.

<comment><AUTHOR> Thanks for trying to help, but I'm using FF 44.0.x and Chrome 52.0.27x. The disruption occurred when CF generated a new cert with ECDSA, the old cert worked fine, until it expired.

[https://support.cloudflare.com/hc/en- us/articles/200278659-E...](https://support.cloudflare.com/hc/en- us/articles/200278659-Error-525-SSL-handshake-failed)

A 525 error states that the SSL handshake between CloudFlare and the origin server that hosts the domain failed. This means that CloudFlare is set to use Full SSL in the CloudFlare settings for the domain, so CloudFlare attempts to make a connection using SSL (for requests beginning in [https://](https://)) to server that hosts the domain.

Likely reasons for this failure include:

The origin server does not support or is not configured properly for SNI. The cipher suites that CloudFlare accepts and the cipher suites that the origin server uses do not match. The origin server is not configured to use SSL and Full SSL is enabled in the CloudFlare settings.

"The cipher suites that CloudFlare accepts and the cipher suites that the origin server uses do not match." <\- This. This is the issue. Again, I verified with the host and they do not plan on supporting ECDSA_P256 specifically, but do support other Elliptical Curve algos. So yes, it is an issue on my end but only to a point, the fallback certs that CF generates and manages aren't 'falling back'. There is no option to manage fallback certs on Free plan, that's fine, but the CF-provided fallbacks should have worked! Again, the issue is they generated a cert with a specific algo and presented that cert to my users without checking first to see if the server supported that algo. Make a cert signed with a random algo and who cares if it works or not? WTH?

Again, I am not asking for tech support here. I am researching CloudFlare alternatives though to begin the process of setting up new accounts to prepare for moving from CloudFlare before those domains suffer the same fail when their CF certs expire. CF was great until it wasn't.

</comment></comment><comment><USER3> The site seems to work fine, but this really isn't a support forum for such issues. Send them another email or something

<comment><AUTHOR> Thanks for the tip. I didn't ask for support here. I think this issue is interesting because CF's decision(s) are experimental and they do not check if a server supports ECDSA prior to issuing the cert, which resulted in any links to [https://mysite.com](https://mysite.com) erroring out "this site isn't secure" and a 525, until I paused CF, and have since deleted the domain from CF, use a different (compatible) SSL cert, updated DNS records to not point CF's nameservers, etc. Perhaps CF will implement a change to check to see if the customer's server supports an algo before signing a cert with it.</comment></comment>


Show HN: Stackoverflow as a Search – Search engine for programmers - <AUTHOR> https://recalll.co/?q=php%20explode <comment><AUTHOR> It would be great if someone provides feedback on further improvements. TIA</comment>


The AWS Controllers for Kubernetes - <AUTHOR> https://aws.amazon.com/blogs/containers/aws-controllers-for-kubernetes-ack/ <comment><USER2> Currently no support for provisioning IAM permissions. ACK will be happy to construct an S3 bucket for you, that is then inaccessible, unless you use dangerous IAM wildcard permissions.

Team is concerned about the security ramifications of setting up IAM permissions from ACK: [https://github.com/aws/aws- controllers-k8s/issues/22#issueco...](https://github.com/aws/aws- controllers-k8s/issues/22#issuecomment-595816197)

Look, it'll be great when it matures... but this is very much in the developer preview stage. Caveat emptor.

</comment><comment><USER3> Am I the only one who's pessimistic about this? One of the big upsides of Kubernetes is having portable workloads and provisioning cloud-provider specific resources (whose lifecycles very likely outlive clusters!) in Kubernetes just seems wrong to me. Kubernetes is great for managing, orchestrating and directing traffic for containerized workloads but it really shouldn't be The One Tool For Everything.

Coupling everything together like this just seems to make things less manageable.

IMO infrastructure including managed services are better provisioned through tools like Terraform and Pulumi.

<comment><USER2> The issue (or benefit, depending on your perspective) with Terraform is that it's a one-shot CLI binary. If you're not running the binary, then it's not doing anything. If you want a long-running daemon that responds to non-human- initiated events, then Terraform isn't a good tool.

Any time you try to declaratively define state, if you don't have a daemon enforcing the declarative state, then you will suffer from drift. One approach is the one Terraform has - assume that drift is possible, so ask the user to run a separate plan stage, and manually reconcile drift if needed. Another approach is the controller approach, where the controller tries to do the right thing and errors/alerts if it doesn't know what to do.

<comment><USER4> This is why Hashicorp needs to accelerate their cloud offering.

Frankly I get the sense they got a little bit too addicted to central ops driven on-prem style deals for Vault but in the public cloud they need to be front and center with SaaS which is a long road. They have a rudimentary Terraform SaaS I believe but none for Vault as far as I'm aware. I see a lot of folks going straight to cloud provider services because of this.

You sum it up well... In these times you don't want to run a daemon

<comment><USER5> They used to have a managed Vault offering! But then it disappeared one day never to return.

</comment></comment></comment></comment><comment><USER6> Kubernetes is becoming the lingua-franca of building infrastructure. Through CRDs and the kube api spec I can

\- start an single application

\- deploy a set of interconnected apps

\- define network topologies

\- define traffic flows

\- define vertical and horizontal scaling of resources

And now I can define AWS resources.

This creates an interesting scenario where infrastructure can be defined by the k8s API resources and not necessarily have k8s build it. For example podman starting containers off a K8S deployment spec. It's an API first approach and its great for interoperability. The only downside is managing the yaml and keeping it consistent across the interdependencies.

<comment><USER7> I really wish fabric8, and more specifically kotlin k8 dsl[2] was getting more traction.

It removes the down side of yaml all over the place. It's missing the package management features of helm. But I have several jars acting as baseline deployments, and provisioning. It works really well, and I have an entire language. So I can map over a list of services, instead of do templating. The other big down side is a java run takes a minute or two to kick off

I was resilient to k8 for a long time. Complexity was secondary to cost, but Digital ocean has a relatively cheap implementation now. This commonality and perseverance of tooling is great.

I want metrics, a simple annotation. I want a secret injected from vault, just add an annotation. It's also cloud agnostic, so this logic can be deployed any where some one provides a k8 offering.

EKS was very powerful. As running service accounts via non managed clusters. Removed the need to pass an access key pair to the application. That service account just ran with a corresponding iam role.

[1] [https://github.com/fabric8io/kubernetes- client](https://github.com/fabric8io/kubernetes-client) [2] [https://github.com/fkorotkov/k8s-kotlin- dsl](https://github.com/fkorotkov/k8s-kotlin-dsl)

<comment><USER6> It's been a while since I've looked at Fabric8 but it had good java -> k8s integration and was great for writing k8s tools.

It appears though that Fabric8 is useful for solo java projects without complex dependencies on non-java projects or small java shop. It overlaps with where jenkins-x is going, which has made major strides in the last 24 months.

The original team that worked on Fabric8 lead by James Strachan all moved on from Redhat and many of them are working on Jenkins-x.

</comment></comment></comment><comment><USER8> Glad to see AWS finally embracing Kubernetes too. Google did a similar thing a while back - [https://cloud.google.com/config- connector/](https://cloud.google.com/config-connector/) So I guess this solidifies Kubernetes as the defacto standard of Cloud Platforms.

<comment><USER9> Azure as well [https://github.com/Azure/azure-service- operator](https://github.com/Azure/azure-service-operator)

<comment><USER10> Bold of you to assume that:

* the magic permissions ghost that runs in Azure whose job it is to inexplicably deny you resources to things won't interfere

* Said Azure service will stay up long enough to be useful

* you finish writing the insane amount of config Azure services seemingly require before the heat death of the universe.

* Azure decides that it likes you and won't arbitrarily block you from attaching things to your cluster/nodes because it's the wrong moon cycle/day of the week/device type/etc

* you can somehow navigate Azures kafka-esque documentation got figure out which services you're actually allowed to do this with.

It is only a slight exaggeration to say that Azure is the most painful and frustrating software/cloud product I've used in a long time, probably ever, and I earnestly look forward to having literally any excuse to migrate off it.

<comment><USER11> I'm feel your pain also my friend. Azure quality is terrible compared to competitors:

* no good working examples in docs

* docs hard to read

* docs are not consistent with reality

* the web portal UX is inconsistent and outright weird (when you navigate through resource group, you can scroll back horizontally to previous context/screen; what a joke)

* there are a gazillion preview api versions that never gets released officially.

* and if you're lucky to work with azure devops, it's like building a house of cards with different card types and sizes

I've worked with AWS and GCP in the past. Indeed Azure is often chosen by CIO's rather than people that have to work with the service every day.

<comment><USER10> Oh my god the web UX, how did I forget about that: for the life of me I cannot figure out why they make all the interfaces scroll sideways. Why? Who does that?

Docs being hard to read and inconsistent with reality is a big point. My favourite mismatch is the storage classes one: it turns out there's actually 2 different grades of SSD available, but their examples and docs only mention premium SSD's. I only discovered "normal" SSD because they happen to auto- create a storage class with them in your Kubernetes cluster. The adventure to figure out whether you can attach a premium SSD to an instance is a whole new ball game - trying to find which instances _actually_ allow you to attach them is like looking for a needle in a haystack. Why are they so difficult about it? AWS is like "you want an EBS volume of type io1? There you go, done". Azure: "oh no, you _can't_ have premium ssd. Because reasons".

<comment><USER12> Actually there are three kind of SSD storage types in Azure: Standard, Premium and Ultra. I'm assuming that you need to provision an 's' VM because the regular instances lack the connectivity for the faster storage, but that's just guessing.

<comment><USER10> Oh I forget about the ultra ones.

I found a few instance types when I went looking, but their interface does not make it easy to figure out which ones are premium eligible, but I do remember the price going up not-insignificantly for a premium capable machine, which feels about like double-dipping if you're also paying extra for the SSD.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I can't decide if I think this is a good idea or not. Conceptually I like that I can get a s3 bucket/rds db/sqs queue by using kubectl but I'm not sure if that's the best way to manage the lifecycle, especially on something like a container registry, that likely outlives any given k8s cluster.

<comment><USER14> Why are these clusters going away?

<comment><USER13> We rebuild ours all the time. New config, k8s version upgrade, node OS patching.

<comment><USER14> Interesting. I'm only familiar with Mesos/Aurora, which is often considered outdated next to Kubernetes, but it can do all those things in place.

Do you end up with a "meta-kubernetes" to deploy kubernetes clusters and migrate services between them?

<comment><USER8> You definitely can do the same with Kubernetes too, just that the scope is too large and it doesn't have a good reputation with rolling updates of controlplane.

> Do you end up with a "meta-kubernetes" to deploy kubernetes clusters and > migrate services between them?

Congratulations, you just discovered the ClusterAPI

</comment></comment></comment></comment></comment><comment><USER15> Here is my container: run it. Where is my url? The end.

No, I don't want Terraforms, puppets, yaml files, load balancers, nodes, pods, k8s, chaos monkeys, Pulumies, pumas, unicorns, trees, portobilities, or shards.

I love cloudrun and fargate. Cloudrun has like 5 settings, I wish it had like 2.

<comment><USER16> I too want simplicity, but Fargate still requires a load balancer in most cases. Further, you'll probably need a database (we'll assume something like Aurora so you needn't think about sharding or scale so much) and S3 buckets at some point, and security obligates you to create good IAM roles and policies. You'll need secret storage and probably third-party services to configure. Things are starting to get complex and you're going to want to be able to know that you can recreate all of this stuff if your app goes down or if you simply want to stand up other environments and keep them in sync with prod as your infra changes, so you're going to want some infra-as-code solution (Terraform or CloudFormation or Pulumi etc). Further, you'll probably want to do some async work at some point, and you can't just fork an async task from your Fargate container (because the load balancer isn't aware of these async tasks and will happily kill the container in which the async task is running because the load balancer only cares that the connections have drained) so now you need something like async containers, lambdas, AWS stepfunctions, AWS Batch, etc.

While serverless can address a lot of this stuff (the load balancer, DNS, cert management, etc configuration could be much easier or builtin to Fargate services), some of it you can't just wave away (IAM policies, third party servic configuration, database configuration and management, etc). You need some of this complexity and you need something to help you manage it, namely infra-as-code.

<comment><USER17> Cloud run is one of my favorite cloud services. It's so easy to use and cheap for low traffic things. I set one up last year. GCP bills me 5 cents a month (they have no shame billing in cents)

[https://issoseva.org](https://issoseva.org) hasn't ever gone down.

</comment></comment></comment><comment><USER18> At the risk of being early, RIP CloudFormation.

I posited that this was the benefit in knowing Kubernetes all along, and possibly the ace up GCP's sleeve -- soon no cloud provider will have to offer their own interface, they'll all just offer the one invented by Kubernetes.

<comment><USER19> There is also the AWS CDK ([https://aws.amazon.com/cdk/](https://aws.amazon.com/cdk/)) which is essentially lets you use your favorite language like Typescript or Python to generate CloudFormation, with an experience similar to Terraform. We've been experimenting with instead of TF, hoping it's here to stay.

<comment><USER20> Take a look at pulumi; it provides a programmatic interface and related tooling on top of terraform.

<comment><USER18> Took the comment right out of my keyboard (?) -- these days whenever I talk about devops with people, I bring up pulumi. HCL and and almost all config- languages-but-really-DSLs are a death sentence.

I am very unlikely to pick terraform for any personal projects ever again, imagine being able to literally drop down to AWS SDK or CDK in the middle of a script and then go back to Pulumi land? AFAIK this is basically not possible with terraform (and terraform charges for API access via terraform cloud? or it's like a premium feature?)

</comment></comment></comment></comment><comment><USER21> Orchestration tools are the way forward especially when it comes to on-demand video compression - it's helpful to have the tools to be able to spin up 100s of servers to handle peak loads and then go down to nothing. Kubernetes is so helpful in this.

<comment><USER22> Would AWS spot instances be useful here?

<comment> big-malloc Currently the cluster autoscaler supports using a pool of spot instances based on pricing, which is super helpful for test clusters, and there are some other tools available to ensure that you can evict your spot nodes when amazon needs them back

</comment></comment></comment><comment><USER23> This is great!

Are other companies doing similar things? e.g. I would love to be able to set up Cloudflare Access for services in k8s

<comment><USER13> GCP (Config Connector) and Azure (Service something) both have similar things. I've not heard of it happening outside a managed k8s env.

<comment><USER8> [https://crossplane.io](https://crossplane.io) is doing a multi-cloud one

<comment><USER9> I like their work, but their OAM centricity is too heavy an opiniation.

<comment><USER24> disclaimer: I'm a maintainer on Crossplane.

OAM is an optional feature of crossplane - you don't have to use it if you don't want to

<comment><USER9> Good to know, at least that warm me up to crossplane further. The messaging might need update, including within the docs. I mean - crossplane is _the_ OAM implement - coupled with OAM sprinkled all over docs, gave me very different impression.

This aside, I think crossplane work is interesting.

</comment></comment></comment></comment></comment></comment><comment><USER9> There is now secular push towards use of custom operators instead of OSB. I wonder what finally caused this.

<comment><USER25> A mix of factors, I think.

1\. OSBAPI is not widely known outside of the Cloud Foundry community it came from. In turn that's because Cloud Foundry is not widely known either. Its backers never bothered to market Cloud Foundry or OSBAPI to a wider audience.

2\. It imposes a relatively high barrier to entry for implementers. You need to fill in a lot of capabilities before your service can appear in a conformant marketplace. With CRDs you can have a prototype by lunchtime. It might be crappy and you will reinvent a whole bunch of wheels, but the first attempt is easy.

3\. Fashion trends. The first appearance of OSBAPI in Kubernetes-land used API aggregation, which was supplanted by CRDs. Later implementations switched to CRDs but by then the ship was already sailing.

4\. RDD. You get more points for writing your own freeform controller than for implementing a standard that isn't the latest, coolest, hippest thing.

It's very frustrating as an observer without any way to influence events. OSBAPI was an important attempt to save a great deal of pain. It provided a uniform model, so that improvements could be shared amongst all implementations, so that tools could work against standard interfaces in predictable ways, so that end-users had one and only one set of concepts, terms and tools to learn. It also made a crisp division between marketplaces, provisioning and binding.

What we have instead is a mess. Everyone writing their own things, their own way. No standards, no uniformity, different terms, different assumptions, different levels of functionality. No meaningful marketplace concept. Provisioning conflated with binding and vice versa.

It is a medium-sized disaster, diffuse but very real. And thanks to the marketing genius of enterprise vendors who never saw a short-term buck in broad spectrum developer awareness, it is basically an invisible disaster. What we're heading towards now is seen as _normal_ and _ordinary_. And it drives me bonkers.

<comment><USER9> I'd agree on the mess. I also find it on over-engineered side. Do I really need service discovery of services that I already know of, from AWS GCP...?

<comment><USER25> If you want a little from column A and a little from column G, having a single interface is pretty helpful. It's easier to automate and manage.

</comment></comment></comment></comment><comment><USER26> The approach of generating the code from the existing Golang API bindings means that hopefully this project will get support for lots of resources pretty quickly.

Excited about this, though you do wonder whether it'll suffer the same fate as Cloudformation: the Cloudformation team finds out about new feature launches the same time that the general public does. If the Kubernetes operator lags behind, you're going to have to fall back to something else if you need cutting edge features.

</comment><comment><USER27> Seems odd there is no controller for EC2 or even planned on the roadmap [https://github.com/aws/aws- controllers-k8s/projects/1](https://github.com/aws/aws- controllers-k8s/projects/1)

<comment><USER28> It's not weird at all. A prime use case for this is to use Kubernetes itself for the compute layer and orchestrating peripheral AWS components using Kubernetes as the common control plane.

You can orchestrate entire application stacks (pods, persistent storage, cloud resources as CRDs) using this approach.

<comment><USER8> There is a fairly decent demand for orchestrating VMs using kubernetes (kubervirt), many legacy apps are too expensive to be rewritten in a cloud native way

</comment></comment></comment><comment><USER29> This is nice from the app manifest perspective because you can declare your database right along side your deployment.

The provisioning time of a deployment and an RDS instance is very different though. This is probably most useful when you're starting a service up for the first time. This is also when it's not going to work as expected due to that latency of RDS starting up while your app crashed repeatedly waiting for that connection string.

This would be really nice for buckets and near instant provisioned resources, but also kinda scary that someone could nuke a whole data store because they got a trigger finger with a weird deployment and deleted and reapplied it.

My feelings, they are mixed. :D

</comment><comment><USER30> Kubernetes is supposed to be cloud vendor agnostic; the cloud vendors counter that by having extension operators to create some tie in to the kubernetes deployment of their making.

I guess the 'kubernetes' way would be to create a generalized object for 'object store', that would be implemented by means of s3 on aws and on azure it would be done as blob storage.

Now with this approach you can only do the common features between all platforms, you would have a problem with features exclusive to aws for instance, or you would need some mapping from a generalized CRD object to specific implementation of each platform.

</comment><comment> 1-KB-OK Interesting how they enforce the namespaced scope for ACK custom resources. This is a logical design choice but makes it trickier for operators to use.

Say I have an operator watching all namespaces on the cluster. Since operator CRDs are global in scope it makes sense for some operators to be installed as singletons. A CR for this operator gets created in some namespace, and it wants to talk to s3 -- it has to bring along its own s3 credentials and only that CR is allowed to use the s3 bucket? You can imagine a scenario where multiple CRs across namespaces want access to the same s3 bucket.

</comment><comment><USER31> Everything from DNS to AWS SDKs gets reinvented in Kubernetes. It is the most anal approach of Infrastructure design I have ever seen in the last three decades. A good design builds on the things that are already there and does not goes around trying to change every well established protocol in the world.KISS.

</comment><comment><USER32> This feels like Crossplane.io but limited to only AWS. Kelsey seems to think the same [https://twitter.com/kelseyhightower/status/12963213771342315...](https://twitter.com/kelseyhightower/status/1296321377134231552)

</comment><comment><USER33> This has been posted a couple times, but GCP has an equivalent that's been around for a while:

[https://cloud.google.com/config- connector/docs/overview](https://cloud.google.com/config- connector/docs/overview)

disclaimer: I work at GCP.

</comment><comment><USER34> Wow. Now we can directly manage AWS services from Kubernetes.

Github: [https://aws.github.io/aws- controllers-k8s/](https://aws.github.io/aws-controllers-k8s/)

On a different note, recently I was looking to learn AWS concepts through online courses. After so much of research I finally found this e-book on Gumroad which is written by Daniel Vassallo who has worked in AWS team for 10+ years. I found this e-book very helpful as a beginner.

This book covers most of the topics that you need to learn to get started:

If someone is interested, here is the link :)

[https://gumroad.com/a/238777459/MsVlG](https://gumroad.com/a/238777459/MsVlG)</comment>


Ask HN: What free public data-sets do you find most useful or interesting? - <AUTHOR> <comment><USER2> [http://planet.openstreetmap.org/](http://planet.openstreetmap.org/) \- free, but the ODbL license requires attribution and has restrictions on mixing data sets.</comment>


Protect Your Site with a Blackhole for Bad Bots - <AUTHOR> http://perishablepress.com/press/2010/07/14/blackhole-bad-bots/

<comment><USER2> I've worked at places that have tried this trick. It doesn't work - it's always been removed because of real users complaining they've lost access.

Several scenarios can trigger it, and probably more. The internet is a weird place. Consider:

1\. Some clients, browser plugins, and proxy servers implement link prefetching. These agents will not care that the link is attached to a 1px gif that the user won't see. This is not really breaking the rules, either, it is quite permissible and in the scope of HTTP implementations - unless you've put your black hole behind a form POST (which bots won't for anyway.)

2\. Internet explorer among other tools allows users to download content for offline viewing. The client does not respect robots.txt when such fetching has been initiated by a user.

3\. Not all users browse the web visually, and your 1px gif is discriminating against the visually impaired. When browsed with a screen reader, a linked image is a linked image is a linked image.

Additionally, outright blacklisting by IP address as noted by others on this thread is highly problematic, especially when the behavior that triggers it could accidentally come from real users behind a NAT firewall (at a typical office, library, etc). A single user performing any of the above behaviors would block the entire group from the service.

There are better ways to fight misbehaving robots that do not so easily trigger false positives...

<comment><USER3> I would suggest burying the "bad link" several pages deep under the blackhole. (i.e. get a page, with a link, which leads to another page that has another link, etc, etc.)

The spider will crawl all the way down, but real users and prefetch won't. (I'm not sure about offline, but I can't imagine they go down very far.)

<comment><USER4> And in case the user does end up triggering it, perhaps also replace the "You have been banned" page with a captcha challenge to get yourself removed from the blacklist.

</comment></comment></comment><comment><USER3> If you do this, create the robots.txt first, then wait a week or two!

Only then activate the actual blackhole.

The reason is that robots do not download robots.txt each time, they can, and do, cache it for quite a while, especially for sites that don't change much.

</comment><comment><USER5> So this is just to ban non-targeted crawlers? Any particular reason you'd want to ban crawlers from your site? Surely your server is up to the task of serving a few extra requests, enough so that it's not worth your time adding code (and slowing down good requests) to restrict them.

The kind of bot that I care about are the ones that spam up my content site. They only go to pages that real users visit (the "Post Stuff" page), so this trick wouldn't help against them. And they never post from the same IP twice, preferring to hop between infected machines on a botnet every time they make a post.

I'm curious what sort of traffic pattern this author is seeing that would motivate him to build this.

</comment><comment><USER6> _Whitelisting these user agents ensures that anything claiming to be a major search engine is allowed open access. The downside is that user-agent strings are easily spoofed, so a bad bot could crawl along and say, "hey look, I'm teh Googlebot!" and the whitelist would grant access._

How many of these so-called "bad bots" already do this sort of spoofing? Would usage of these techniques only encourage such behavior?

</comment><comment><USER7> A few bad ideas here:

1) Blocking by IP address. (AOL and Universities come to mind.)

2) nofollow links are followed by search engines and users alike. (display:none is ignored by some text-based browsers that ignore CSS.)

<comment><USER8> Also: whitelisting anyone with "googlebot" in their user-agent. That's like letting anyone in at the White House just if they turn up with an Obama mask on.

</comment></comment><comment><USER9> If your site becomes popular this could become a target for trolls. Eg. in some forums trolls will post a fake link to a logout page, this is why sites should use POST or private keys for logging out. If you implement this blackhole it will become a much more serious target.

</comment><comment><USER10> This is pretty neat.

Something we did at $company[-2] is we had a block of IPs that weren't used for customer traffic. If something hit them (SSH login attempts, HTTP GET requests that were looking for RFI vulnerabilities, etc, etc) the IP would be firewalled from the entire network for a period of time (generally 2-3 days).

</comment><comment><USER11> This is okay, but what would happen if someone writes a popular flash client that pulls data from a site using that blackhole.php?

The clients could access the data once then blocked out forever?

</comment><comment><USER12> Against what, exactly, does this protect? And why?

"Bad bots" are the least of my worries, and if I were to protect against anything, I'd protect agains excessive requests per second.

</comment><comment><USER13> There are some interesting ideas to work around the problems with this method in the comments, such as hashing the ip with a secret string on the link to stop others making you ban all your users. And also sorts of other stuff - even putting a CAPTCHA on the ban page as an escape method. But in the end I think the method is flawed:

1) a singled infected computer on a network could take out a large number of users. 2) any thing doing prefetching will cause them to be banned. 3) there is a risk of taking out valid bots, and verifying them correctly is just too expensive for a large site.

My main issue with bots is their spam, so I just use tools like Akismet to keep that under control.

</comment><comment><USER14> robots.txt is malformed in this example:

      Disallow: /*/blackhole/*

This line won't work even for good robots (robots.txt doesn't have wildcard characters).

</comment><comment><USER15> Wouldn't using a hidden link also subject you to a possible penalty from Google and other search engines?

</comment><comment><USER16> Implementation is very weak. It reads whole blacklist, line by line (could have used sqlite at least), and uses extract() to emulate register_globals misfeature on hosts that disabled it (and it doesn't even check for disabled register_globals properly).

</comment><comment><USER17> Would like to see how someone implements this type of blocking in a rails app.</comment>


LinkedIn Wants Users to Connect More - <AUTHOR> http://online.wsj.com/article/SB10001424052748704905704574622191027266548.html?mod=WSJ_hps_sections_careerjournal

<comment><USER2> I view LinkedIn solely as an online resume site. I believe a better route for LinkedIn would be to compete with Monster.com or CareerBuilder and build a social networking job site. With all the "resumes" currently stored on LinkedIn it is probably one of, if not the largest, holders of personal job/work experience in the world.

A business idea would be to create a mashup of sorts pulling information from users profiles and matching them with potential career opportunities on a job board site. LinkedIn could then charge a premium for providing the user and/or the company with a list of potential job opportunities and/or potential candidates. Taking it one step further would be to incorporate some form of background check/education verification into the platform for the companies. A user could select whether they are open to receive job postings or be included in job searches by companies. They could also select which types of companies they want to be included in. I am sure that LinkedIn could develop some sort of algorithm to provide benefit to the job seeking users while at the same time reducing potential spam in the users inbox.

Taking the idea one step further would be to charge a fee for resume assistance in helping users build their profiles to highlight current and past experiences. Many times I know (myself included) that users just list the company name/job title and do not include what they did at the company.

</comment><comment><USER3> LinkedIn should let users post an online "portfolio" of their work. This would be hugely useful for designers, but could be extrapolated to a general solution for everyone. Programmers could link to Github repos and/or production projects. I'd love to show the photos and news coverage of the solar car I built and raced back at University...

This could be relatively straightforward to do and could be hugely valuable for both job-seekers AND employers looking for candidates.

<comment><USER4> Can't you already post links now? Isn't it better to link to a site that does a good job of hosting portfolios instead on expecting LinedIn to handle that well?

<comment><USER3> I think you can post three links.

Considering the full potential of the web (cheap storage and easy access) why is LinkedIn still limiting itself to just textual information? I'm not expecting them to do it, but it would be a natural extension to their current business.

</comment></comment></comment><comment><USER5> > turns a profit from ads and _recruitment services_

I spent a lot of time working on a startup in a related space, and came to realize that the real customers of LinkedIn are the recruiters. As long as they can get you to enter your details, they can get thousands of dollars a year from individual recruiters for access to your information.

Look at their site as a service for recruiters which happens to require consumer input. They want you to be promiscuous in your connections, since weak-but-wide links are more effective for recruiting than strong-but-narrow 'true friendships'. They don't have much incentive to drive users to interact with the site, beyond keeping their details up-to-date.

It sounds like they're interested in becoming more compelling to consumers, but I wonder how deep that commitment goes when there's no immediate revenue stream from it?

Here's one older article that discusses LinkedIn's revenue model: <http://www.nytimes.com/2008/06/18/technology/18linkedin.html>

</comment><comment><USER6> Use the News and Discussion features of linked in to drive traffic to client Wordpress blog articles. It's a soft sell mechanism, a gateway for offers on the blog page. I am always pleased with the quality targeted traffic I get through this process.

If your tired of paying for $1.00 click thrus, the silly keyword scoring BS, rampant competitor click fraud, and not knowing anything about your traffic unless it converts, switch tactics.

I don't give a hoot about how Linked In makes its buck. A free account allows you to join 50 groups. If you setup a profile aimed at your target demo, and then join the right groups, you can post a weekly blog article notice that gets seen by 250k+ real human beings that actually converse about the topics you write about.

If you are a smart cookie you can leverage low cost labor for about $25 a week to write the article, post the notice across 50 groups, and average about 5000 real nice visitors a week. No click fraud, engaged readers, 1-2% conversions for your paying adv's. What would the same 20,000 clicks cost you on Google?

That's what Linked In is good for...

And Twitter too...

Facebook, not so much...

Facebook is useless for this, as a personal account maxes at 5k. Useless.

</comment><comment><USER7> If LinkedIn want greater engagement, they need to start offering professional functionality that is useful on a day to day basis. LinkedIn Answers is okay, but they would do very well to partner with StackOverflow (or do their own take on the StackExchange platform) for example.

Offering tools like TripIt is a good start. They should try and expand their applications to things like expense tracking, etc, while also doing a better job of making the applications visible and useful.

<comment><USER8> Agree, I find that LinkedIn does little for me. I'm not in sales or marketing, and I'm not currently looking for a job. There's just no reason for me to log in to LinkedIn daily, or with any real frequency at all.

</comment></comment><comment><USER9> What I have never understood about LinkedIn: If I am looking for a new job, why would I want my current cow-orkers, including managers at my current employer, to know about it? Keeping your profile up to date is one thing; soliciting recommendations from current cow-orkers is a broad hint and setting your status to be "is looking for a new job" is blatant. How can it possibly work?

<comment><USER10> I heard an interesting story that Yahoo pays LinkedIn lots of money to figure out which of their employees are looking to leave in order to offer incentives to get them to stay.

Certainly, employers could do the opposite with that information and let you go, but that's about as simple of a way to get a raise as I could think of (assuming your the type of employee they want to keep around).

</comment></comment><comment><USER11> Competing with CareerBuilder and Monster is a waste of time. Both of these sites will eventually become irrelevant -- searching for a job by typing in a few keywords is unnatural. People hear about jobs thru friends, professional acquaintances, work product (GitHub, StackOverflow, etc), and local businesses (signs) and as LinkedIn becomes more prevalent they will grab more then their fair share of this market without trying very hard.

The far bigger opportunity for LinkedIn is to aggregate business leads. Are you looking to outfit your company with new laptops this year, looking for a block of hotel rooms for a conference, looking for an event management company, looking to upgrade accounting systems. Each of these leads is worth hundreds of dollars and helping businesses find good vendors is not easy (consultants make billions of dollars/yr making vendor recommendations).

<comment><USER12> The existence of the recruiting industry belies that claim. The job market is incredibly inefficient: I would bet that no professional in a big city could name more than 10% of the people who would be willing to employ him at that moment.

Most of the jobs I see and hear about are of no interest to me; I can search careerbuilder (or LinkedIn) and instantly find some jobs that are relevant.

<comment><USER11> The recruiting industry will not go away, but sites like CareerBuilder and Monster as major players within the recruiting industry will. The value of matching job seekers to jobs is far more efficient within LinkedIn.

</comment></comment></comment><comment><USER13> If Linked-In ever wants us to connect more often, first they should lower their subscription prices. At $25/month, it's a rip-off, and without a subscription the site looks useless and is not worth visiting too often.

I'm currently subscribed to the rival social networking site Xing.com at about 5.5 EUR/month and satisified with the service being provided.

</comment><comment><USER14> A social site bending over backwards to be perfectly devoid of fun. Is it any wonder the users don't interact more?

<comment><USER11> Why does something need to be fun in order to be consistently useful? Search is not fun but I do it multiple times a day.

<comment><USER14> I certainly didn't say that it did...I only suggested that some sort of amusement (at the very least: discussion) might be an important part of interaction.

But, since we're making rhetorical straw men: what does their desire for users to interact more have to do with the site being useful?</comment></comment></comment>


Flares is a CloudFlare DNS backup tool - <AUTHOR> https://asciinema.org/a/249730 <comment><USER2> I too enjoy taking my keys to the kingdom and piping a bash script with it to do stuff.

</comment><comment><USER3> Well done. But you can use cf-terraforming easily. "cf-terraforming is a command line utility to facilitate terraforming your existing Cloudflare resources."

[https://github.com/cloudflare/cf- terraforming](https://github.com/cloudflare/cf-terraforming)

<comment><USER4> terraform != text/dns

Lots of DNS tools speak text/dns natively - and being able to easily get all zones in that format makes things like export / point in time backups much easier.

</comment></comment><comment><USER5> Shameless plug: After doing this kind of thing manually for a while, I created a service a few years ago to backup and alert you on DNS changes for all of your providers (CF, AWS, DO, Linode, etc). It's free for one domain if anyone wants to take it for a spin: [https://zonewatcher.com/](https://zonewatcher.com/)

</comment><comment><USER6> I added an equivalent script after we moved to Cloudflare. I found it's easy to make a mistake in the Cloudflare DNS web interface, e.g. it's easy to accidentally remove an entry.

Now, at every deploy to production, we do a backup of the DNS configuration on Cloudflare and save it on S3. This hardly costs us anything as each backup is only a small text file. But I now feel much more comfortable when editing our DNS config.

<comment><USER7> For text, I'd lean to preserving that in a git repo instead.

<comment><USER8> Or even use a git-repository as your source of DNS truth!

[https://dns-api.com/](https://dns-api.com/) is my approach to that problem.

</comment></comment></comment><comment><USER9> If anybody from Cloudflare sees this - this is another good reason to add multiple API keys with permissions!

<comment><USER10> That's coming.

<comment><USER11> That comment inspires joy! I'm writing a tool that would jump at the chance of using limited access API keys than having the whole kingdom in my hand!

</comment></comment></comment><comment><USER12> Cool tool! But why would I use this over dnscontrol, Terraform or OctoDNS?

<comment><USER4> text/dns is a standard way to move DNS zones around - this means you can export this to a file, and possibly import it elsewhere, or just archive it as a point in time backup

</comment></comment><comment><USER13> This is REALLY cool! I'll be using this a lot!</comment>


You are your biggest failure - <AUTHOR> https://medium.com/devops-dudes/you-are-your-biggest-failure-48f3f389e97d <comment><USER2> And to quote some of Despair.com's all-time best Demotivators: The only recurring factor in all of your failed relationships is you. It could just be that the purpose of your life is to serve as a warning to others.

<comment><AUTHOR> hahahaha, that's beautiful.</comment></comment>


EMC's Atmos shutdown shows why cloud lock-in is still scary - <AUTHOR> http://arstechnica.com/business/news/2010/07/emcs-atmos-shutdown-shows-why-cloud-lock-in-is-still-scary.ars

<comment><USER2> Room for a startup here: guaranteeing/supporting cloud APIs when vendors fail. Or providing a portable/pluggable API for deploying on any cloud service, so you can quickly recover from vendor failure.</comment>