Seattle to deploy Gigabit fiber network - <AUTHOR> http://seattle.gov/mayor/SeaFi/gigabit.htm <comment><USER2> it is just getting better and better to live here in Seattle. Legalization of weed, same-sex marriage, and now high-speed internet

<comment><USER3> Fix that whole rain thing and I'll be there tomorrow.

<comment><USER4> Yep. I have an internship there this summer, and I'll be moving from Calgary, which gets the most hours of sunlight of any city in Canada. Hope the change won't be too jarring/depressing... it was overcast every day when I was there for interviews.

<comment><AUTHOR> Summers are _why_ you live in Seattle. 80°F, sunny, and beautiful every day (after July 5th)! We get about 16 hours of sunlight on the summer solstice.

There are actually cases of people getting SAD from the over abundance of sunlight in the summer ([http://cliffmass.blogspot.com/2012/10/depression- from-too-mu...](http://cliffmass.blogspot.com/2012/10/depression-from-too- much-sun.html?m=1))

<comment><USER5> Moving from seattle to the bay area you basically get that for about 8/9 months on end.

</comment></comment></comment></comment></comment><comment><USER6> Hooray! Now I have one less thing to lose by leaving Kansas City!

RE: <http://news.ycombinator.com/item?id=4917132> (from today)

<comment><USER7> Just make sure you move to Actual Seattle and not the sprawling suburbs. As someone who has used PhoneFactor for a few years, thanks, congrats, and welcome to Seattle soon!

<comment><USER6> Thanks, good to hear it.

Alas, we'll probably land in the burbs for all the usual uninteresting reasons. But it won't hurt to have the right people seeing Gb internet across the lake.

<comment><USER7> Well if you must live in the suburbs (Microsoft has a private bus fleet that ferries people from the city out there), they at least have some FiOS out there. I've heard Frontier stopped deploying it, but that existing deployments are maintained.

</comment></comment></comment></comment><comment><USER8> The initial 12 neighborhoods include: Area 1: the University of Washington's West Campus District, Area 2: South Lake Union, Area 3: First Hill/Capitol Hill/Central Area, Area 4: the University of Washington's Metropolitan Tract in downtown Seattle, Area 5: the University of Washington's Family Housing at Sand Point, Area 6: Northgate, Area 7: Volunteer Park Area, Area 8: Beacon Hill and SODO Light Rail Station and Areas 9-12: Mount Baker, Columbia City, Othello, and Rainier Beach.

<comment><USER9> As someone from Seattle, even though I don't see my neighborhood on that list (Maple Leaf) -- I am extremely excited to see more and more infrastructural focus on SODO and Areas 9-12 getting some much needed improvement. The light rail running through that area has been a step in the right direction for everyone in those neighborhoods, and I'm excited to see that development continue.

</comment></comment><comment><USER10> Awesome news. Comcast's monopoly on broadband in certain neighborhoods has produced nothing but sub-par internet access. This should greatly improve things.

<comment><USER11> Yeah, Broadstripe and Centurylink are even worse.

</comment></comment><comment><USER12> So proud of Seattle on a personal and professional level, across multiple recent advancements.

<comment><USER13> Cool, which were they? Just wondering.

<comment><USER12> 1) Marriage equality 2) Decriminalization of small quantities pot 3) Amazon's recent innovations in the hardware space 4) MS's recent innovations in the hardware space 5) T-Mobile's finally getting the iPhone

Several others on a more personal, non HN related front. Mostly trivial and entertainment based.

</comment></comment></comment><comment><USER14> As thrilled as I am that we're doing this, overdue and hopefully done right in the public interest, being about _three blocks_ outside one of the initial service areas stings just a smidge.

</comment><comment><USER15> Note, Santa Clara has municipal fiber too[1] - It is only 'last mile' (e.g. you have to hook up to a real provider in a santa clara data center) and the per-hookup install costs are... substantial, but the ongoing costs, if I could get several customers on the same physical fiber (I mean, if I signed up a few people in a row on a street) could be competitive with the 100Mpbs down/20Mbps up half a kilobuck comcast cable service, and gigabit or even 10 gigabit (if you are willing to make the setup fees even more... substantial) are realistic.

I'm currently working on a project to light a warehouse in santa clara (and I'm moving prgmr.com, and my massive overcommit of bandwidth to santa clara so I'll have somewhere to get transit) If others are interested in a 'fiber to the condo' type setup, lemme know; as a hosting provider (mostly upload) buying symmetrical links, I'd be pretty happy to have some end-user (mostly download) customers. I'm also willing to show you what I know, if you are trying to do the same thing on your own. (I mostly am interested in the fiber 'cause it's cool, and 'cause it is the next step on the path to learning what I need to know to operate a datacenter... a very long term goal of mine. I don't expect to make much money on the fiber project, as selling 'enterprise connectivity' isn't really my kind of game.)

[1]<http://svpfiber.com>

</comment><comment><USER16> I've got a job interview tomorrow for a position in Seattle. I'm now even more motivated.

</comment><comment><USER17> I am seriously debating why I recently moved from Seattle to SF/Bay... I can't go a week without seeing or hearing something that just rubs it in.

<comment><USER18> I lived in Seattle for 7.5 years, moved to San Francisco September 2011.

My only regret is not doing so sooner.

Seattle is a wonderful town (and it really is a big town more than a city) full of wonderful, if slightly insular, people. It's beautiful, there's great food, you can hike and kayak if that's your thing.

If you're a developer that doesn't work for Microsoft or Amazon, though, the geek community is definitely lacking. There are plenty of professional nerds but much fewer people working on exciting side projects.

I found it much harder to meet people, nerds or civilians. It's the sort of place where people settle in, where people have grown up, where people aren't necessarily looking for new friends. All of which is fine, I just found it a bit off-putting.

Seattle doesn't really do urban density (granted, SF has plenty of room to grow, literally, here). Some of that is intentional, mostly it's just aggravating. It doesn't seem to want to be a city. Portland, which is smaller, manages to do many of the "city" things (like public transportation and urban planning) much better.

And, man. Don't forget the weather. Those months without the sun age you.

I loved my time and life in Seattle. SF feels more like home, even if I have to wait another year for Sonic.net to roll out fiber.

<comment><USER17> This neatly summarizes how I feel. Or how I think I feel. Or how I want to feel?

There's no getting over the fact that Seattle isn't Silicon Valley. But, it's become so clear that Seattle isn't as static as it used to be. So even though it's insular now (and always has been), I just have a gut feeling that Seattle will open up and blossom more. Can you imagine a Seattle with SV's good parts, and none of the bad parts? Or is that just inherently impossible because it is Seattle?

In between the legal weed, fast internet, social entrepreneurship community, and it now being the 'it' place to live and play, it's almost a tossup for me. If there were money in Seattle and the funding climate there not being so stingy, maybe I would've stayed.

</comment></comment></comment><comment><USER19> I'm moving to Seattle in January and was already planning to sign up with CondoInternet. Seeing as my to-be neighborhood is one of those they say this will be offered in, I'm now wondering when this will be rolled out. Awesome news though.

Edit: "Gigabit Squared will be aggressively building, with eyes towards beginning services in the Fall of 2013."

<comment><USER20> Just a friendly mention that if your would-be neighborhood is Belltown or SLU, you may want to investigate some other options (unless of course you already have, in which case please ignore me!). Belltown has become worse and worse for crime (unless Phoenix Jones happens by to save you from being mugged). SLU, while nice and pristine and new, is now very overpriced due to Amazon's recent relocation there. Both neighborhoods absolutely have their positives as well, but I wouldn't move to them just for CondoInternet. :)

<comment><USER7> [citation needed] re: Belltown crime.

SLU is a former industrial neighborhood now filled with Amazon offices and cookie-cutter apartments. Basically the positive there is that you're close to work, the neighborhood itself is severely lacking in culture.

<comment><USER21> Belltown is "dangerous" only for people who have never lived in a city with a _real_ dangerous neighborhood. I have never so much as felt even uncomfortable walking around Belltown alone at night. I can't say the same about most _downtowns_ of other cities I've been in, let alone sketchier neighborhoods.

Maybe I've just been desensitized, but I really feel like there is no cause for alarm in Belltown.

<comment><USER20> It's relative -- among Seattle hoods, I would (anecdotally and out of my ass, of course) say there is more violent crime there than in others. I'm also a fairly big guy and I've felt uncomfortable plenty of times there at night when the streets are semi-abandoned.

In the past year I've seen ambulances taking away normal citizens who've been beat down (twice) and I've had a stabbing perp run by me as he was chased by the cops. And this is with me almost never going to Belltown. I've never seen anything remotely like that while I lived in First or Capitol Hill (although I've definitely seen plenty of car break-ins).

</comment></comment></comment></comment></comment><comment><USER22> Our (government owned) telco is building out an island-wide Gigabit network here in Jersey which is great. Problem is that it is capped at 50GB/month usage, which defeats the purpose. Actually using the connection's full capacity for about 5-6 minutes a month will result in overage charges. I'm hoping Seattle has a more realistic monthly cap, if one exists.

Sign-up page with plan details here: [http://www.jtglobal.com/Jersey/Personal/JT-Fibre/Fibre- Tarif...](http://www.jtglobal.com/Jersey/Personal/JT-Fibre/Fibre- Tariffs/Tariff-details/)

</comment><comment><USER23> Oh hell yes. I live in the U District. I am basically first in line for this. Signed up for more info as it happens. Goodbye, Comcast.

</comment><comment><USER24> Hurrah! I was getting worried about something Google fiber esque taking painfully long to make it here.

</comment><comment><USER25> I live in SLU! Today is a happy day.

</comment><comment><USER26> Question: why would a private person (as opposed to a business) need a Gigabit internet access?

<comment><USER27> Why would you need a terabyte hard drive? Why would you need 8 GB of RAM? Why would you need a Core i7 processor capable of over 80,000 MIPS?

Step back and think about what you do with a computer or mobile device today. Most of what we do involves the Internet. We don't "need" Gigabit internet access any more than we "need" the things above, but when they're present, we're free to find innovative new ways to use them.

<comment><USER6> It's still a fair question though.

How many streams of retina-quality video do you need to watch (or feed) simultaneously?

</comment></comment></comment><comment><USER28> What is a "fiber transmitter"?

<comment><USER29> Any of a number of different wireless transmitters plugged into fiber.

There are laser transceivers for use in open air, but they don't work particularly well in rain or fog. So not great for Seattle.

[http://en.wikipedia.org/wiki/Free- space_optical_communicatio...](http://en.wikipedia.org/wiki/Free- space_optical_communication)

</comment></comment><comment><USER30> In all seriousness, what's the likelihood of bootstrapping something like this? Intuitively I'd say near zero, high upfront costs, low profit margins, slow ROI. For some reason though, my gut isn't convinced.

<comment><USER31> You're much better off figuring out a wireless solution. Building out and maintaining a network of underground cables in an established city just sounds like a nightmare.

<comment><USER30> I know what you mean, and there has been wireless successful wireless startups so there is a case for it. The big issue though is bandwidth. With ubiquitous wifi hardware (thus cheap), you might be able to push 100Mbps (rough guess, I'm not sure how multi-antenna systems work for the 300 limit, I would assume 1 antenna to a person's house though). Which would be great but you're not going to get it unless you're standing next to the base station. You have to go through thousands of feet of air and then share what's left with everyone else using that AP. How many people would share an AP? Assuming 4 to a tower, easily 100? During peak times of day, I doubt you could get WiFi to deliver speeds that rival current offerings and it may be difficult to even match them (my local WiFi provider just recently broke 15Mbps for their top business tier at a much higher price than local cable).

You also need to physically install and maintain antenna's on everyone's roof (how would this work at apartments?) and hope there's no buildings in line of sight to the tower. Both of which would be highly vulnerable to weather (you put lightning suppressors on those people's antennas and ran a grounding wire to the earth right?).

TL;DR: I don't think wifi is any less of a nightmare (purely hypothesis though, I don't have experience with either in public infrastructure) but we see it more simply because initial cost of deployment is less.

</comment></comment></comment><comment><USER32> Does anyone worry about increased microwave radiation due to all these beamed broadband Antennas all over?

</comment><comment><USER33> Hopefully the pricing will be competitive with Google Fiber, and not several times more.

</comment><comment><USER34> No love for West Seattle? :(</comment>


Where the Small-Town American Dream Lives On - <AUTHOR> https://www.newyorker.com/magazine/2017/11/13/where-the-small-town-american-dream-lives-on <comment><USER2> TL;DR anyone? I got half way through and lost interest.</comment>


Being acquired doesn't have to suck - <AUTHOR> http://theprogrammingbutler.com/blog/archives/2012/01/08/being-acquired-doesnt-have-to-suck/

<comment><USER2> This is a case of one small company acquiring another slightly smaller company. I think that is as important as anything in terms of the Ordered List employees being happy as Github employees. In many cases the acquirer is several orders of magnitude larger than the acquiree, and I think that is what leads to the "suck" associated with being acquired.

I worked at a company of 200 employees that was acquired by a company of 200,000 employees, and it was a bad enough experience that I promised myself I'd never work for a big company again, and that if I ever worked for a company that was acquired by a big company, I'd start a new job search immediately.

I think this is fairly standard practice, but I've only been through it once. When we were acquired, management came up a with a set of timelines and associated goals. 30 days, 90 days, 6 months, 1 year. None of the short term goals were that big of a deal. Log in to the new HR system. Do a sexual harassment training. It was the longer term "synergy targets" that were the killers. Tracking every minute of your day to a project. New project management techniques and new project managers. No more input from engineers on new features. It happens slowly enough that you don't just walk in one day and realize you're working at a different company; it's more insidious than that. I'll never put myself through it again.

<comment><USER3> I've been on both sides of this situation, and if my (arguably limited) history is any guide, people like "you" are the very ones the big companies WANT to leave. (I say "you" in quotes, because I'm that way too and I don't want to make it sound like I think that's a bad way to be; far from it.)

<comment><USER4> This is true enough based on my experience at EA. There is a pervasive culture oriented around adapting to management desires ("your job is to make your boss look good") and the status quo.

</comment></comment></comment><comment><USER5> It's pretty unusual to be acquired by another startup. It's generally the culture clash, hierarchy and bureaucracy that make acquisition suck for the acquiree. None of that happens when a startup acquires you.

<comment><USER6> I wouldn't even call Github a start-up anymore. They're passed that phase.

<comment><USER5> Couldn't disagree more. They're a successful startup, but definitely still a startup.

<comment><USER6> How do you figure? They've established a great business model, have over 50 employees, profitable, and are acquiring other companies. Everything needed to be labelled a success business IMO.

What else would they need to do in order to be pass the start-up mark?

<comment><USER5> A successful business doesn't mean they're not a startup anymore. Dropbox is hugely successful, but definitely still a startup and its infancy.

Github will remain a startup until they can make a dent in the big boys' bottom line, for example: Perforce.

Github is insanely successful amongst startups and hackers, but has yet to significantly penetrate the enterprise. Hopefully this will change (for us and for them) because their product is a gazillion times better than anything else out there.

</comment></comment></comment></comment></comment><comment><USER7> Great example of an acquisition that will work out - two startups motivated by the same type of goals and both, as far as I can work out, optimised for happiness, not optimised for profit.

</comment><comment><USER4> It's different when you're the boss.

<comment><USER8> Definitely, I told this from the viewpoint of one of the guys hired in the acquisition. Would love to hear more about the other viewpoint.

</comment></comment><comment><USER9> has github ever taken outside money?

<comment><USER10> No. [https://37signals.com/svn/posts/2486-bootstrapped- profitable...](https://37signals.com/svn/posts/2486-bootstrapped-profitable- proud-github)

<comment><USER9> i thought that was the case, and figured we would have heard of them raising a round since then.

<comment><USER8> We keep this page updated: <https://github.com/about>

VC Funding: $0.00</comment></comment></comment></comment>


Ask HN: How to become a successful startup employee? - <AUTHOR> I am recently moving to a startup (late stage, post series D) from a big company. Since I was not satisfied with building internal tools without much customer impact. I wondering what different knowledge and skills do I need to acquire in order to become a successful start employee?<p>PS: I am a new software engineer with about 1.5 year experience. The company I am about to join is also a portfolio of UC <comment><USER2> These are bits of knowledge from my personal experience in startups:

1\. Most of the stuff you write will not be used.

2\. Product owners/sales people will change their designs/expectations on a whim (get ready for it) and expect a quick turn around.

3\. Be prepared for a revolving door of employees signing on, fizzing out or being dropped one day without ceremony.

4\. Be prepared for work done to be valid when you committed it and for it to the wrong design when it finally got accepted into production.

5\. Be prepared for some of the senior programmers to make bad choices for the company even if common sense says otherwise.

6\. Be prepared for long hours if it is required.

Your mileage will vary but it is experience that you can add to a CV and you'll learn if you like it.

</comment><comment><USER3> Before looking into knowledge and skills, look into the definition of successful.

Do you mean rich? Happy? Wanted? Desired? Etcetera

<comment><AUTHOR> In my current position, I am not getting much impact at work, I am working on internal tools. I would hope to be more impactful at work, like developing stuff that customers think useful and they are willing to pay a lot! Certainly, I want to have a big exit, but at a post series D startup, my impact on exit/failure would not be that much.

<comment><USER4> Right now your internal stakeholders are your customers (the best kind of customers). I would say you have the chance to build great tools your customers want (ask them).

</comment></comment></comment><comment><USER5> \- Work 24/7.

\- Brown-nose the boss every chance you get.</comment>


Ask YC: Where to improve? - <AUTHOR>

www.tipgroups.com
starting to think its almost ready to promote (not that I actually got a clue how to do that).
ALL suggestions are welcome. (don't spare the rod) :) <comment><USER2> To start, nice idea! Congrats.

To start off, I am on a Mac with FireFox...

1\. Your sign-up screen and log-in screen have a very different look from the home page, and from each other (one is centered, one is to the left, one shows the table borders, the other dosen't) 2\. I am not sure I understand the need for a "Go Back" button on the sign-up screen. 3\. When you go to the login screen (or the signup or the About page) the Title of the page disappears. [It shows only the hyphen] 4\. Is there a reason why Google Stuff, Car Buying etc show up on the left hand side, and never change? Refreshing the page does not help, but the top "Groups" section starts. 5\. Is there a way to browse the groups without having to refresh the page (Much like Amazons recommendations... maybe?) 6\. When viewing a Tip, the Works! and Unique links don't look like links (or buttons) and only clicking on them tells you that there's something there...

P.S. I did not create an account, but I hope this gives you something to work with. Good luck!!!

<comment><AUTHOR> Thanks raju for the feedback. Regarding (1),(2) (3) yea I got to clean those areas off.

(4) yea there is a reason, but not a very good one. I'll figure out a way to arrange groups thats more intutive to for the user, perhaps simply by most tips in group. (5) I guess your refering back to the mainpage. Whats there right now is simply just a random group display. I'll rethink on that thought about the group browsing, I've tried to build the site on the principle of clean and minimalstic and avoid any flash or ajax whenever possible. (6)I noticed that too last night when I added those buttons, but I thought "well they look good in IE" no big deal,...aha but you've noticed it too so I guess they've got to go.

<comment><USER2> samson, I like your idea of a minimalistic design. If you would rather not have any fancy ajax or flash, then may I propose for an easy way to search for tags and tips etc...

My apologies if I sounded too critical, but I certainly hope the input helped. Again, Good Luck.</comment></comment></comment>


SCons: A Software Construction Tool - <AUTHOR> https://scons.org/ <comment><USER2> The maintainers of SCons have long argued perceived performance and scalability issues do not exist ([https://github.com/scons/scons/wiki/WhySconsIsNotSlow](https://github.com/scons/scons/wiki/WhySconsIsNotSlow)).

I've long been really excited about SCons but eventually decided to move away because it became unbearably sluggish for a large-ish codebase with >180K lines of C++ code split into many files. Another issue are cross-platform builds. SCons breaks every time there is a new version of Visual Studio, and it takes many months until an updated version restores compatibility.

<comment><USER3> That blog post is an impressive logical leap on the authors part.

I realise that the post is not from recently but the benchmarks are on seriously outdated software and hardwaee, those specs are over a decade old at this stage. His conclusions are also misleading, all of his graphs show that make is 2-10x faster than scons, and that make scales better than scons.he seems hell bent on proving there's no quadratic complexity, despite there being an order of magnitude of a difference!

On the other hand, I don't think it's reasonable to assume every build system will immediately support every compiler/IDE. At the end of the day, scons is an open source project and if that's the only issue stopping you using it, I'm sure they'd be happy to accept patches providing support rather than wait months.

<comment><USER4> Scons is almost 20 years old at this point. There are projects like waf that tried to fix it but ended up incompatible (and faster and more usable).

Scons has great ideas, but something either about the implementation or about reality fails to deliver.

<comment><USER3> As is cmake. Make is about to hit a mid life crisis, other projects like Ninja are faster and more lightweight, projects like WAF/Premake use a scripting language instead of a DSL, others liek FASTbuild claim to support distrobuted builds. At a certain point, sofradre has to be accepted for what it is, not what it claims to be.

</comment></comment></comment></comment><comment><USER5> One of my favorite SCons features is that it determines the necessary build operations from file hashes rather than timestamps. Working on a project with a long link step, it was wonderful to be able to rephrase comments, rename local variables, or tidy code formatting and skip the link step, since scons saw the object files had the same hash.

A few times, the skipped link step revealed to me that the code change I had just made had no effect on the compiler output, usually because the compiler's optimizer was already doing the same thing.

Likewise, hash-based compilation made git operations much smoother, since things like rebasing or jumping back and forth between branches can update timestamps without affecting content.

I know it's possible to hack similar functionality into some other build systems by adding a layer of intermediate hash file targets everywhere. But I'm a bit surprised the idea hasn't seen broader adoption... Having build artifacts indexed by hash seems like it'd be a requirement for any system that eventually wants to support large, distributed builds.

<comment><USER6> Buck and Bazel both work using hashes, if you are looking for a more modern build system with this feature.

</comment></comment><comment><USER7> Relevant section of Debian upstream guide: [https://wiki.debian.org/UpstreamGuide#SCons](https://wiki.debian.org/UpstreamGuide#SCons)

As a Linux distribution maintainer, I second that. There are not that many packages that still use SCons, but ones that do often require boilerplate and/or patches to honor standard environment variables like CC, CFLAGS, LDFLAGS. Cross-compiling a SCons package is a nightmare.

If you like that SCons uses Python, I'd suggest to try Meson. It does everything right and exposes a subset of Python API: [https://mesonbuild.com](https://mesonbuild.com)

<comment><USER8> How easy is it to extend Meson for languages that it doesn't ship support for by default? That always seemed to be one of the strong points of SCons/something many modern build systems don't support so well.

<comment><USER9> Meson developers are highly opinionated regarding what "should" and "should not" be supported, and aggressively block anything that might be considered, or even lead to "badness". Sometimes this is justified, but it makes one's job very difficult if one disagrees with them. For example, they insist on completely integrating Rust into the build framework, but also (apparently) don't have the manpower to actually implement that, so, coupled with the fact that extending the language is impossible from within the language, practical Rust (i.e. any dependencies, any Cargo use at all) is difficult to impossible.

</comment></comment></comment><comment><USER10> I'm a build engineer and SCons is one of the gems in my tool belt. Where it truly shines is as a framework for building build systems. At its core, it's just a library for building and executing a DAG. What most SCons users work with is the standard-library of rules built on top of the core API, that makes it immediately usable as a "high-level" build system like Meson or Cmake. In my experience, it's unparalleled when you have to model an entirely custom build-flow in a clean way. I've used it to model build-flows for custom tool- chains that would have been a nightmare to reason about if they were written in GNU Make and outright impossible with a meta-build system.

The only other tools I've found to rival this flexibility are Gradle (see the Software Domain Modeling chapter of its documentation) and Shake (though having to write rules in Haskell makes it a hard pill to swallow).

</comment><comment><USER11> MongoDB uses Scons to build their product, or did when I was there. MongoDB is coded in respectable modern C++, with an admixture of Java bad habits and a history of Google Style pessimization.

Among the most used articles on MDB's internal wiki is "Scons: It's Not That Slow!"

In fact it is really quite, quite slow, but a universally popular add-on (not officially "supported" when I was there), is a Ninja build scheduler that is blindingly quick.

So, the slowness only manifests when you need to recalculate the dependencies, which doesn't appear in the typical edit-build-test cycle. With Ninja, combined with Ccache and a distributed build tool (whose name escapes me ATM), coding at Mongo was not bad.

<comment><USER12> This doesn't exactly shine well on mongo's development practices. Why go through all of this trouble when you could use something that works well out of the box like CMake? Maybe they like wasting money.

<comment><USER11> The answer is the same as everywhere: history. Not just the product build, but continuous integration, test suites (test themselves are largely JS, of course) and release management, are all tied together with Scons and lots of custom Python.

It would just be a huge job migrating to something else, for little better possible result than "it still works". And it does already work.

</comment></comment></comment><comment><USER13> I really loved SCons and used it for most of my personal projects, but beyond a certain project size it really starts to show performance issues. At work we used to use SCons for a major code base and even running it without any source changes took a good 30s.

We eventually switched to Blueprint.

<comment><USER14> For better or worse, a name like "Blueprint" is virtually useless without a link. Even googling is worthless, since it collides with...everything.

<comment><USER15> Duckduckgo for [blueprint build system] returns [https://github.com/google/blueprint](https://github.com/google/blueprint) as the first hit, so I think it's that.

Edit: Google, for me, _doesn 't_ return that on the first page, but the first result is [https://opensource.google.com/projects/blueprint](https://opensource.google.com/projects/blueprint) which links to it.

<comment><USER14> Interesting. DDG for "blueprint build tool" doesn't get anything relevant, but "blueprint build _system_ " works fine. Sigh.

</comment></comment></comment></comment><comment><USER16> I really like the idea of SCons. Writing Python is strictly better than using the CMake language or m4. But, quoting one of my colleges: "SCons spends 5min to figure out nothing needs to be done."

<comment><USER17> I have exactly the opposite experience: I do not want to write a program to compile my program.

Having used both scons and waf, and also having used make, cmake and cargo, I would take any of the last three over scons or waf in a heartbeat. I think cargo is far and away the nicest to use because there is very little to actually _do_ to build your program. Using waf or scons was always an exercise of 'I added a header file, so now I need to figure out the scons/waf API in order to tell it what to do with it'.

</comment></comment><comment><USER18> I worked long for years with scons and it is the worst and most terrible tool I've ever seen and I would only recommend it to my worst enemies.

At the beginning might look good, with some "apparently" nice principles, but beyond a certain point it will start growing in volume and complexity, like a cancer grows, until its technical debt devoures whole teams of people and impacts everyone performance and people starts quitting. Adding more people to the build responsibilities doesn't help because it's impossible to maintain it after more than 2 people have been involved in a large scons projects.

Together with the few fancy ideas that it has, there are other design principles which do not scale from the human standpoint. It's nature of python code for everything and the way builders and scanners are created, makes impossible to follow the code flow and next to impossible to find certain bugs unless the people who built the mess was a god of communication and an ascet in coding discipline. Every single aspect from that build, as soon as more than one target is compiled, will start growing unendlessly, moving the focus from the project's business code to build environment's code. It's design principles and monolitic structures together with its terrible underlaying implementation of that horrible API make impossible to work in a team with scons and the larger it gets the more it leads to giant unmaintaible build environments which end up crashing randomly and no one can explain why or how to make anything by themselves. And at some point the amount of features pythin users end up embeddign there end up creating so much technical debt that it makes feel impossible to justify the migration to a different build system; whereas in reality other build environments might solve almost all the non problems easier by skipping features no one wanted.

You might think I am exagerating because someone showed to you a scons hello world, but then I will reply you that I've witnessed 3 different teams at a large corporation escalating their scons based build environments to upper management because it became an interminable source of conflicts and a black hole of company's resources. The best case was when a full dedicated person in a team of 10 people does all the build related work, and when I say all related work, I trilly mean to write even the most basic aspects of every single build, leaving the rest of the team in the ignorance and uncappable of extending the build by themselves, or at best copy-pasting a snippet and praying that it works.

Seriously, this tool is wrong for teams of all sizes bigger than 2 people. It favors an unmaintainable mess only comparable with the worst spaghetti-worm- hole codebases.

</comment><comment><USER19> IMHO SCons had some nice ideas but it falls down in practice in non-trivial projects. Wrestling with eels is easier than doing cross-platform builds in SCons. And while I do love Python, I think using a fully-fledged language is a mistake.

I think a declarative DSL with scripting hooks behind it is a better model. Having used many, many build systems over the years, I've never found one I thought truly got things right (though several came close).

I actually think the ideas behind bjam ought to be revisited. It had a declarative style, with scripting to support it. The implementation was awful sadly; the tiniest mistake or typo would send the parser into a tailspin and the documentation was truly confusing. Any errors were presented to the user at the scripting level, which was even more confusing. But the idea of having toolchains defined separately, and having traits and features was brilliant. There's a lot to learn from there.

</comment><comment><USER20> I love new technology, but when it comes to build systems I am a stone cold conservative.

Maybe it's just me, but I prefer even the ugliest make files to scons and Gradle and what not. Because I have been burned too many times by "improvements" in the build system making my code so compiling.

Am I the only one?

</comment><comment><USER21> I have used it in a large codebase, and it was terrible.

Everybody must write python code to build their C++ files in a project. What could go wrong?

</comment><comment><USER6> In my experience SCons has the right design, but the implementation is incredibly slow. Buck and Bazel are superior options.

<comment><USER22> This is why CMake is spectacular (for all of its many, many, many warts): it spits out good, fast configurations for a large number of build runners; and they all tend to work. CMake + Ninja is spectacular if you want to spend less time compiling, but maybe not ideal if you are not familiar with CMake idiosyncrasies and want to configure it for something. I usually find that I can add a pkgconfig-based dependency to a CMake project without much fuss, but anything much more complicated than that I typically do not enjoy.

</comment></comment><comment><USER23> I'm the current SCons project Co-Manager. Nice to see spirited conversation.

A couple data points on performance. A current snapshot of MongoDB's repo will do a null incremental build in 53 seconds on my i7-2600 with non-ssd drive. (Null incremental build = fully built tree. no need to rebuild anything).

In the last few releases we knocked that down from about 63 seconds.

Currently we're working on a number of performance related items and hope to make some strides here.

Note the article sited is fairly old: [https://github.com/scons/scons/wiki/WhySconsIsNotSlow](https://github.com/scons/scons/wiki/WhySconsIsNotSlow) (from before 2.4).

That said there are (currently) faster build systems. SCons tends to be most valuable when the build is complicated.

So as you can see.. the current maintainers don't argue that there are no performance issues with SCons. But we're working on them.

</comment><comment><USER24> Nooooooooooo, please!

Try Meson instead:

[https://mesonbuild.com/](https://mesonbuild.com/)

</comment><comment><USER25> Bleeeech. CASE design? No thanks.

ihmo CASE (really automated policy configuration) is what people are now calling "AI". It's really just a computer augmenting and assisting a human's decision making.

</comment><comment><USER26> The main comment here seems to be sluggish performance.

Is it some sort O(n^2) rule handler deep inside the builder? Or is it just "python-slow" ? :/

Can someone give an example of a big open source project which is too slow to build?

<comment><USER27> I think there's a lot of exaggeration in the comments about SCONS being slow. We use it for a 300K LOC codebase, and while it is not as fast as cmake, it's still perfectly serviceable. To be honest, for me the flexibility to do non- trivial customization of the build directly using Python code is well worth the somewhat slower performance. I always wonder what kind of build process people use if the overhead of the build system outweighs the compile time itself.

<comment><USER11> No, Scons really is dog-slow. How slow can be discovered by using the Ninja back-end plugin, with Ccache. Then it can be quite pleasant.

Of course if you only ever build from scratch, on one core, compile time will dominate, and you will wonder what the fuss is about.

</comment></comment></comment><comment><USER28> A thread from 2008: [https://news.ycombinator.com/item?id=294887](https://news.ycombinator.com/item?id=294887)

</comment><comment><USER29> I'm starting to think build systems should be built like LLVM with separate front-ends and back-ends.

Imagine if CMake were separated into a front-end and back-end. You could use a super nice Scons-esque pythonic front-end instead of CMake's crappy proprietary language and still have all the benefits of CMake!

<comment><USER30> That's basically the way things already are. Current backends are things like GNU Make, Ninja, Xcode and Visual Studio. CMake _is_ the frontend.

<comment><USER29> Well what I guess I mean is, I wish CMake were an API. That way I could use the language of my choice to drive CMake instead of using its quirky/esoteric language.

Ninja is indeed a build system backend but it's too low level. I want a intermediate to high level backend that abstracts common things I want to do.

<comment><USER31> But why do you think the API would look any nicer?

<comment><USER29> Well the API would have bindings for common languages

</comment></comment></comment></comment></comment><comment><USER32> The best thing about SCons is the build cache. I wish more build tools had that.

<comment><USER33> It's a pretty old idea, going back to "derived objects" in ClearCase aka wink- ins.

If you think about it though, it's not hard to cons up a tool that files objects on disk by normalizing all the inputs to a compile step, and retrieving that object if it exists. Here's one but there's others.

[https://www.commandlinux.com/man- page/man1/ccache.1.html](https://www.commandlinux.com/man- page/man1/ccache.1.html)

<comment><USER34> It might be ready for a revival. Bazel is halfway there.

[http://beza1e1.tuxen.de/version_control_and_build_systems.ht...](http://beza1e1.tuxen.de/version_control_and_build_systems.html)

</comment></comment></comment><comment><USER35> Can somebody summarize how ot compares to e.g. conan.io? I get the python aproach but yet another build tool?

<comment><USER36> > yet another build tool?

Scons is 19 years old...</comment></comment>


What I Do as a DevOps Consultant - <AUTHOR> https://ilhicas.com/2019/08/11/What-you-as-a-Devops.html <comment><USER2> In practice, and talking from my experience, unless you're one of the lucky few this is what it really means to do DevOps in 2019:

\- Forget what the books said, theory, semantics and idealism. You are a DevOps Engineer, working in a platform specific team.

\- You deal with Jenkins or similar, and consult other teams or developers to write scripts for it, or worse, do the work for them since they're too busy doing actual programming.

\- Contrary to what they say, other than tiny scripts you are not programming much anymore, unless you consider configuration management to be programming.

\- You are not allowed to come up with your own abstractions. Proposals to develop anything are automatically declined by your Product Owner, who simply points you to whatever tool with a fancy logo he could find listed in the Cloud Native Computing Foundation.

\- You pride yourself for being an engineer, but decisions end up being only made in terms of getting free open source labor and ease up hiring, so you end up doing what everyone else is doing.

\- Half of your team co-workers are perfectly fine dealing with churn, software updates and other sort of manual, classic sysadmin tasks.

\- You are repeatedly being paged at night for problems that your fellow developers won't feel responsible for. You hear buzzwords and talks about this SRE thing or "you built it, you run it", but it never seems to materialise due to politics.

\- You are getting a feel that cloud providers are not really making things easier nor cheaper.

It used to be a lot of fun back in the day, and a great chance to get paid to solve interesting problems related to system and infrastructure engineering instead of the boring CRUD work that plagued the last decades, but seeing the "App Store" that this turned into, if you are a creative individual with a software engineering background and you're considering a career in DevOps, my advice is to run away while you can.

<comment><USER3> My company calls what I do DevOps but I write full stack webapps to support the network operations team. I prefer to call it OpsDev, but noone seems to agree with me.

<comment><USER4> DevOps has nothing to do with writing code or doing ops. Think of DevOps as a synonym for Agile and Lean, but not specific to software development.

</comment></comment></comment><comment><USER5> "DevOps" used to be a methodology where a Dev and an Ops share a same goal of delivering value into production, at least, that's in the book I have read.

A sort of extension of the Lean System where workers from different areas share a common goal of delivering value to the final customer (in production), the same card may require a backend dev, frontend dev, and an ops to share the goal to take this card from idea to production, and then monitoring how it behaves in production.

For people who have not read the same books, "DevOps" mean things like "applying dev method in the operation field" ie. with ansible and the likes, coding the infra. After all, that's what that word seems to mean at first glance.

This reminds me of the term full-stack, some people consider it's just about being good at both frontend and backend, in my opinion a good full-stack is also a good networking engineer as well as good at customer acquisition.

For best ROI:

\- integration must be automated and continuous

\- delivery must be automated and continuous

\- tech debt includes untested code and being late in dependency versions

\- the above should be treated as impediments

The purpose of "DevOps" being to deliver faster from idea to production, it does necessarily include a toolchain of CI/CD/IaaS & monitoring tools. From this "DevOps toolchain", taylorists opened positions for developers that can maintain it around a software, they called that position "DevOps", which explains how we got there on having different meanings for the same word.

I highly recommend "Continuous Delivery & DevOps: QuickStart" by Paul Swartout for a first quick read on the matter.

<comment><USER6> _> But I don't think you'd be doing "DevOps" all by yourself, unless you are what I call a full-stack, good at: communication, frontend, backend, and networking._

This is pretty much how I sum up what you'd have to be to be "a devops engineer": an actually-full-stack developer with a strong facility for communication and for process.

Such folks are hard to find. I only know a few, out of the dozens of folks I've worked with.

<comment><USER7> _you 'd have to be to be "a devops engineer": an actually-full-stack developer_

Completely false. A full-stack developer applies JavaScript frameworks to create websites. A DevOps engineer applies development methods to infrastructure i.e. infrastructure-as-code. Totally different both skillset and mindset.

<comment><USER8> I think that's the point that post and the parent comment are making. A "Real- full-stack" (actually-full-stack) would actually include communication + networking.

I think it's more of a criticism on the term "full-stack" for someone who works on a backend and touches front-end every now and then.

I think everyone is in agreement that what we call "dev0ps" devs and "full- stack" devs have completely different skill sets and mindsets but if I had to attribute "full-stack" to either of these it would be a "dev-ops" dev. (theoretically, real life is messy)

<comment><USER9> That's quite arbitrary and you likely defined it as this to fit your current business or occupation. Or even just your current main competencies.

I could say a real-full-stack should actually include EE, chip design, compiler design, kernel hacking, model checking, machine learning, virtual reality, power supply design, and 20 years of experience in Rust.

Or anything, really.

<comment><USER10> I think you're missing the point a little by adding hardware and chucking in the 20 years experience with rust at the end. But, as long as you stay in software land, yes. I'm happy with real-full-stack description for experienced DevOps people who can say - I'm not a master of JS, but this caching strategy needs reorganisation on multiple levels, I can handle that. Or I'm not a master of kernel, but if we have this specific crash repeating, I'm happy to dig into it and create a patch/workaround. Whether you work with machine learning / VR / other environment changes the specific tech, not the idea.

</comment></comment></comment></comment></comment></comment><comment><USER11> Great DevOps practitioners are rarer than 10x engineers. It's the combination of:

* Systems knowledge through the lens of Conway's Law: what does an ideal even look like in terms of organizational efficiency

* Leadership to get disparate teams in an organization to cooperate instead of compete

* Technical competency to help disparate teams adopt the principles, because telling people on the fence to "go Google it" is a plan for failure

People who get bogged down in CI/CD/IaC/containerization miss the forest for the trees and it's why most organizations never see any value out of their DevOps initiatives. If you don't know what to automate then WIP increases your costs. If you don't have leadership on board then you can't reorganize teams to prevent "cycles" and re-work inside the "factory". If you don't have technical competency then you have people re-inventing the wheel, poorly.

You need all three.

<comment><USER12> At my day job I have a "devops" guy who is all-in on "devops". By which I mean he wants everything run through a CI/CD workflow, committed into change control, with passing unit tests, and tasks passing through a Jenkins pipeline.

Did I mention we are information security consultants and work in neither dev nor ops? Yeah he wants our powerpoint slides checked into change control. I'm not joking.

<comment><USER13> I put docs in vcs, it is convenient. But, binary formats are less useful.

</comment></comment></comment><comment><USER6> This article makes me...itchy. For background, I've been running SRE/infrastructure/"devops" teams for the last couple years, hung out my shingle as an independent consultant before that, and worked at a fairly large company as what we'd have called an SRE if the term had been a thing yet. And to me, feels like a lot of missing forests for trees.

Elsewhere in the thread, 'somepig notes that this sounds like what a sysadmin does. I replied there because, just as you shouldn't call yourself a programmer[0], calling yourself a sysadmin is probably similarly mindset- and career-limiting, but I kind of have a bigger beef with calling this "consulting" than I do "devops". Of course this stuff is "devops", but--"properly" applied (and I scare-quote the word because you can call damned near anything "devops", up to and including "the development team hurls a tarball over the wall at some sysadmins in the basement and flees at top speed")--it's not consulting. It's a list of hands-on work. There's only a cursory nod to the _most important part_ of any devops-facilitating role (whether it's called an SRE, an "infrastructure engineer", a "devops engineer", whatever): alignment of technical initiatives with business needs.

I don't mean to be harsh in saying this, but if you're spending most of your time in the code mines grinding at this or that, you may not be a great "devops consultant". You might be a great infrastructure developer or SRE. But in my neck of the woods at least, clients hired me to make sure they were doing the right thing and to make sure that their employees were adequately prepared for the workflows they wanted to implement, not to do last-mile CI/CD computer touchery. (Which I'd do as well, of course, when time allows--but there's more value in being a multiplier than an adder, and at the rates I charged I'd _better_ be the biggest multiplier I could.)

[0] - [https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

<comment><USER14> Though there's also the other side of the coin, people picking up a tech because they read about it, which ends up in the core business, without good rationale for the tech other than "i found it on the internet".

This blog post really reflected my background, with most of the tech used being the same. However, most of the experience is by cleaning stuff up. I see stuff being used too many times that are not performant, effective or incorrectly configured due to people not taking care of said tech. Especially in the Javascript business. It is cleaning up tech debt that might not make cash in the short term, but many companies have it as a burden in one way of another and someone willingly to clean that mess up is very valueable, imho.

<comment><USER6> A nontrivial part of my career has been smacking people with sticks when they do this, so yeah, I agree with you here. I don't view that as the other side of any coin, however--rather, it's the same thing, where there is a lack of a holistic understanding of what goes into any given piece of technology and what the (inescapable) knock-on effects of it are.

Cleaning up the results is sometimes due to a soberly considered "we have to move fast _now_ to not die" decision, but often is just because it looked good in a five-minute demo.

</comment></comment></comment><comment><USER15> I founded a DevOps consultancy (Contino.io) and have been involved in hundreds of DevOps engagements.

I've always been comfortable with the idea of DevOps as a role. If you work on Terraform, CI/CD, container platforms etc and have knowledge of both Dev and Ops practices and engineering mindset then it seems like a fine label.

We really took a bet in the early days that DevOps as a discipline as well as an operating model and culture would emerge. We are now approaching 400 people so we are happy with how it's playing out. I think it's very early days too.

</comment><comment><USER16> _" I'm not your...Sysadmin or other common role"_

What's described is very much like what a sysadmin was in the 90's, prior to more specialized roles.

<comment><AUTHOR> Dont read diagonally please. I never said i dont end up doing sysadmin/ops work

<comment><AUTHOR> But yes. The devops movement is actually here to bring the 90s back when we didnt specialize to an extent where silos are created and the gaps between teams get in the way

<comment><USER17> it never left. you've just been blissfully unaware of it, and now that you've discovered it, you think it is new for everyone.

everything in this article is what I do as a sysadmin.

part of being a sysadmin is practicing devops. not the other way around

<comment><USER6> Like it or not, vernacular changes. Today, in most contexts, "sysadmin" suggests (at worst) a Windows pusher armed with a mouse and (at best) a heads- down computer toucher (which is also what this "devops consultant" document seems to outline, really, so you're not wrong!).

You're totally right in that sysadmins can certainly practice (part of) devops, but anywhere I've ever gone it's less the rule then the exception and "sysadmin" is a career-limiting classification, akin to calling oneself a programmer [0]. Ends, not means, etc.

[0] - [https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

<comment><USER17> certainly won't disagree that it can be limiting to folks of some perspectives, but as someone who publicly has applied the sysadmin label for the duration of their career (starting in the early 00's), I've yet to see a downside.

I've been obscenely compensated for working on interesting projects for much of my career. then again, part of it may be due to the confidence that comes with focusing on my work instead of fluffing my title.

<comment><USER6> You also, candidly, may be experienced enough and have enough time-served to get away with it. ;) There's definitely an effect--I kinda want to call it a thermocline?--above which your actual achievements can speak for themselves, particularly if you've built a solid network.

Today, if I had a notion to, I could probably call myself a "sysadmin" and not have trouble finding well-compensated work. But when I was freelancing, as well as when I was earlier in my career, I can tell you a lot of doors would have slammed _right_ shut had I used the term regardless of my capacity. I do not particularly love the term "devops", but at this point its umbrella at least encompasses what we (like, you and I, not the general we) think about when we're doing this stuff, and it has a certain amount of loaned--or stolen --credibility.

As I said in a top-level comment, I'm more twitchy at this description of being a _consultant_ than I am at the _devops_ part.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I wish the idea that DevOps was a role or activity would die.

<comment><USER6> Upon joining my current company, I renamed the team that I lead "infrastructure" for exactly this reason. That team was not a "devops" team except insofar as things were getting hucked over the wall and they necessitated some dev out of the ops folks.

My role here is arguably a more integrated one where we're working towards a devops-flavored _culture_ , and the infrastructure team here is part of it: "we maintain the roads and set up the water mains and keep the power lines from falling down, but hooking up your house to power and electric and making sure it doesn't catch on fire--that's _your_ responsibility."

</comment></comment><comment><USER19> The times I've been stuck doing "DevOps", I mostly rue the loss of the quality assurance culture (values) we once had.

Best I can tell, like Agile Methodology, Skype, and open offices, "DevOps" is edgy jargon the financial people came up with to screw us knowledge workers.

I imagine myself trailing a parade, wearing oversized shoes, a rainbow fro, painted on happy face, and red nose, pushing a wheel barrow, scooping up the messes left by horses and elephants.

Some orgs seem to have figured out how to turn lemons into lemonade. That dude from Gilt has a "Test Into Prod" thesis that seems to square the circle. (I can't say from personal experience, but someday hope to work somewhere willing to try it.)

</comment><comment><USER20> Lack of monitoring is scary.

> knowing a triple A (Authorization, Authentication and Access Management) > solution

AAA is Authentication, Authorization and Accounting.

edit: formatting

</comment><comment><USER21> One of the coolest things about devops is that nobody seems to agree on what it is, and articles like this one elicit many different opinions. So here's mine: devops is infrastructure as code, where code in this context is something that is checked in to an scm and is really more like configuration. It is not software development, which is more likely done by software developers. I'm still not sure where the 'dev' part came from.

</comment><comment><USER22> DevOps in my experience often stems from a breakdown of communication/trust between management and developers. Software production and deployment complexity has outpaced the deliverable(s). Traditional IT system admins struggle to keep up with deployments that are way beyond ftp/sync tools. Simultaneously developers are creating microservices each with independent multi-step build processes.

The complexity and problem solving of the job is not automating some widget or service. That is very easy and not a challenge to someone with a deep programming background. The challenge is knowing what to build to a) enable developer productivity and flexibility to b) increase development speed to c) provide products/services the business side can iterate on quickly while d) not completely destroying the infrastructure and lessons learned that already exist and e) providing training and leadership to system admins and developers not used to these processes.

</comment><comment><USER23> I founded and run a DevOps consultancy (Elasticbyte.net) and fundamentally the biggest difference between daily DevOps work and typical software engineering is tooling. DevOps is all about the tooling, knowing which ones to use, and organizing and memorizing lots of details.

The majority of my time is either wrangling AWS, GCP or in tools such as Packer, Terraform, Ansible, Docker, Kubernetes, and writing bash scripts. I prefer DevOps now to writing traditional code as it is less down in the trenches nitty gritty code/math/logic and more higher level architecture and applying changes. I think it lends itself toward a slightly different personality type than a software developer.

</comment><comment><USER24> Just recently I wrote a brief post about how the title of 'DevOps Engineer' (and similar) were irking me, especially when looking for new roles / opportunities. DevOps isn't a job title - it's a culture and making click-bate / hipster job titles isn't helping recruiters or business gain the value or plug the gaps they need:

[https://smcleod.net/tech/2019/08/08/camels-and- unicorns.html](https://smcleod.net/tech/2019/08/08/camels-and-unicorns.html)

</comment><comment><USER25> I'm a freelance DevOps consultant working in Germany

I consider my duty as 50% as consultant regarding DevOps culture and agile culture and to 50% "building pipelines and all that automation stuff" This shows quite clearly how DevOps as a term is used in Germany. Either the fusion of responsibility of Dev and Ops is meant or just someone who does this modern cloudy stuff One thing I really like in the DevOps space is that I never had a problem with the tech stack at a customer. Some want more cloud, some more pipelines, some more infrastructure, still I could do every project and never had problems with my qualification. So when I have calls from recruite I kinda skip the tech stuff, since it won't be the issue anyway. I'm more intersted in how much the company really does DevOps and Agile. I just recently declined a job opportunity bc the company wanted to buy this modern DevOps stuff but actually couldn't risk an actual change.

The customer I currently working for is a mess. It's a middle sized company who has to finish 3 projects at the same time and do neither the "new world" nor the "old world" They overthrown a lot of the old world rules and took a lot of power from the project managers. But what they are doing now is taking random parts of the new world and implement it in a broken way and say "we are modern!" Like this they are doing neither of it and they end up with basically just chaos. Companies often want a change without having a change. And for me it's kinda annoying to run against corporate walls, when I was hired (as an expensive external!) to solve those problems but then getting ignored. So they throw more people at the problem and just churn them. As you guys already know, what 1 guy in IT can do within 1 day, 2 guys can do it in 2 days.

P.S.: I'm planning to relocate from germany to NY. If someone needs a DevOps, give me a shoutout to: email@example.com Also open for non-work contacts. Don't want to be alone in NY

<comment><USER26> I've been hopping from one DevOps role to another for the past 4-5 years and I've been meaning to get into freelancing recently.

However, in my experience, I find that projects are incredibly hard to acquire, especially if it's your first freelance gig.

Do you happen to have any advice for me on how to get into DevOps freelancing, particularly how to acquire projects?

Thanks

</comment></comment><comment><USER27> Remember that scene in Back to the Future 2 at the Enchantment Under the Sea dance when 1985 Marty had to somehow neutralize Biff's thugs from the catwalk before they jumped 1955 Johnny-B-Goode-playing Marty, all while trying to avoid seeing him or else the universe would explode in a space-time paradox?

That's DevOps.

</comment><comment><USER28> I particularly agree with the scripting nature of the role. I've played a major part at my company using many of the tools you mention to set up IaC/CICD/etc. However, day-to-day I'm in script land, which is where I want to be really.

</comment><comment><USER29> That is in alignment with the work I have done as a "devops" person. I have also worked as doing primarily backend development.

The single-most useful skill I have used is problem solving in an unknown context. Knowledge of architecture patterns help a lot in both cases. There have been times when I have had to read code just to figure things out.

There was a technical interview for a devops role I did recently. Whomever designed it was brilliant: a deceptively simple task (install an obscure blogging platform and get it running) with many hidden landmines and gotchas, compressed into 45 mins. Just another day at work.

</comment><comment><USER30> devops in my department means developers they push into a full time support role to fill out release paperwork, oversee manual regression tests, and fix production failures.

</comment><comment> brew-hacker Personally - I would consider some of the best DevOps engineers as the best generalist engineers around.

DevOps engineers are thought as limited to CI/CD or infrastructure management. I would 100% consider them to be able to pick up development and understand the full stack (including networking, database management, etc.).

Kudos to you and others that expand "DevOps" to be more than just a simple shift of SysAdmins to Cloud.

</comment><comment><USER31> "a DevOps"

<comment><USER32> One DevOps please.

<comment><USER33> "Sir, please drive through, this is a Burger King."

</comment></comment></comment><comment><USER34> I appreciate the "I've had contact with <technology>" phrasing used here.

It gives just the right characterization of qualification - _" I've used it and been paid. I'm not necessarily an expert"_ \- needed when living in a rapidly churning set of technology ecosystems.

</comment><comment><USER35> "DevOps" == "sysadmin that can write scripts"

<comment><USER7> Or "a developer that does on-call"

I'm being facetious. Sysadmins always wrote scripts and developers always got called at home.

<comment><USER36> The best always did.

Many of the rest did, but not high quality scripts, and only in shell; not perl or python or tcl or ...

The lower rungs of sysadmin were happy to point and click on guis and lug and plug hardware.

<comment><USER35> Yes, "DevOps" is basically an attempt to weed out the best sysadmins from the rest in the job market, because if you look for 'an experienced sysadmin' you'd usually find a guy who laid cables and replaced mice for 1000 Windows workstations instead of 10.

</comment></comment></comment></comment><comment><USER37> Nice article! I also do consultancy in that field and your article describes my work situation by 90%

</comment><comment><USER38> Fix my tools instead of the product.

</comment><comment><USER39> convincing my boss to let the machines and our code to do our job

</comment><comment><USER40> To everyone in this thread: this is an article, not a question to HackerNews.

</comment><comment><USER41> Now with the advent of software such as Rundeck, the majority of tasks and automation can be consolidated into a singular control panel. Now I focus more on project based work and reduce time fumbling with random annoying tickets.

It makes it more manageable to juggle the diverse work we are responsible for in a "DevOps" role.

<comment><USER42> It is customary on HN to disclaim when you work for/on a product that you are pitching or suggesting.</comment></comment>


The EpiPen, a Case Study in Health System Dysfunction - <AUTHOR> http://www.nytimes.com/2016/08/24/upshot/the-epipen-a-case-study-in-health-care-system-dysfunction.html <comment><USER4> It's unfortunate the NYT story doesn't get into the billings process as part of the dysfunction. It makes me wonder how the pricing is then negotiated with the insurance companies. Did they set the retail price so high because the insurance companies were refusing to pay a workable price? Mylan has already commented that most EpiPens are paid through insurance, and there's the "billed rate" and "paid rate" on claims reports which often shows outrageous retail prices by health providers and then the negotiated rate the insurance company actually paid. Mylan's "quick" offer of a $300 discount to individual payers appears to keep in line with this and potentially not impact the insurance claim issue, but does anyone have any evidence that this theory is mistaken?

<comment><USER5> If that's the case, then the market equilibrium makes un/underinsured patients collateral damage in a battle between pharmaceutical and insurance companies. That's a massive market failure that's killing its victims.

Here's my capitalist suggestion: figure out how much the pharmaceutical company stands to earn from life saving medication. Then let the government purchase the rights and put them in the public domain. The variable costs of producing these things is so low that we can treat every one for nearly the same price as treating only the rich.

<comment><USER6> Lets go further: nationalize drug companies. Do this to _all_ the drugs.

<comment><USER7> I think it would make more sense to simply have a government owned corporation who's sole purpose is to produce generic drugs on which the patent has expired.

<comment><USER8> The market for drugs like that generally functions quite well. Like a cash price of ~$5 a month well.

(The dustup over Martin Shkreli raising the price of Daraprim only happened because there were very few users of the drug)

</comment></comment></comment></comment></comment><comment><USER9> "When Mylan bought it, EpiPens cost about $57 each."

I can concur. I have a family member I purchase these for. At first, it was like...okay, $50 after insurance. Now $100 after insurance. The thing is...nobody really seems to care until things spiral out of control. Who the hell is watching our backs in America? Is it the FDA, the FTC, Congress (likely too busy defunding AMA to care), the DoJ? No idea. I wonder if gov't agencies like the DoD who stock tons of epipens pay the same prices that we the public do? Does the DoD purchase from another market to get out of the huge sticker price? I'm curious to see how many people in the gov't get around purchasing these in the US for their own agencies yet didn't raise extreme alarm at the ballooning prices for the American consumers.

<comment><USER10> what is really amazing is the epi pen, even for those who need it, is a tiny fraction of our healthcare costs. the gorilla in the room is doctors pay, in which the US purposely keeps low in supply to keep the wages high.

doctors easily make north of 200k after residency(a number almost no engineer will ever come close to), and people complain over hundred dollar epi pens.

<comment><USER11> Take home pay for physicians represents about 10% of healthcare spending ([http://economix.blogs.nytimes.com/2008/11/14/do-doctors- sala...](http://economix.blogs.nytimes.com/2008/11/14/do-doctors-salaries- drive-up-health-care-costs/)). On top of the cost of 4 years of college, you've got 4 years of medical school (average med student debt is $167k - [http://www.cbsnews.com/news/1-million-mistake-becoming-a- doc...](http://www.cbsnews.com/news/1-million-mistake-becoming-a-doctor/)). On top of that, you've got 3-7 years of residency where residents barely make $50k/year while working ~80 hours/week (this is a reduction from ~120 hours/week after regulations were passed). Becoming a doctor is expensive, requires massive sacrifices in time, and doctors don't earn their full salaries until almost a decade after most people start their careers. It doesn't seem like physician salaries are a clear cut problem.

<comment><USER10> engineers barely make more than a doctor in residency. virtually no engineer on earth makes as much as any doctor after residency.

i dont know about you, but i pulled 80+ hour weeks working, studying, and skill training to get myself where I am today. If I am lucky, and If I spend nights reading code interview books, practicing my skills, maybe I'll get a great job at google/facebook after 4 interviews and some connections making 1/3 - 1/2 as much as an average doctor.

<comment><USER11> I'd be more inclined to buy your argument if you supported it with evidence. Also we're talking about the impact of physician salaries on healthcare spending. Engineer salaries aren't relevant in this discussion.

</comment></comment></comment></comment></comment><comment><USER12> This is concerning on so many levels because there are multiple agencies that are supposed to oversea and simply avoid issues like this.

In principle I am opposed to regulation, but in this case, where all other measures have failed, I say regulate away.

I want to call out Heather Bresch, Mylan CEO, by name because she and Martin Shkreli are the problem as well as any investor or board member that doesn't steer them back to being human.

This comes down to life and death for people. The instrument is simple, accessible and cheap. This doesn't make the instrument more valuable, but more necessary. Mylan is simply exploiting its customer base temporarily caught in the middle.

<comment><USER13> > In principle I am opposed to regulation, but in this case, where all other > measures have failed, I say regulate away.

But the article says there would be competition except that it's too hard to get a product to market. Doesn't the author mean it's too hard to compete because of regulation, like from the FDA?

<comment><USER12> Pardon if this point wasn't clear. I am talking about additional, direct regulation related to this product and this issue.

Normally, I would say the logic doesn't follow that, the answer to failed regulation is more regulation. However, in this case, my opinion is that we should call this out for what it is and do something to counteract it.

<comment><USER14> This is a ridiculous stance to take. So because one drug/company decided to raise prices 1500% we need to take immediate and specific action.

But those companies who operate at 600% markup in the same industry are perfectly fine.

I can guarantee you the latter are where the actual problem lies - since it's systemic. The outliers that get press are good - but only if people solve the problem vs. kneejerk reactions like specific legislation for a single drug.

My point is that _every_ drug company is doing this. And not a little bit. We shouldn't set some ridiculous threshold before we take action (as long as we're stolen from, it's ok if it's only a small amount right?) - we should fix the problem where it begins. This means adding competition to the market, in which case the usual race to the bottom should occur. You are basically advocating for a tiny measure that "fixes" a fraction of a fraction of a percentage of wasteful drug spending - and simply focusing on manufactured outrage. This is how the industry continues to win.

<comment><USER12> It's not ridiculous at all.

If we are talking about one company then specific action seems appropriate.

I agree that there are systemic issues. I think that is a larger conversation that will take more time. There are merits to the European systems that are generally more liberal, or at least are characterized as such, and likewise, merits to the US system. We could probably cherry pick examples in each system and perhaps that is how it will continue in that larger conversation.

However, in this instance, which is the context I am focused on we recognize that allowing a monopoly is a failure. It presents special circumstances, so special action to sidestep the bureaucracy seems appropriate to me.

I believe that the proverbial 2x4 to the head (of Mylan, in this instance), would do more to further the larger conversation and the points we agree on, than waiting for the conversation to conclude with a pretty bow. It won't.

Making examples of the most egregious perpetrators has an immediate, albeit incremental impact.

<comment><USER14> I guess we'll have to agree to disagree. I see negative value in stamping down the outliers. This just sweeps the conversation under the rug and people feel good about "doing something". We then all can rage against the latest scapegoat who is doing exactly what everyone else in their position is - <USER2> just got a bit too aggressive and got unlucky on the roll of the PR dice. The rest of the industry laughs and continues to reap 900% margin on generic products, and increases it 15% next year since 15% is totally reasonable. We then repeat the next two minutes of hate every 2-3 years.

We are talking about a price increase from a floor that was _already_ absolutely insane. $300 for a $20 or less to manufacturer device is already being ripped off, and we are only just now talking about it because it went to $600. Why is there a difference in reactions here? Are you the one who gets to judge a $580 profit is ok vs. a $280 profit? Why? They both seem obscene to me - why is this just now becoming a problem? Obviously $300 is an acceptable price - so is $400? $500?

This is just the tip of the iceberg. If you start by clipping the tall poppies you might get some extremely slight downward pressure on prices in the market - but that does nothing to solve your actual problems. It's penny wise and pound foolish and is the approach we've thus far taken with predictable results.

<comment><USER12> I think that, generally, in principle, we agree.

Where we disagree is in practice.

Doing nothing, or a little empty outrage is sweeping it under the rug, or "the approach thus far."

What I am talking about has a practical benefit beyond targeting the worst offenders, which again seems appropriate. Establishing a precedent for what is "too aggressive" frames the conversation going forward. Otherwise, your logic, "Obviously $300 is an acceptable price - so is $400? $500?," is valid. When human lives are at stake I don't think it is. So, establishing a precedent and thereby the beginning of a framework we move the conversation forward rather than just another lap on the rotary.

I also disagree that doing something is the same as doing nothing. I find that practically and logically false. Particularly, in the context of progress in a bureaucracy, it has been the modest incremental changes that have created the opening for larger reform.

<comment><USER14> I think we generally agree in the outcome we want, just disagree on how to get there.

I'm not proposing doing nothing. I'm stating making targeted efforts to go after this specific case is a silly waste of effort (at best - at worst it's placebo) is all. I would rather see that effort go towards actually reforming the system that allows monopolies to form when they don't make (open) market sense.

Otherwise I do think we agree - the end result is Mylan can't charge $600 Epipen.

<comment><USER12> I acknowledge and respect your preference for larger reform. I think that would be great.

In the meantime, why is it binary in your mind? Why is it larger reform or nothing?

Because this does have a life and death impact, I don't think it is silly, or a waste. The efforts, at worst have potential to move the larger reform forward, and at best potentially save a life.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The World Trade Organization has a provision known as "Compulsory Licensing" which can be used in extraordinary situations such as this. Compulsory licensing is when a government allows someone else to produce the patented product or process without the consent of the patent owner.

A few years ago, India's government authorized a drug manufacturer to make and sell a generic copy of a patented Bayer cancer drug because the price charged by Bayer was unaffordable to most of the nation. The US pharmaceutical industry has been up in arms about this, and has been exerting pressure on India to stop this practice. But abuses of the system by Mylan (with EpiPen), Turing (with Daraprim) and others would seem to justify the Indian practice.

In fact the US would do well to copy India's model. Citizens should be able to sue corporations for egregious abuses of the patent system, and courts should be able to provide relief in such cases by granting a compulsory license of a drug patent to a generic maker.

Read about compulsory licensing here: [https://www.wto.org/english/tratop_e/trips_e/public_health_f...](https://www.wto.org/english/tratop_e/trips_e/public_health_faq_e.htm)

Read about India granting compulsory license to Bayer cancer drug here: [http://www.nytimes.com/2012/03/13/business/global/india- over...](http://www.nytimes.com/2012/03/13/business/global/india-overrules- bayer-allowing-generic-drug.html)

<comment><USER16> An interesting model, taking advantage of other countries taxpayers and innovation so you never have to fund any research yourself.

I'm sure that will work out well to better humanity as a whole - <USER3> when there's no reason to actually invent anything new because every other country is just waiting to steal it.

</comment></comment><comment><USER17> Isnt this a much more simple tale of greed and corruption. the ceo is the daughter of a democrat senator and lobbied big government the jacked hwr salary 600x. Just another shkrelli, maybe even worse because she lobbied for schools to have them.

</comment><comment><USER18> The majority of the comments here are interesting to me because they're talking about the cost of an epi-pen after insurance. The problem doesn't seem to be some mismatch of the interplay between drug price and insurance rebate but just how incredibly expensive an epi-pen is in America because of a lack of collective bargaining on price.

For comparison, here in Australia, the dispensed price for an epi-pen is 96.57AUD which includes everything, even the maximum markup from the pharmacist (as far as I understand the pricing mechanisms). Of course, depending on insurance arrangements and personal circumstances you'll end up paying less with a maximum of 38.30AUD out of pocket but that's a different part of the system.

I don't see how the dysfunction is any of the things mentioned in this article as opposed to the ridiculous prices insurance companies and patients are being charged for it. Many drugs expire quickly, are hard to administer, and are difficult to make. All that means is that we need them done well and we need to pay the least we can.

<comment><USER8> There are various entities that collectively bargain drug prices in the US. It's just that other groups and individuals may not have access to the prices they achieve.

(several large insurers provide coverage for more people than live in Australia)

It seems the problem in the US is that a patent that "improves" a product ends up creating a new period of exclusivity (it's not clear to me if this is just because the improved version becomes the new standard of care or because people are nuts and demand the very best regardless of whether the difference is particularly significant).

</comment></comment><comment><USER19> The most interesting thing here would be the lack of competition, but the article, which was pretends to be a "case study", just leaves it at "various reasons". What the hell? It's not like an individual company's responsible for keeping the price sane; it should be kept down by the whole market — and if the market's malfunctioning, government's to blame, not the company.

</comment><comment><USER20> I've got a question about price caps, would appreciate a non-trolly/non- sarcastic answer if anyone is informed on the topic.

We know that epi-pens cost under $50 to make, because they're sold profitably in Canada for around $60.

And I recognize that companies are entitled to make a profit, and that drug companies (sometimes) use those profits on R&D for new and better products.

But we see instances of clear cash grabs. Sometimes they're due to circumstances (in this case, a generic alternative failed FDA approval, and a competitor left the market); other times a drug company will buy up competitors and consolidate the market (Turing Pharm).

Why don't we have some sort of market cap of 3-4x or even 10x the cost of manufacturing a drug that is implemented after the R&D has been paid off? I get that companies would bend over backward to inflate that R&D figure, but sooner or later they would have to admit that it was paid for and need to settle into a mode of merely making reasonable profits instead of insane profits.

</comment><comment><USER21> It would be interesting to hear the other side of the story. So far, as in this piece, there is only the implied or stated theory that the price increases are due to greed, or just because they can.

This whole thing reminds me of the flu vaccine debacle. The original narrative was that flu vaccines cost less in other countries, so why not in the US? Must be due to some greedy capitalists! The truth turned out to be a bit more nuanced.

[http://webcache.googleusercontent.com/search?q=cache:-08YyGE...](http://webcache.googleusercontent.com/search?q=cache:-08YyGEf18EJ:www.ncpa.org/pub/ba493&num=1&hl=en&gl=us&strip=1&vwsrc=0)

It should surprise no one that these kinds of price problems occur in a system with heavy regulation, very little choice, and no transparency.

<comment><USER8> There's a different epinephrine auto-injector that has generic versions. The generic versions cost $150 for a set of two ([http://www.goodrx.com/adrenaclick](http://www.goodrx.com/adrenaclick)).

It's reasonable to assume that most of the $350 difference goes to things like marketing, profit and shenanigans to encourage people to utilize their insurance (the rebate cards eliminate copay and some deductible costs and extract money that eventually has to be paid out of premiums...).

<comment><USER22> If there's an alternative, then what's the issue? Well a quick search shows 2 alternatives have had recalls. So maybe they have QA issues. Adrenaclick says they lack the ability to scale up to more market demand. So perhaps they should raise their prices a bit to build out facilities?

<comment><USER8> If you twiddle the generic/brand menu (just to the right of the blue "Prescription settings") at my above link, you'll see that their price is already ~$475.

So my above point is more that the generics provide a lot of information about what it costs to have a product on the market (which the comment I replied to was speculating about). When companies price higher than that, they are presumably doing it in a way that tends to maximize profits and are responsible for the choices they make to do that.</comment></comment></comment></comment>


Punched cards: One of the biggest breakthroughs in programming history - <AUTHOR> http://en.wikipedia.org/wiki/Punched_cards

<comment><USER2> When I was a child (8-10 y) I used to collect them, my parents worked in a computer facility with lots of room-sized computers. Ah, good times... :)

<comment><AUTHOR> It's cool to see, in Amsterdam, some people with those music trolleys that play it using punched cards. It shows that technology sticks around for a while longer than one would expect :)</comment></comment>


Canadian startups bring big data to inefficient industries - <AUTHOR> http://www.theglobeandmail.com/report-on-business/small-business/sb-growth/day-to-day/farms-factories-and-film-sets-startups-bring-big-data-to-inefficient-industries/article20574000/

<comment><USER2> This reminded me of arguments against plan economics of Soviet Union - "plan economics is infeasible" they said.

Oh, the irony.</comment>


KDevelop 5.3.3 Released - <AUTHOR> https://www.kdevelop.org/news/kdevelop-533-released <comment><USER2> A bugfix release, so not that interesting. However it's an opportunity for me to express my gratitude to the KDevelop team for producing such a fine IDE. Its Python static analysis plugin is first rate and extremely convenient, and it shares the KTextEditor component with Kate, which leads to a pleasingly consistent experience if you use KDE (and Kate is a fantastic editor in its own right).

<comment><USER3> I used it back in college (10 years ago), being a dedicated Windows Dev. It was the only IDE that came close to approximating Visual Studio (after a few trivial tweaks) and deeply impressed me. The C++ support was probably better than VS.</comment></comment>


Google Streetview stop motion (video) - <AUTHOR> http://flowingdata.com/2011/11/24/touching-google-streetview-stop-motion/ <comment><USER3> Google should add a 'continuous drive' mode.

<comment><USER4> I'm attempting this (360 video street-view) for Buenos Aires.

It is certainly feasible but there are many factors involved, starting from the right lens to dealing with the bureaucracy when trying to acquire permits.

Storage is an issue. A couple of city blocks means a few GB without compression. Since I'm shooting for high quality, I need a better solution than a measly notebook.

Of course, I'm just a mere mortal without an appropriate income for this stuff. Google could do this in their sleep.

<comment><USER5> Google's shown something like this off before. Video at <http://techcrunch.com/2009/12/07/google-liquid-galaxy/>

</comment></comment></comment><comment><USER6> Wow, this is really awesome. Google should contact this person and use it as a long-form commercial for Street View. I think it sells it better than anything else I've ever seen. Incidentally, it fits almost perfectly to fill an entire commercial break.

</comment><comment><USER7> This is a brilliant piece of beautiful and clever animation, there's no doubt about that.

But is it really stop motion street-view? I didn't think street-view's increments were that small. Not that it should take anything away from the final product if it wasn't, I'm just wondering.

<comment><USER8> On Vimeo he says that everything on the computer screen is animated without any replacements. So I'm guessing that yes, it's all just street view.

<comment><USER9> The first part looks like street-view, but the rest is clearly not - <USER2> the overtaking cars in the tunnel...

<comment><USER10> Street view is built via a camera mounted on a truck driving on the street. I see no reason that the captured frames wouldn't include normal traffic flows.

</comment></comment></comment></comment><comment><USER11> Beautiful video but IMO it has not its place on HN.

<comment><USER12> Right. Unless there is some more information like the making of, it would just make HN another Reddit.

Also, why link to some blogspam when the _more informative_ Vimeo link is right there.

<comment><USER11> From the description of the video on Vimeo, here are some making-of pictures: [http://www.facebook.com/media/set/?set=a.293407880691317.735...](http://www.facebook.com/media/set/?set=a.293407880691317.73582.135537249811715&type=3)</comment></comment></comment>


Apple Q3: Best Mac Sales Ever And Huge iPad Numbers - <AUTHOR> http://sec.gov/Archives/edgar/data/320193/000119312510161807/dex991.htm

<comment><AUTHOR> Interesting facts from the press release and call:

-Still having issues with meeting the demand for iPad and iPhone 4

-iPhone 4 has lower margins than 3GS

-Apple has about $50 per share in cash (20% of current share price)

-80% of Fortune 100 are either deploying or piloting the iPhone. 50% doing same with iPad.

<comment><USER2> 80% is a typo for 60%, right? It says 60% on tech crunch.

<comment><USER3> Techcrunch is wrong. I read the 80% figure transcribed directly at MacWorld as well.

</comment></comment></comment><comment><USER4> I didn't realize Apple had invented magic as well!

> [Apple] has recently introduced its magical iPad which is defining the > future of mobile media and computing devices.

From the press release in TFA

<comment><USER5> Their technology is just sufficiently advanced.

<comment><USER6> Sufficiently polished, anyways. Underlying technologies are getting less important than polish and interfaces, at least to the average user.</comment></comment></comment>


Libcloud: a unified (python) interface into the cloud - <AUTHOR> http://libcloud.org/

<comment><AUTHOR> We're looking for folks who would be interested in "owning" a particular provider. Shoot us a note on the mailing list if you would like to participate! Although, patches speak louder than words. :)

<comment><USER2> [Disclaimer - I work for Windows Azure]

I think this is a great library and I would love to see it work with Windows Azure. Windows Azure doesn't have a service management API today (we only have storage APIs) but we are working on one and we'll have it by the end of the year[1].

I do think it'll need some changes to work with us (or with AppEngine for that matter) since libcloud seems to deal with raw nodes and Windows Azure likes to deal with 'services' as the first class entity with the raw nodes/machines/VMs/whatever just being various instances of something we call 'roles'. I think you could kind of hack around that in your code but it wouldn't be very elegant.

[1] I'm the person responsible for them so feel free to reach out to me. I can't reveal much of how it will look like in public yet though.

<comment><AUTHOR> It is true, we're initially targeting providers that will give you a "server via API call". When you're developing against AppEngine (and I imagine Azure), you're committing to that platform, because it is very very specific. Whereas when you develop against Amazon or Slicehost, the server is the common unit ... which you are free to do whatever you like with.

That said, I think there is a lot of room for a similar project with storage. Amazon S3, Rackspace Cloud Files ... and maybe Azure will fit in there?

As for libcloud, we're trying to provide a DBI like thing for cloud server providers. It's not the end-all solution, but it is a clean first step towards cloud portability.

<comment><USER2> You can hack around it (but like I said, it isn't very clean). I can't speak for AppEngine or the others but on Windows Azure, you're really committing to Windows but not Windows Azure. So in theory, anything that works on Windows should work on us (we don't run things in a sandbox as some people like to say though we do run you currently in a normal user account without admin privs).

One way to implement this would be wrap a Windows Azure service around whatever you want to do on a node/server and then deploy that service. For example, if you have a Windows server where you install a ASP.NET app or a PHP site by xcopying binaries, you could do the same thing by wrapping that into a web role and put that in a Windows Azure service.

By doing this, you do miss out on some of the advantages of the platform but it should make it fit into your model.

</comment></comment></comment></comment><comment><USER3> Launching and stopping servers is a small part of the portability hassle. The big part is a unified image and data plan. Things like building images programmatically from templates (look up rBuilder) and calling back to some centralized thing to seed the image with context/data to work on can help (many variations in these areas).

That said, I am glad to see more people releasing tooling in this area and appreciate the open licensing! Not trying to rain on this parade or anything.

</comment><comment><USER4> Great! I'm a slicehost user and happy to see them here, but nice to be able to do this stuff in a non-platform specific way.

</comment><comment><USER5> I attended your talk at Oscon, and am really excited about this project, thanks for releasing it. You'll see me on the mailing list soon.</comment>