Nokia CEO: Nokia is "standing on a burning platform" - <AUTHOR> http://www.engadget.com/2011/02/08/nokia-ceo-stephen-elop-rallies-troops-in-brutally-honest-burnin/ <comment><USER2> This is an excellent, really excellent call to arms from a new CEO. I have a few takeaways -- first: the board brought Elop in for a four to seven year turn-around. He's going to make enemies, but that's okay. If he executes the turn-around, they'll put someone more finnish back in to sooth the old guard after they're making money again.

Second -- this guy has the Microsoft internal criticism DNA, through and through. This isn't quite a Gates-level memo, but it's in the ballpark. I'd love to see some leaks of him reviewing his experience using different phones, Gates style.

Third -- he's totally correct. Nokia f-ed this up, all by themselves. I STILL miss my Nokia E-90; it had 7mb up and down, a beautiful keyboard, video chatting, first-class SIP phone account support, and an 840x320 screen in 2007, for God's sake! The UI sucked, the apps weren't there, and there was no touch interface. Apple cleaned Nokia's clock. Then Android did it again.

One reason HN readers should care: Nokia is probably the only carrier in the world with the balls to just go ahead and release unlocked phones with things like VOIP accounts built in. They may be the only company who doesn't have to play nice with US carriers around; innovation from them will be excellent for consumers.

<comment><USER3> Nokia regularly cripple features, specifically including VoIP, at the demands of carriers. Perhaps not US carriers, but it happened frequently in the UK.

I took the calls of people angry that their 'top end' handset couldn't do VoIP because they bought it from Vodafone.

The carriers were always Nokia's customers, not the consumers, I can't see how that's going to change.

<comment><USER4> > _Nokia regularly cripple features, specifically including VoIP, at the > demands of carriers. Perhaps not US carriers,_

Oh, definitely in the US—look at the difference between the E71 and the E71x, the AT&T version. The GP was talking about _unlocked_ phones. I have an N86 which I bought on Amazon, and it's got SIP and other features which AT&T would hate me to have.

> _The carriers were always Nokia's customers, not the consumers_

Yeah, but that's the case with every phone manufacturer.

<comment><USER3> > Yeah, but that's the case with every phone manufacturer.

That's exactly my point. In this regard Nokia are not in a special position to stand up to the carriers.

Unlocked handsets don't count: almost no one is paying that much for a phone. Even Apple had to accept carrier subsidies for the iPhone to get the end purchase price down.

<comment> Tuna-Fish > Unlocked handsets don't count: almost no one is paying that much for a > phone.

Most mobile phones in the world are bought unlocked. Carrier-locked phones holding most of the market is an US/UK quirk, and in many European countries, carrier-locked phones like used in the US would actually be illegal.

<comment><USER5> Locked Phones are the norm in Germany too. If this holds true for France too, the vast majority of mobile phones in Europe is being sold locked. I don't know the details about the "illegal" claim, but normally those things are governed by EU laws, making it somewhat hard to believe that contracts common in the UK and Germany would be considered illegal in the Netherlands or Portugal.

<comment><USER6>
      Locked Phones are the norm in Germany too.

You forgot to add that this is only the case for subsidized phones. Nobody stops you from going to Media Markt to purchase an _unlocked, uncrippled_ phone for full price.

In addition: SIM locked (i.e. only able to use a designated network) is not quite the same as a crippled phone (like in intentionally crippling the Bluetooth stack to force users to use a crappy service to upload photos for a couple bucks a pop).

I can't speak for Germany, but in Switzerland the only SIM locked phones are the ones that you buy together with a pre-payed deal. And then they have to unlock it for you after a couple years.

Personally I perceive the development of locking down devices as rather disturbing and I really hope that this trend doesn't swap into European mobile phones. That's why, yeah, I feel that Nokia matters a lot.

<comment><USER3> Except that Nokia have been locking down handsets at the request of carriers for years (cf, earlier comments about VoIP on Vodafone on certain Nokia handsets). They really do have no special power to say 'no' to those guys. None whatsoever.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> A well-written email is more powerful than many people comprehend. We used to call them letters, and they were powerful then too.

You can change a person's or a group's mind about something, even after a decision appears to have been made. You can clinch a job, win a contract, stop a lawsuit, regain a friend, woo a lover, and change history itself with just a few words.

I'm not sure if people realize quite how powerful an email can be, directed at the right audience, at the right time, with the right message. And the flip- side is true too. A badly written, poorly directed, or mis-timed email can have terrible consequences. You can make or break a company with a single email.

Regarding this memo, it's a truly inspiring, and well-timed. I think this will be a Gettysburg moment for the CEO, and may mark a turning point for Nokia.

<comment><USER8> Very well said. It's a great memo, but its main effect is to lay the groundwork for a strategy change.

 _This means we're going to have to decide how we either build, catalyse or join an ecosystem [...] When we share the new strategy on February 11, it will be a huge effort to transform our company [...] The burning platform, upon which the man found himself, caused the man to shift his behaviour, and take a bold and brave step into an uncertain future._

This may be a turning point for Nokia, but in the end it will come down to just what this new strategy _is_ and how effective it proves to be.

<comment><USER9> No matter how good the strategy looks on paper, it's useless unless everyone buys in. Its effectiveness will depend to a great extent on how well the new strategy, and more importantly the need for it, can be sold internally.

</comment></comment></comment><comment><USER10> > _The battle of devices has now become a war of ecosystems, where ecosystems > include not only the hardware and software of the device, but developers, > applications, ecommerce, advertising, search, social applications, location- > based services, unified communications and many other things. Our > competitors aren't taking our market share with devices; they are taking our > market share with an entire ecosystem. This means we're going to have to > decide how we either build, catalyse or join an ecosystem._

Please, please, Nokia, adopt Android and put your efforts into making great hardware to go with it, without ruining the interface like so many other manufacturers do.

<comment><USER11> I'd rather Nokia actually be the only truly open mobile platform out there. No, Android isn't sufficiently open.

It's _my_ phone, at a minimum I should be able to pull all my own data off it in any form I choose.

<comment><USER12> IMO a GNU/free fork of Android would _still_ be a better platform than MeeGo or Symbian, and would be cheaper to develop.

<comment><USER13> There is no such thing as a free Android, except if you tear the whole Java user space away.

And I'm REALLY curious about why you and 14 other people think that Android is such a good mobile OS. The VM is both a legal and speed liability, the Android UI is not GPU-accelerated and the entire OS is still immature (see the embarrassing bugs with the SMS or the browser security holes).

<comment><USER14> > There is no such thing as a free Android, except if you tear the whole Java > user space away.

Isn't that part BSD-licensed?

> the Android UI is not GPU-accelerated

It's a bit hard when you have to support more than one device, but I believe it's a matter of time. As more and more hardware gains hardware acceleration, I assume it will come (if not already in the latest 2.x and 3.x series)

> the entire OS is still immature(see the embarrassing bugs with the SMS or > the browser security holes)

Don't confuse the OS with the programs that run on it. You don't blame Windows when SharePoint eats up all your intranet, do you?

<comment><USER13> The license doesn't matter that much, it's the principles - one of them being that you don't get sued by such and such corporation if you use the code. Or Google doesn't change the terms if they lose on trial. No one has patents on C or C++ AFAIK...

SMS and web browser are core mobile OS services, they're not simple programs since connectivity is very important for a mobile phone.

<comment><USER14> > No one has patents on C or C++ AFAIK...

Oracle is not complaining Google is implementing Java in Dalvik. Oracle is complaining they are implementing things too similar to stuff Oracle has acquired patents about.

[http://carlodaffara.conecta.it/oraclegoogle-the-patents- and-...](http://carlodaffara.conecta.it/oraclegoogle-the-patents-and-the- implications/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I worked for Sony Ericsson when the iPhone was revealed. My job was to translate the thousands of pages of operator requirements that came in (within my technology area: Java) to a technical roadmap for the coming 2-5 years. So I have a fairly good picture of how the market for mobile phones work wrt to the interplay between operators and manufacturers.

It's hard to grasp just how revolutionary the iPhone was. There are so many tiny things that's not by itself a revolution, but adding them all up and you're going disruptive.

I tried to compile some of it in a list here:

[http://blog.opportunitycloud.com/2011/01/21/what-apple- did-w...](http://blog.opportunitycloud.com/2011/01/21/what-apple-did-wrong- with-the-iphone/)

<comment><USER16> Apple releases iPhone, from the well-thats-not-very-exciting dept.

...

No 3G, no MMS, no video calling, shitty camera & bluetooth. Lame.

</comment></comment><comment><USER17> I worked for Accenture (then Andersen Consulting) in Paris in 1995 when a new team of Englishmen were brought in from London to "turn the French practice around".

Their theme? "Burning platform". The exact same story that opens the memo was their story too.

Maybe this Mr Elop is really an original thinker that will do great things; but the "burning platform" analogy is the most tired image EVER.

Oh, and did it work in Paris in 1995? Not really. It was not an absolute disaster, but in the end (two years later) the British threw the towel and went home, and the French partners who were there before stayed on (are still there to this day).

<comment><USER18> Where else have you heard it? What makes it a tired image beyond the fact that you heard it once in Paris?

<comment><USER17> I didn't hear it "once"; it was a central theme of the transformation story; there were posters everywhere, email campaigns, leaflets, etc. all based on the "burning platform" standard playbook.

The reality is that the "burning platform" metaphor is a classic story repeated ad nauseam in business schools and business books; see this for example (from 2005):

 _The term "burning platform" is a mainstay in business lexicon for many years.

For those not familiar with its origin, the story goes something like this:

A man working on an oil platform in the North Sea awakened suddenly one night by an explosion. Amidst the chaos, he made his way to the edge of the platform. As a plume of fire billowed behind him, he decided to jump from the burning platform even though jumping is a risky option for the following reasons: It was a 150-foot drop from the platform to the water.

There is debris and burning oil on the surface of the water.

If the jump into the 40°F water did not kill him, he would die of exposure within 15 minutes.

Luckily, the man survived the jump and hauled aboard a rescue boat shortly thereafter. When asked why he jumped, he replied, "Better probable death than certain death." The point is the literally "burning" platform caused the radical change in his behavior._

<http://www.imakenews.com/cppa/e_article000368179.cfm>

(Please read the rest of this article to know how the story should be used in a business context; it really seems to describe the email, and it's prophetic since it was written six years ago).

Where do you think Mr. Elop heard this story in the first time? What's more likely, that he met an actual burning platform survivor, or that he read about this very common story in a business book?

<comment><USER19> The "burning platform" inspirational stories are probably based on an actual disaster:

"Piper Alpha was a North Sea oil production platform operated by Occidental Petroleum (Caledonia) Ltd. The platform began production in 1976, first as an oil platform and then later converted to gas production. An explosion and resulting fire destroyed it on July 6, 1988, killing 167 men, with only 59 survivors. The death toll includes two crewmen of a rescue vessel. Total insured loss was about £1.7 billion (US$ 3.4 billion). At the time of the disaster the platform accounted for approximately ten percent of North Sea oil and gas production, and was the worst offshore oil disaster in terms of lives lost and industry impact."

<http://en.wikipedia.org/wiki/Piper_Alpha>

</comment></comment></comment></comment><comment><USER20> Stephen Elop has finally put in writing what the market has said about Nokia ever since the iPhone came out. Props to him for finally initiating this intervention at Nokia; it has been long overdue. Someone has finally said "we have fucked up, its now time to get back on the horse and make it right" to the Nokia management.

Less than a decade ago, nobody could ___touch_ __Nokia in the mobile handset market, Nokia defined quality... and then they got complacent and instead of innovating, they stuck to old principles. Its like Nokia witnessed the age old fable of the tortoise and the hare firsthand.

<comment><USER21> Your comment and Engadget's article seem to imply that Nokia failing in the smartphone market means that Nokia is failing generally. But wouldn't Nokia still be making a lovely profit even if they stuck to the more vanilla phones?

Don't forget that only a fraction of people can afford these >= £500 devices and only a fraction of those buy them without financing.

<comment><USER22> Nokia used to be up around 60% of the mobile phone market (in terms of profit). Now they're around ~20%, while Apple is more than 50% (on less than 5% marketshare).

Nokia is still making money, but pretty much all new profit is going to everyone else (especially Apple).

<http://www.freerepublic.com/focus/f-chat/2666565/posts>

<comment><USER23> Do you think there is a fixed "profit" out there for the taking?

Apple's profit margin is an extreme aberration, and it isn't sustainable. Any comparison that relies upon profit numbers is...disturbed.

<comment><USER24> Apple has been making similar margins on all of its products for the past 10 years. How can you say it isn't sustainable?

<comment><USER23> 10 years ago Apple had 5 billion in revenue. Now they're pushing 100 billion in revenue. They butting in on competitors who operate in the 5% margin range, and who are all desperately starting to claw back at Apple's gains.

No, it isn't sustainable. History will prove me out, and in 3 years I would bet that Apple has seen a significant margin haircut. Quote me on a 50% decline.

As a comparison, by the way, look at Sony (which was the Apple before Apple). Once a purveyor of high margin audio equipment, they saturated that market and started moving to high markup mobile audio equipment...and then TVs...and then lower markup mobile equipment, etc, and then everyone started fighting back.

Apple is exactly following the Sony curve.

EDIT: Arrowed down. This is one of those seminal moments that speak volumes about a community, and I think HN is done (just furthering an observation that has grown). Account and site abandoned.

<comment><USER24> One downvote on a site where the voting arrows are tiny and close together and votes can't be reversed is a "seminal moment that speaks volumes about a community"? I think you're being a little melodramatic.

Anyway, Apple has always had a disproportionate share of any market it seriously participated in — the big difference is that 10 years ago Apple was a very small part of a single market. Some fluctuations will probably happen over the next half a decade, but you can bet that Apple will remain absurdly profitable in a way that embarrasses most of its competitors. It's just something that Apple is good at.

<comment><USER25> _you can bet that Apple will remain absurdly profitable in a way that embarrasses most of its competitors. It's just something that Apple is good at._

I'm betting it's not. It's something Steve Jobs is good at.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> This memo is spot on, except for the optimism at the end. I think Nokia is toast.

At the end of the day, you can't create a best-of-breed product out of nowhere. You need the core competencies to be already present in your company's DNA.

Palm came back out of nowhere and created in the Pre a phone with great usability fundamentals, and an incredibly innovative contact/data management layer. But that didn't come from nowhere.... those are exactly the things that the Palm Pilot excelled at.

Apple created a phone with incredible industrial design that pushed the boundaries of what was possible in a category of device. These things, also, have lots of precent at Apple, in the Macintosh, the iPod, OS X, and the iTunes music store.

Google, in Android, built a phone OS that has incredible integration with networked apps, and is built on a well run open source project. But before they started, they already had the best network app development teams in the world, and many world class open source developers and evangelists on staff.

What does Nokia have? I'm honestly not that familiar with their history, but they appear to have had (at one time) world class supply chain management and global distribution. And solidly built hardware? Is that it?

Honestly, I think Nokia had the right DNA to make a huge contribution to cell phones when they were a brand new, untested product with limited global reach. But now that those issues have been nailed, the distribution channels are in place, and everyone's phones, from Motorola's Android phones to LG's crappy feature phones are "good enough" for the people who buy them.

My guesses for the big future developments in phones are the web maturing as a development platform (Google seems positioned to ride that wave), powerful new software APIs (social, location, augmented reality, AI, etc), new media distribution models (Netflix, iTunes, Shopify, etc), and of course design- driven expansion of the user experience (Flipboard, FaceTime, Google Maps, etc).

I don't see product teams at Nokia who appear to be executing in any of these areas at the level that would be necessary to dominate in them. And they would need to dominate in two or three to stop hemorrhaging customers.

I think they're toast.

<comment><USER27> Nokia already produces some of the best phone hardware there is. If they got Android onto it, I'd upgrade in a heartbeat.

They also know how to differentiate without creating fragmentation. Most Android products suffer because of fragmentation - different OS versions, different hardware, etc. Nokia should know to create a core platform or 2 (standard screen size, hopefully upgrade support), and then make money on marketing prettier models to the people who'll buy them.

It's obvious that they need Android, maybe with some "value added" features tacked on (but not in a tacky way).

OK, crappy feature phones may be "good enough", but mobile phones has always been something of a fashion business. Nokia is good at this game, they just got blindsided by the iPhone and Android.

<comment><USER28> Nokia could create a fairly vanilla Android phone with Ubuntu style LTS (long- term support) for upcoming Android releases. Buying one of these Nokiandroids, you could be sure to be able to run Android 5.0 in 2014 before the support dies out. Nokia was synonymous with quality ten years ago and while nowadays anyone can order a truckload of tegra2's and whip up a new Android model out of them, the end-user quality sucks because your new phone will be outdated sooner than you can google the Android version roadmap page. Nokia could show that they deliver what people want and still ride a different wave than the Q1/2011 trendweasels.

<comment><USER27> Exactly. 10 years ago, anyone could make a dumbphone. They all just made phone calls, and sent texts, kept memos, and had some terrible Java game system. Nokia came to the top because they offered quality dumbphones, not because they offered a completely different experience.

Now there's iPhones (which Nokia can't really do anything about), and Android phones (which Nokia can do better than anyone, if they really try), Windows Mobile (maybe) and burning platforms like Symbian (despite Qt rocking, or so I'm told).

</comment></comment></comment></comment><comment><USER29> I think Nokia have repeatedly been making really dumb decisions about both their marketing and implementation.

Some examples include:

* Code-naming their phones obscurely, making it nearly impossible to remember and later buying a phone you like. Compare "Galaxy S" and "iPhone 3G" with "N6310".

* Not bothering to place the phone's name anywhere remotely visible on the phone, so you have to yank the battery out if you want to know your friend's phone model.

* Repeatedly implementing really dumb design decisions without ever fixing them: When calling someone, the "Speaker" button temporarily means "End Call" _in addition_ to the "End Call" button. What possible purpose does this serve? It means you need to bother your eyes and hands with the phone when explicitly need an eyes/hands-free experience!

Many more of Nokia's decisions seem simply stupid. Does anyone see justification for these dumb practices?

<comment><USER30> _Code-naming their phones obscurely, making it nearly impossible to remember and later buying a phone you like. Compare "Galaxy S" and "iPhone 3G" with "N6310"._

Nokia's phone naming strategy was certainly not dumb at the time. They built brand around 'Nokia', not around specific models. You had 'Nokia' phone regardless of the model, similarly as you currently have 'iPhone' regardless of the exact model. (And current iPhone numbering i.e. 2G, 3G, 4 is easy to remember just because there are so few models) It was an integral part of Nokia's strategy that there were many many models to choose from, any single strong model brand could have been hindrance for that strategy.

Now, we can argue that in smartphone era, building strong model brands might be wiser strategy (Galaxy S), but that's another discussion. Nokia's model naming strategy was definitely not stupid in earlier times.

</comment></comment><comment><USER31> Nokia had something good gooing with Maemo on the N900, they should just have pushed on with that. They had a software platform that was competitive with iOS, technology wise. Lighter, smaller and sexier phones with the Maemo software, it would have been awesome.

But instead they decided to start over with Qt and a partnership with Intel.

They ripped all progress out from under them.

</comment><comment><USER32> The idea of a Nokia device running Android is pretty appealing. They've always had good hardware, but Symbian has become a develpment dead-end, and Meego isn't yet here.

<comment><AUTHOR> Android on Nokia hardware is an appealing idea, but given Stephen Elop's Microsoft background I wonder if they won't shift to WP7. Or both.

<comment><USER4> I see two things to make me hope they might not go with WP7. The first is the ecosystem: he correctly points out that the ecosystem is what they're lacking; but WP7 doesn't yet have one to offer. The second is that MS apparently exercises strong control over the design of WP7 phones, which would leave Nokia little room to distinguish themselves.

An Android-based Nokia could come with improvements in the phone features that make it feel like a Nokia, so that existing Nokia customers who are considering jumping ship to the Android of the week will be more comfortable sticking with Nokia.

<comment><USER4> > _The second is that MS apparently exercises strong control over the design > of WP7 phones,_

This is where I went wrong; Elop was able to negotiate an exemption for Nokia.

</comment></comment></comment></comment><comment><USER33> I'm predicting an HP-Palm/Nokia combined effort. HP and Nokia already collaborate, and webOS is the closest Nokia will get to an existing "ecosystem" that they could thrive in. Palm has crappy hardware, and awesome software. Nokia has excellent hardware, but crappy software. Both of them are getting slammed by Apple/Android. The solution is obvious.

Also, Nokia's work on Meego would transition well to webOS, since they are both linux based.

<comment><USER34> Nokia should have bought Palm when they had the chance. The former has solid hardware and crappy software, the latter an inverse problem. It would have been a perfect match.

</comment></comment><comment><USER35> Hopefully they're able to restore competitiveness, but I hope they don't do it by simply adopting WP7 or Android. I'd really like to see them make something like MeeGo viable. IMO, the mobile space could use an open ecosystem without the Google tie-in.

</comment><comment><USER36> I think they might be looking at Android rather than WinMo7 (ok, maybe I'm just being hopeful...)

The memo repeatedly mentions innovation and market leadership.

With WinMo7 locked down as tightly as it is it is very difficult for a company to be innovative in that market.

OTOH, Android already has quite a diverse ecosystem, and would allow Nokia the opportunity to do it's own thing while still supporting an active developer community.

If Nokia was interested in WinMo7, why would they invest heavily in a Silicon Valley Engineering office (as opposed to a Seattle office)?

Finally, there is already a (very active, community) port of Qt to Android (<http://code.google.com/p/android-lighthouse/>). If Nokia got behind that it would give them a roadmap that would avoid alienating app developers who were hoping to support MeeGo.

</comment><comment><USER37> IMHO, this does nothing else than hurt morale. It's not that the Nokia engineers were so stupid as to not know where their platform stands. This memo only contains lamentations over lamentations, with only a small, general call to action towards the end: "We are working on a path forward -- a path to rebuild our market leadership. When we share the new strategy on February 11, it will be a huge effort to transform our company. "

The way I see these types of memos work is like this: spend the first part of it describing the problem, and the second part should include the suggested solutions. I know a former boss of mine who , if I didn't do that in my "lamentation" emails, i.e. not suggest solutions, would have smashed my head against the nearest desk.

</comment><comment><USER38> Nokia is standing where Nintendo once stood: struggling to hold market share against powerful juggernauts, and in dire need of a bold product that eschews conventional wisdom, challenges consumer's expectations, and tickles developers' imaginations.

The problem is that Apple already did that recently. The iPhone was Apple's Wii, and now it seems incredibly difficult for Nokia to innovate that much that quickly without creating something the world might not be ready for, like the N-Gage.

I hope they pull it off though. Respect for the candor in the memo.

<comment><USER39> I love the analogy. They were great, but they need to redefine the platform and what it means to be a smartphone again.

</comment></comment><comment><USER40> Ignoring the problems with WP7, if Nokia were to produce phones with other 'external' OSes why would they stick with just one?

No one criticizes Samsung and they are pretty much a mobile-OS whore: SHP, Bada, WP7, Symbian (albeit a year or so ago), Android, Limo, etc.

N.B. Regarding SHP: I can't remember the name properly but this was the old/existing Samsung feature phone platform, it probably has got rolled into Bada, although Bada has two configurations (with and w/o the Linux kernel).

<comment><USER41> IMO, that's because Samsung doesn't have a clue and would rather hedge their bets. Most people I know who has a Samsung Galaxy, Captivate, etc have complained endlessly about the wait for updates.

Samsung's business is in selling phones, not developing a software platform and therein lies the problem. They make their bread and butter on planned obsolescence and in the process screw over their customers.

<comment><USER40> But this points out a potential weakness with the model of taking someone else's OS and slapping it in your device.

Once the operators (typically) have added their crap on top it leaves you little margin to extract extra cash until you get someone to buy another device.

<comment><USER42> Seems to work alright for Apple - even though they're doing gangbusters on App sales, it seems the majority of iPhone's profitability comes from hardware sales themselves, and this is without any real shades of planned obsolescence.

Nokia is renowned for their hardware build quality - well in advance of LG, Moto, or Samsung. I think the market has spoken that they want the full experience - solid software, beautiful hardware, and impeccable integration of the two. Samsung IMHO has fumbled that ball up until now, producing cheap-y hardware coupled with lazy software integration. There's a _lot_ of room for someone who knows what they're doing with Android to come and eat their lunch.

<comment><USER40> Except Apple is a bad example as it makes it's own OS and own the end to end user experience with out a dependency on a 3rd party?

</comment></comment></comment></comment></comment><comment><USER43> A helpful tip for those arriving late: Skip the entire article and read the email directly.

The article is longer than the mail, says less, and says it less eloquently.

</comment><comment><USER44> This is exactly where Steve Jobs found himself in 1997. He stood by and did what he wanted to [or may be not yet]. Hope Elop does it as well.

<comment><USER45> Unfortunately for Elop, there's only one Steve Jobs.

<comment><USER46> There can only be one hero?

<comment><USER47> There can only be one!

</comment></comment></comment></comment><comment><USER48> A good memo and he's certainly correct about the phone market. I hope that Trolltech/Qt makes out OK.

</comment><comment><USER49> In case anyone is curious about the full story behind Mike Williams and the "burning platform", watch the following video. You won't be disappointed.

<http://www.youtube.com/watch?v=83EwglrnvlU>

edit: part 1 for those interested

<http://www.youtube.com/watch?v=XgkZtklS6xE>

<comment><USER49> downvote? not sure why as i was only trying to provide context. :/

</comment></comment><comment><USER50> idea for how to create value in your brand when you're "just another android phone".

1\. create a really awesome skin like HTC has.

2\. create a suite of really awesome apps and release them on the apps market, but give them free to users of your specific phone.

<comment><USER51> 3\. Create some of the best hardware out there, as Nokia does.

</comment></comment><comment><USER52> I thought that this was the most interesting part of the article:

 _and that Elop would start looking to Nokia's new Silicon Valley campus as its center of gravity, with execs and senior management expected to start spending more time outside Finland._

That's quite an endorsement of Silicon Valley as a tech hub...

<comment><USER53> And also the part of the rumors that makes the least sense. Hack through the middle management and bureaucracy with a chainsaw, cut off all the incredibly inefficient contractors, clean all the dead wood from R&D, kill one or both of the in-house operating systems, give up on building services and just start preloading every phone with Bing services for big money, etc. One might not agree with those actions, but at least one could plausibly argue that they'd be beneficial to the future of the company.

But how exactly is moving the heart of the company into Sunnyvale going to help? Nokia isn't exactly in the position to compete for the best people in those horribly over-fished waters, especially soon after a round of brutal layoffs. Are the dregs of Silicon Valley really going to be that much better than the talent elsewhere? Does the world even need one more company centered around that echo chamber?

<comment><USER54> I agree -- I think the best thing Nokia could do is probably to relocate somewhere more central within Europe (Berlin? London?) and become the strongest European mobile phone option, vs. trying to compete for talent in SFBA. Arguably they could also try NYC or another major city with lots of development expertise but no strong mobile company.

</comment></comment></comment><comment><USER55> That's really interesting read, but doesn't tell anything about specifics. I'm not really sure what they will announce on Friday. As we can see however, it's about ecosystems, not about the OS.

1\. Qt is really valuable asset, they are keeping it. Actually they are keeping everything they have now.

2\. Joining WP7 or Android as an OEM would cut Nokia out of their ecosystems, not going to happen.

3\. Adopting WP7 or Android as is would require Nokia to cut back some custom hardware features and make differentiation harder.

My best guess is WP7 with Qt allowing Nokia's services and apps on those phones. This would be additional to Symbian and MeeGo devices. However, I'm pretty sure they are starting to ramp Symbian down.

<comment><USER4> > _My best guess is WP7 with Qt allowing Nokia's services and apps on those > phones. This would be additional to Symbian and MeeGo devices._

If they adopt any third-party OS, I can't see them keeping MeeGo. That'd be stupid; it'd leave them having to build a MeeGo ecosystem instead of just taking advantage of the one they join.

And I don't see Microsoft allowing Qt on WP7; it'd undermine their whole .Net- based story.

<comment><USER55> On the other hand, I'd believe Microsoft would want Nokia to "catalyse" their ecosystem, because of the lacking success of WP7. The ecosystem of WP7 is now very weak, and not much of an asset for Nokia, except MS services like Bing. But, Nokia doesn't want to give up Qt apps and their own services.

</comment></comment></comment><comment><USER56> I would work for that man.

<comment><USER57> I used to (at Macromedia). He's a great guy. Very approachable and down to earth, but certainly not afraid to make the hard calls as you see here.

I sometimes wonder where Microsoft might be if he'd replaced Balmer, but it's great to see him take on Nokia. Talk about a tough gig!

</comment></comment><comment><USER58> Not really impressed, yet. And here is why:

Zero points for coming out: Mr Elop was brought in by the board exactly with the goal of rescuing Nokia in mind. Looking from that angle the memo is a bit overdue.

Zero points for opening the letter with a metaphor - this is the way someone steering a major technologic corporation is expected to convey the direction - by projecting a vision.

Negative ten points for picking wrong metaphor. It broke down immediately. See for yourself: should Mr Elop's best employees take his advice literally and jump the burning platform? Followed with a change in behaviour meaning never again joining a severely fragmented bureaucracy ridden company? What was the lesson learned by the oil rig worker? What could he have done differently in the situation when he woke up on a burning platform in a middle of a sea?

I'd award one point for openly enumerating the challenges. But these are the symptoms of Nokia demise, he hasn't dug deep enough, the list is known at this point to every man and his dog.

Negative ten for the actual lack of a credible vision at this point. Let's wait till the strategy comes out.

</comment><comment><USER59> wow, that is one way to motivate the troops. The lack of mentioning of WP7 at all and the re-emphasis of Andriod as a competitor makes me think it's unlikely they will be running Andriod any time soon.

<comment><USER60> I don't follow your logic.

Windows 7 _isn't_ much of a competitor. It had a smaller debut than Android and iPhone, by a large amount, and is being outsold by both so the gap is widening. If I were Nokia, I wouldn't be worrying about fellow also-rans in the industry, like Microsoft. I'd be worried about the products that were eating my lunch, and I'd let Microsoft figure out how to protect their own lunch.

If Nokia chooses Windows for their next generation, I'd wager they'll keep dropping like a rock. How could they generate any excitement over a _Windows_ phone? Nobody likes Windows phones, even people who like Windows on the desktop.

<comment><USER61> Remember that Microsoft has a trick up its sleeve: Midori. It quietly incubated the Singularity research OS, a pure .NET operating system, a couple of years ago and is turning it into a commercial product. The advantages of the OS are increased security and massive parallelism, both due to the fact that .NET code is inherently memory safe.

My hypothesis is that Windows Phone 7 is a stop-gap measure introduced to build their brand and app portfolio while they're working on the 'real' thing. Note that WP7 apps are .NET apps, so transition to a pure .NET kernel would be relatively easy. Of course I have nothing but a hunch and some rumours, to base this on, but I find it highly unlikely that MS is just going to sit there while Google is building the dominant platform for internet usage (note that in some countries, like India, smart phones are now the most popular device for accessing the internet).

Remember that although us geeks are picky about the OS our phone runs, a the large majority of phone buyers really don't give a crap and switch easily. My girlfriend goes into a store and just picks out something shiny, possibly looking for specific features like a keyboard to type out email on. And app portfolio isn't just a matter of quantity. About 10% of the apps on any given platform probably satisfy 90% of a user's needs. Microsoft really just needs to have that 10% to be a compelling alternative, and they have the cash to simply write it themselves or pay people to write it for them.

So all in all, I don't think that Microsoft is out of the game just yet. On the contrary, they're just getting started, and this deal with Nokia is going to be very valuable for both companies.

<comment><USER60> "The advantages of the OS are increased security and massive parallelism, both due to the fact that .NET code is inherently memory safe."

So, what? Everything in userspace on an Android phone is Java and runs in the JVM. That's not really a feature users care about, but even if it were, the leading OS already has it.

You then go on to say:

"Remember that although us geeks are picky about the OS our phone runs, a the large majority of phone buyers really don't give a crap"

Which I agree with. Which is why there's _no_ reason for someone to switch to a Windows phone, even if, on some technical level a .Net phone were lovelier than the competition.

Just because the next magical version of Windows is based on a smarter core, doesn't mean any normal user will have a reason to switch.

"On the contrary, they're just getting started, and this deal with Nokia is going to be very valuable for both companies."

You still haven't answered why Nokia would sign on with another sinking ship rather than simply choosing to make great devices for the leading (free) OS.

Of course, because the new CEO is coming from Microsoft, he may very well have loyalties that simply don't make sense for his new company...and if that's the case, he'll merrily drive the company into further insignificance while drawing a nice fat paycheck, and making his friends at Microsoft happy.

<comment><USER61> "Just because the next magical version of Windows is based on a smarter core, doesn't mean any normal user will have a reason to switch."

I agree, but chip makers, handset makers, and ultimately carriers do care. Apple, Sony, Microsoft, and Nintendo sure care a great deal about people jailbreaking their devices.

My point was not that a new kernel would directly persuade potential buyers, but I do think it is needed to support the features that users have come to expect from modern phones (i.e. multitasking). In my opinion WP7 is just not up to the task, so if they want to compete, they need to step up their game in the OS department.

"You still haven't answered why Nokia would sign on with another sinking ship rather than simply choosing to make great devices for the leading (free) OS."

I don't know, maybe MS is giving them a truckload of money? Nokia has a large software development group, so maybe the deal is that Nokia will develop apps for WP7? Maybe they just want to differentiate from the Android horde? I really don't know why they would go with MS, if indeed they choose to do so, but all I'm saying is that I don't think Windows Phone is a 'sinking ship'.

</comment></comment></comment></comment></comment><comment><USER45> The only way forward is to embrace WP7 and become the WP7 phone. Build apps and an ecosystem around that. Hell, get Microsoft to acquire Nokia and make WP7 exclusive. WP7 is a much better platform than Android anyway (in a couple of OS updates at least).

There is no way that Nokia will ever win using Symbian/MeeGo or Android.

If they stay the course then Nokia's dead and will never recover.

<comment><USER41> I agree with everything you said except I think there's a 0% chance of Microsoft buying Nokia, it doesn't fit their business model. Companies would not be as willing to license WP7 if MSFT were competing directly with them and able to undercut their competitor's prices.

<comment><USER45> The point is that Microsoft would no longer need to license WP7 (and quite frankly, I doubt they really care about those licensing fees when ecosystem market share is a far bigger revenue source).

Both companies are at a point where they're about to enter irrelevance in the mobile space (Nokia actually entered irrelevance as soon as the iPhone launched, but it took them a while to figure that out due to pride and thinking all that matters is how many widgets you ship -- they're about to hit the bottom of the abyss).

The problem Microsoft has is that all the existing licensees don't care at all about their platform. Samsung, HTC and LG all have their hands in multiple pies, not willing to commit to any platform because they don't care about who wins, as long as they make money.

They need someone to focus exclusively on WP7, delivering the best integrated experience the platform can offer. Nokia's not going to go exclusive unless Microsoft does too.

There are issues on both sides though:

* Nokia used to build great hardware. They need to start doing that again to convince Microsoft it's worth acquiring.

* Microsoft needs to recognize that WP7 isn't going to go anywhere unless something major changes.

The upcoming announcement might be a precursor to the above scenario.

</comment></comment></comment><comment><USER62> If they don't want to alienate existing developers, a logical choice would be official Qt support for Android. Meego could also be tweaked to run Android, as it is already being done by others, see for example <http://www.aavamobile.com/>

<comment><USER63> They could run Myriad's Alien Dalvik engine. I also agree that official QT support for android would be great as well. I think 2 open source mobile OS's rising at the top of the mobile market would be a great thing for wold. I think Apple will provide enough contrast with their closed iOS platform to balance things out.

</comment></comment><comment><USER64> A strong Nokia is good for smart phones. I hope Elop is smart and doesn't get bogged down in the tablet fight. Nokia needs to focus on doing smart phones well. Plenty of market there as 6 billion people will be buyers.

</comment><comment><USER65> I'm very curious how this will effect QT...

</comment><comment><USER66> It's worth noting in this context that Nokia has reinvented itself before; for instance, the company started in 1865 as a pulp mill and paper manufacturer. They've pivoted a few times in the years since.

</comment><comment><USER67> This is a great PR campaign from Nokia. :)

</comment><comment><USER68> There are at least one reputable source that claims it is false: [http://communities-dominate.blogs.com/brands/2011/02/the- nok...](http://communities-dominate.blogs.com/brands/2011/02/the-nokia-ceo- burning-platform-memo-at-engagdget-doesnt-ring-true-to-my-ears.html)

</comment><comment><USER69> Is it obvious to everyone that he is preparing Nokia for a transition to Windows?

</comment><comment><USER70> This is interesting, but wouldn't a move to say Android or Windows make them "just another Android or Windows phone". I understand the reasoning behind this but it seems to me that they would also lose something here.

</comment><comment><USER71> Nokia should ally with Facebook to make the Facebook phone. That is the only thing I can think of that would put them back in the game.

The downside is that MS probably has the inside track on that with Windows Phone 7/8.

</comment><comment><USER72> <http://twitter.com/#!/vicgundotra/status/35182523650801664>

Looks like Nokia is going with Windows Phone 7

</comment><comment><USER73> This is the point where someone argues that Nokia is doing just fine, since they still have 110% market share in Tanzania...

</comment><comment><USER74> compare and contrast with this statement from the company, several months ago:

<http://news.ycombinator.com/item?id=1481354>

this new memo makes me think better of them. if Nokia can get out of the new CEO's way and let him execute, then maybe they can turn it around.

</comment><comment><USER75> Is anybody else thinking "Manchurian candidate"? I mean if he decides to go with Windows phone 7.

</comment><comment><USER76> absolutely agree</comment>


Convore (YC W11) Launches and Makes Web Based Group Chat Easy and Fun. - <AUTHOR> http://thenextweb.com/2011/02/09/ycombinators-convore-launches-easy-and-fun-web-based-group-chat/

<comment><USER2> Most of the Convore commentary is in this thread: <http://news.ycombinator.com/item?id=2198517>

</comment><comment><USER3> Anyone else getting sick of the hyperbole "ever?" That said, Convore looks pretty sweet.

<comment><USER4> Was absolutely intended to be tongue in cheek

</comment></comment><comment><USER5> Same comment I left on the TC story: Congrats to Convore on the launch, I've been using it almost since its inception and it's become a staple of my communication platforms.</comment>


11 month to accept a Qt contribution patch - <AUTHOR> https://codereview.qt-project.org/#change,43594

<comment><USER2> This headline is ridiculous. It's not a case of "Here is my patch" and eleven months later "okay it's accepted" as the headline implies.

</comment><comment><USER3> 11 months is almost a year.. Tingles my OCD.

The committer:

"Could you please wait until 23 December to merge this patch so we can say it took 1 year to accept this translation update? i don't like to say 11 month, and i think we can wait an other month, we already waited 11 ;)"</comment>


Why Use Make? (2013) - <AUTHOR> http://bost.ocks.org/mike/make/ <comment><USER2> Make is an absolutely wonderful, wonderful tool.

Most of the common criticisms of Make are actually criticisms of autoconf, which I agree is a hideous tool. (On the other hand, autoconf is a tool intended to address a hideous problem, so perhaps that's inevitable).

A lot of the more recent build tools I see are largely reinventions of Make. Make is very widely supported (most basic projects can make do[0] with portable Makefiles, though GNU Make is also available for most systems), and its syntax is actually very easy to grasp and manipulate[1].

[0] no pun intended

[1] Most projects only need a very small subset of what Make has to offer, anyway, and that can be learned in a matter of minutes.

<comment><USER3> Make is a great tool for the intended uses. Unfortunately, many uses of Make- like tools also require the unintended uses; my favorite example is the auto- dependencies, which is required by most compilation tasks and still tedious to get it right [1]. It also (mostly) lacks modern programmable interfaces, which led to Makefiles laden with hacks and mumbo-jumbos. At least for the compilation tasks, I see Make is clearly being outdated.

[1] Something like [http://mad-scientist.net/make/autodep.html](http://mad- scientist.net/make/autodep.html)

<comment><USER4> The auto-dependency problem is a perfect example of how there is room for improvement in make-land. When something that basically everyone wants to do takes a long web page to describe a complicated method that sort of works, that is a compelling indicator that there must be a better way.

Incidentally, I am working on a make-replacement that is intended to address this and similar needs. It's still in very early stages, but I think I'm onto something.

The idea is to write a very low-level tool that leaves out most of Make's higher-level abstractions. In my tool there are no recipes, no implicit rules, no variables or variable substitutions, no conditionals, etc. The input to my tool is just the precise specifications of the commands you need to run, their inputs and outputs (so a precise dependency graph can be calculated), and with everything fully-expanded already.

The idea, then, is that whatever higher-level abstractions you want (if any) you build into a higher-level tool. The higher-level tool just spits out a file describing the list of tasks. Then the higher-level tool can worry about the higher-level structure, policy, configuration, etc. of your project. So instead of writing things like implicit rules in Makefiles, you just write some code that explicitly generates tasks.

For example, with Make, you might write an implicit rule like this:

         %.o : %.c
                 $(CC) -c $(CFLAGS) $(CPPFLAGS) $< -o $@

Then Make magically decides which output files match this implicit rule. My idea is that, instead of this, explicitly apply your rules to your inputs. Your build system could instead be a Ruby/Python/etc. script that looks something like this:

        for c_file, o_file in files:
          tasks.append(Task(
            target=o_file,
            source=c_file,
            command="gcc -c %s -o %s", c_file, o_file
          ))

        print(tasks)

I think this is much more convenient than having to program in Make and learn its quirky abstractions.

I have an elegant solution for the auto-dependency problem (unproven, but I think it's promising). The idea is that your dependency-calculating tasks are still just tasks, but the tool knows how to integrate the calculated dependencies back into the overall dependency graph. These dependency- generating tasks depend on the files they are generating dependencies for, so it is all part of the unified dependency graph.

If you're interested, star my project and follow my blog (where I will make any announcements about it):

[https://github.com/haberman/taskforce](https://github.com/haberman/taskforce)

[http://blog.reverberate.org/](http://blog.reverberate.org/)

<comment><USER5> Are you familiar with Ninja? (which is absolutely excellent IMHO) [http://martine.github.io/ninja/](http://martine.github.io/ninja/)

> Ninja is a small build system with a focus on speed. It differs from other > build systems in two major respects: it is designed to have its input files > generated by a higher-level build system, and it is designed to run builds > as fast as possible.

Obligatory: [https://xkcd.com/927/](https://xkcd.com/927/)

<comment><USER6> I recently played a bit with ninja on a tiny c project -- as I was already using cmake, the transition was seamless, and even for such a very tiny project the speedup was tangible (but absolutely not relevant in any way, everything was building fast enough :).

Also played a bit with tup, and it's quite nice too.

</comment></comment></comment></comment></comment><comment><USER7> I write my own automation/build tools in Python

Envoy pynotify and fnmatch pretty much do the heavy lifting.

I do it this way because

        Since I know Python no extra syntax knowledge is required

        Python is going to be readable to me in 6 months when I've
        forgotten the syntax of whatever build tool I just used

        *All* my machines desktop and servers already have Python
        installed

        *It's fast, merging 20-30 largish text files takes around
        10-15milliseconds

        * It's very very flexible (it's Python)

I used make extensively when I was at Uni and quite frankly if I never have to touch it again I would be a happy bunny.

It's an incredibly powerful and clever tool hiding behind an interface (that second to Git) is the worst I've ever had to use.

EDIT: I've actually been toying with the idea of writing a python library to simplify things as lots of the code I end up writing is very similar across projects, it's been one of my "think about in shower" projects for quite a while.

<comment><USER8> > a python library to simplify things

That's basically scons. Give it a try, I've been using it for years to manage a fairly complex, unusual build process with minimal effort (less than 200 lines of Python code).

[http://www.scons.org/](http://www.scons.org/)

<comment><USER7> Thanks for the link :).

Scons is awesome but for what I use Python for (minification of web assets, automatically running image optimisations) it's taking a sledgehammer to a walnut.

<comment><USER8> Fair enough, though I've found scons is extremely flexible and lightweight, in the sense that it's not very insistent about imposing a certain style or process on you. Unlike the vast majority of other build tools.

</comment></comment></comment></comment><comment><USER9> Make is a very under-appreciated tool. I think it gets a bad rap because many people's only exposure to it is in large projects (where Make has some issues) or when coupled with autotools (which is rather ugly).

If that has been your only exposure to Make, you should take another look at it, and consider using it for your next small- or medium-sized project.

</comment><comment><USER10> If you read down the comment threads here, you'll notice something. Many many folks get frustrated with some aspect of Make, and then turn around and say "I can do better myself in [language]". And then they go off and do 30% of Make in their favorite idiom. Sorry, but as an old fart, these all read as "Wah, make is haaard, and inconvenient".

This isn't to say that I think Make hung the moon in radiant perfection, but I haven't seen any tool that has a clearly superior set of compromises and tradeoffs. Gorgeous example: automatic dependency generation. Does anyone really think the identical dep generation codebase will work on 20 year old C and node? It's not hard to glom whatever dependency mapping you want into your make workflow and drop it into separate included makefiles.

It feels easier to write your own. But what that really leads to is re- learning all the shit the make maintainers have learned in the last (look it up.. DAMN.) nearly 40 years.

Or maybe _not_ learning it, and duplicating mistakes which have been solved for decades.

<comment><USER11> The reason for all these alternate build tools isn't that Make is hard. The problem is that it's too generic and low-level. It comes with a very limited set of built in rules, after that you're on your own.

For example: If I'm working on a C++ project then I'd like my build tool to be aware of concepts like header files, shared libraries, include paths, compiler options. For me that tool is CMake.

Can I do that in Make? I'm sure I could, but I'd end up with the same problem you're complaining about. I'd essentially be writing my own build system, just implemented in Make. Life is too short for that.

<comment><USER5> Yes: CMake is a little weird, but it's less bad than all the other options for cross-platform projects, and CMake+Ninja is wonderful. (that said, I do hope something Lua-based like Premake catches on).

</comment></comment></comment><comment><USER12> > The ugly side of Make is its syntax and complexity; the full manual is a > whopping 183 pages. Fortunately, you can ignore most of this

I cannot take this seriously.

I like the concept of make but it doesn't make up for its own warts. Unfortunately, there is no single build tool I can blindly recommend to people without being extremely familiar with their project and how it builds. No solid and lightweight build tool that pleases more or less everyone without having 183 pages worth of manual and a repugnant syntax.

CMake/Lua gives me hope but we're not quite there yet. Make it pretty decent for small projects though... I see it as the HTTP of build tools, though. It has serious issues but when tools come up they are built on top of make because it's ubiquitous.

<comment><USER13> djb redo captures the concept of Make but is a lot simpler and no extra syntax (just uses shell)

</comment></comment><comment><USER14> POSIX make really does make auto dependencies hard, but GNU make actually solves this fairly cleanly by adding an include directive. As long as you have a script or program to process a file and spit out its dependencies in make style (e.g., GCC does this for C and C++ with its -M flags), you can just include the outputs of that process and make will do the rest.

For example, here's how I handle a simple C project.

        CSRC := [list .c files here]
        DEPS := $(CSRC:.c=.d)

        [standard statements for building go here]

        %.d: %.c
                gcc -MM -MF $@ $<

        -include $(DEPS)

Poof. Automatic dependency handling. You can see how any sort of dependency that can be detected by some sort of preprocessor can be plugged in here.

<comment><USER15> Some problems I have encountered with this approach:

1\. dash before include. It will cause make to ignore any errors when generating the .d files. It can be pretty difficult to figure out what went wrong. Removing the dash will show a (harmless) error message for every .d file generated, which is pretty annoying.

2\. At one time a.c includes b.h and you run make. a.d is created with "a.o: a.c b.h". If at this point you add to b.h an include to c.h, the new dependency of a.o on c.h will never be updated in a.d unless you manually delete it. This can cause some pretty nasty bugs! This can be solved by adding

        -MT $*.o -MT $*.d

to the gcc command line, which causes the dep file to regenerate when one of the dependencies changes (in fact the make manual suggests a similar solution using sed). However this creates another problem: if you remove a header a.h included by a.c (and the #include line to it), a.d still depends on a.h, so make will fail looking for it until you _manually delete_ a.d (and any other dep file depending on the removed header).

tl;dr: this solution leaves much to be desired, and can be dangerous in some conditions.

</comment></comment><comment><USER16> I completely agree with the sentiment of the article. Makefiles are a form of documentation. However, I no longer use make in new projects and instead use redux [1]: my implementation of djb redo. It manages the dependencies and you write your scripts in shell. Simple, straightforward and easy. No more 'make -B', no more make contortions.

[1] [https://github.com/gyepisam/redux](https://github.com/gyepisam/redux)

<comment><USER17> I thought with make you also write scripts in shell.

<comment><USER16> Yes, you're right. However, in redo, you don't have a Makefile equivalent and, instead, specify the dependencies in the shell script that generates your target. Basically, the configuration language is shell (or any other program that can be invoked from a shell script).

</comment></comment></comment><comment><USER18> This _specific_ problem would be more simply solved with a script, listing the commands. Repeatable, testable and documents the process.

It doesn't require differentiating between identifically rendered tabs and spaces. It doesn't need dependency hand-holding, with explicit _touch_ or checking _Last-Modified_. The simplest script just builds it all from scratch, like _make clean_.

</comment><comment><USER19> If syntax is bad, why not build something with better syntax? Why we sticking with it?

</comment><comment><USER20> I don't quite see the benefit of using make for arbitrary workflows (opposed to building software) over using plain old shell scripts.

But it sure isn't that much more complex nor requires a lot more of your system, so I'd say it's more a matter of preference.

<comment><USER21> Make has more natural built-in dependency management.

To write your workflow purely in shell scripts, you will invariably use lots of tests.

Also note that they are not necessarily mutually exclusive. You can write Makefiles that call shell scripts (and shell scripts that call make)

<comment><USER22> I use a ton of inline shell in make for data munging. I often put

SHELL=/bin/bash

at the top of the Makefile when I use bashisms to construct complex pipelines.

And once, in a fit of mad genius, I made a particularly complex and useful Makefile executable by putting #!/usr/bin/make -f at the top. (It was a bad idea, obviously, and I won't be doing that again.)

For large file based datasets, the shell is just a REPL.

</comment></comment></comment><comment><USER23> I never understood why make has to use tabs. Even if that had sense in 1977, why it remained so until now. Why not let any whitespace, even more spaces, have the same effect of starting the command line.

</comment><comment><USER24> Make wouldnt be the first build tool i would try. I would go with something like gradle first. Eventhough, in Mike's case make looks like a good match for his requirements.

<comment><USER25> Gradle looks to me like it's full of good intentions, of exactly the sort that in a few years will have led them straight to hell, at which point someone will reinvent ant or make with different syntax and we'll be back where we started.

I worked on a proprietary build system remarkably similar to gradle for many years. The cleverer a build system tries to be the more likely it will become a self sustaining beast that consumes ever more of your time and destroys productivity. They look great with relatively simple systems, but a few years into production with multiple deployment target configurations and you will want to murder people. Build systems should be stupid, simple, and trivially predictable.

<comment><USER26> It's been going for five years so far, and has yet to get noticeably near the infernal realms.

I know Gradle fairly well, and i wouldn't describe it as particularly clever. The basic ideas in it are quite simple (and actually fairly similar to make!). Most of the complexity comes from specific build tasks for specific purposes, which doesn't complicate the core.

</comment></comment></comment><comment><USER27> I often convert makefiles to shell script (bash) when I outgrow my knowledge of make. However, it's where I always start, and the makefile never goes away, just the complex pieces get rewritten in bash!

</comment><comment><USER28> I am glad, that make exists. Guess what would happen, if every open source tool would use its own build environment. Open Source Software would be much more difficult to build from sources (sometimes, I can't do without).

So it is rather straight forward. Type make, sometimes autoconf and most of the time you are done.

Also in my own projects I prefer make to many other build tools. In software development, command line still rules (if you want to be really productive)!

</comment><comment><USER29> I've used make as the basis for a system that works out the dependencies for nightly batch processing in an ERP system and coordinates the execution of the required processes across multiple applications that make up the system.

There's some shell script to glue the pieces together, and a Python script for invoking processes within the ERP applications, but make is the secret sauce that figures out what order to run everything in.

</comment><comment><USER30> [https://github.com/ndmitchell/shake](https://github.com/ndmitchell/shake) Shake is an awesome alternative to Make written in Haskell. It fixes a lot of the weird dependency tracking issues Make has ("my build broke and I don't know why!" "did you make clean?")

</comment><comment><USER31> Surprised that there is no single comment here about other options like ant and gradle. I personally hate anything where tab has a different meaning from 4 spaces, but maybe it's just me. Anyway, my personal choice for any kind of automation would not involve make if I can use the tools I mentioned.

</comment><comment><USER32> I've been using ansible for complex build environment setup. Inline documentation. Can Factor in software dependencies or environmental setup as required.

It's working pretty well so far. It wasn't an intensional thing. I had a fairly complex stack for a particular project that I needed to share.

<comment><USER33> I was looking at Ansible in the context of this thread:

[https://news.ycombinator.com/item?id=7487202](https://news.ycombinator.com/item?id=7487202)

exactly because I like the idea of capturing the setup (compared to a more haphazard approach). My initial reaction was that for the computer setup use case, it did too much to hide away complexity.

I guess I don't have a deeper point, but I wonder if it is overkill for capturing simple workflow like is discussed here.

</comment></comment><comment><USER34> You might be interested in Drake, a kind of 'make for data'.

[http://blog.factual.com/introducing-drake-a-kind-of-make- for...](http://blog.factual.com/introducing-drake-a-kind-of-make-for-data)

</comment><comment><USER35> I used to do this until I found drake. Drake is the truth and the light. Use it.

</comment><comment><USER36> Make uses disk I/O, which is really slow, and for complex projects become difficult to maintain. Also, why not use a proper programming language to define the build process? Well, a modern tool like Gulp[1] does that. It's streaming/asynchronous and scripts are written in JavaScript. I don't see why one would prefer Make over it.

1\. [https://github.com/gulpjs/gulp](https://github.com/gulpjs/gulp)

<comment><USER37> There are many complex projects that use Make to build source code. Grab just about any software release tarball and there will almost certainly be a Makefile in it.

This is yet another example of the JavaScript community being completely ignorant of what came before them.

<comment><USER38> I wish I could use make to build my JavaScript code, but I need it to also work on windows (easily).

If there was a version of make I could point to that would work easily on windows, preferably as a non-global variable, I would use that, until then I probably will have to use something else, through likely just bash scripting with pipes (which does work in windows).

<comment><USER33> What do you mean when you say "as a non global variable"?

The one here:

[http://gnuwin32.sourceforge.net/packages/make.htm](http://gnuwin32.sourceforge.net/packages/make.htm)

works fine if you do set path= and then call it using a full path into Program Files (I've just checked to make sure, but I used whatever version I had installed, not sure it's the latest one there).</comment></comment></comment></comment>


Andy Hertzfeld tells about the team behind Google+ Circles - <AUTHOR> https://plus.google.com/117840649766034848455/posts/FddaP6jeCqp

<comment><USER2> You've got to hand it to him for being so classy and humble about it. It's much easier to be quiet and take the praise. Only when someone is modest enough and truly believes that others deserve credit does he/she actually advocate for other people on his/her team.

<comment><USER3> Humble? Look at the first two sentences after the introduction: "I am indeed the main individual behind the interaction design and implementation of the circle editor. I conceived, designed and implemented a compelling prototype for it almost single-handedly". And then, the first sentence of the following paragraph "Steven Levy's excellent Wired article got the story right - I wrote the circle editor and then recently widened my focus to the overall Google Plus user experience."

In my opinion, in order for me to believe Andy is actually humble, the last sentence, "Suffice it to say that Google Plus is the creation of large, talented team that I'm proud to be a part of", should have been the first one.

<comment> brown9-2 I think you are missing what he is actually doing - he states that the part he is wholly responsible for is just one tiny part of the whole, and that all the other credit given to whom is wrong. His first statement is meant to be a bit ironic.

</comment></comment></comment><comment><USER4> I was impressed with the fact that this post was on plus. It's like Twitter, only with no size constraint and with discussions right on the post. I'm excited to see how its usage will pan out.

<comment><USER5> Or exactly like LiveJournal circa 2002.

<comment><USER6> Except without nested/threaded discussions. I don't know why the social web loves flat comments so much.

<comment><USER7> Flat comments ensure a narrative thread.

<comment><USER8> Like Twitter encourages? Or maybe you're referring to YouTube comments.

<comment><USER7> Okay, Twitter is more like a disassociated bag of nodes in a partially connected non-directional graph where half the edges don't connect to the node they're intended to connect to.

YouTube is a pack of raving howler monkeys with the occasional howler monkey researcher at the periphery. And, in fact, YouTube used to have threads, but they were still threads full of howler monkeys.

I'm talking more like your classic bulletin boards producing high quality content, like MetaFilter, Something Awful, and the like.

<comment><USER8> We agree on the sites, but I don't see what the conversation being flat has to do with it. Reddit is famous for the AMA threads, those are threaded.

<comment><USER7> Yeah, but try reading an AMA after it's been finished. It is really hard to find everything from the Askee.

I'm not intrinsically opposed to threads, but I'm not sure they're super beneficial outside of technical contexts or in an environment where people are expected to break a larger conversation off into it's own little set of discussions to keep the high level conversation easy to understand.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> You've got Andy's name wrong, twice, in the headline. It's "Hertzfeld", with a t, and no i.

<comment><AUTHOR> Doh. Thanks for pointing it out, maybe I learn and get it right next time. It seems that I can't edit the title to fix it.

</comment></comment><comment><USER10> Anyone interested in technology who hasn't read the stories on his site are missing out: <http://www.folklore.org>

</comment><comment><USER11> It was nice of him to announce this using a service he single-handedly built in a weekend

<comment><USER12> Subtle trolling always works best

</comment></comment><comment><USER13> " I conceived, designed and implemented a compelling prototype for it almost single-handedly, and then wrote a fair percentage of the production ......but that's pretty much as far as it goes."

That's some modesty!.

<comment><USER14> For only the circles editor. His point is that he had very little to do with the rest of Google+ and nothing to do with the rest of Google's redesigns. He's still taking credit for the significant work he did on Circles, as he should.

</comment></comment><comment><USER15> I thought that the UI was done in GWT, but that was a guess, and I was probably wrong. Anyone know?

<comment><USER5> Whenever a new Google site comes out, everyone always asks this question. I can only assume it is asked by people who only know Java and are terrified of JS (which seems to be GWT's primary audience, despite the framework's other advantages).

If you want to know, just pop open Firebug or Chrome's Inspector and search for the string "__gwt". I don't see it in Google+.

To my knowledge GWT is not actually used that much within Google. Most of the things it solves for developers are solved in other ways within Google anyway, and if you want really low-level control GWT is not the best option.

<comment><USER16> [http://groups.google.com/group/google-web- toolkit/msg/37bf75...](http://groups.google.com/group/google-web- toolkit/msg/37bf75b622b32584)

has a list - just eyeballing it, it seems like about half of the major javascript apps from google are GWT. (the other half would likely be closure)

<comment><USER17> There is an overlap: GWT itself uses closure.

<comment><USER18> That's interesting. I've done my fair share of GWT development, and I didn't know about this, so I tried to find more info.

I've searched through the GWT source code, and I found no mention of the closure library (closure tools / closure compiler). There are obviously some mentions of javascript "closures", but that's all I found.

According to [https://groups.google.com/group/closure-library- discuss/brow...](https://groups.google.com/group/closure-library- discuss/browse_thread/thread/bf3731cee9d8a57c) , no code is shared between GWT and the closure library.

Where does GWT use Closure?</comment></comment></comment></comment></comment>


Want a Tropo.com USB Bottle Opener? - <AUTHOR> http://www.disruptivetelephony.com/2010/11/want-a-tropocom-usb-bottle-opener.html

<comment><USER2> This is pretty cool. For anyone who doesn't know, Voxeo is kind of like the enterprise, super-scale version of something like Twilio but that's just one of their products, VoiceXML. They do a lot more with SIP and IVR. They do some awesome stuff over there, and they have an office here in Orlando, FL. One of their directors comes out to FAMiLab sometimes, and he's really cool and knowledgeable.</comment>


Psychology of Computer Programming: Conquering the Imposter Syndrome - <AUTHOR> https://nthlook.wordpress.com/2014/09/24/psychology-of-computer-programming-conquering-the-imposter-syndrome/ <comment><USER2> What about all of the people who think they know what they are doing but don't?

<comment><USER3> At work we call them npp's (negative producing programers)

You spend so much time fixing their poor code that the project velocity actually slows down. Worst of all, since they "think" they know, they tend to never improve.

</comment></comment><comment><USER4> This is an interesting article. Especially as it reflects some of the unspoken assumptions among programmers.</comment>


Ask HN: Best programming language to learn for expanding my knowledge? - <AUTHOR> Hi to all, I am a Ruby developer who primarly works on the web. I know also Javascript, and just enough PHP to be dangerous.
But I feel that I need to learn a most 'complete' or better, lower level, programming language to improve my arsenal of weapons and to improve the way I think while programming.
I am fascinated about a lot of languages, just to be clear, I am talking about the ivy league, something that is where C++ or Java are. Any advice?
Which is the best choice to improve my skills, and that can help me make the differences where languages like Ruby or Javascript can't? <comment><USER2> The best programming language to learn to expand your knowledge is one that is outside your current knowledge. Java, perhaps, but C++ is further outside your knowledge since it can go more low-level than Java can. Rust might be at the same level as C++, and might be easier to learn.

Or, you could go up - to higher-level instead of lower-level. Lisp or Haskell might be worth your while.

</comment><comment><USER3> If you want Ivy League then Scheme is a good choice

[https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...](https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs)</comment>


Smartphone Rises Fast From Gadget to Necessity - <AUTHOR> http://www.nytimes.com/2009/06/10/technology/10phone.html

<comment><USER2> The spread of those social assumptions may signal a technological crossover that echoes the proliferation of e-mail itself more than a decade ago.</comment>


Books For Learning to Design, The Hard Way - <AUTHOR> http://alexn.org/blog/2011/11/25/4-books-for-learning-to-design-the-hard-way.html

<comment><USER2> The Robin Williams book is great. I used it as a text several years ago for a class I taught. A very good overview.

I was a bit surprised to see the Edwards (Drawing on the right side of the brain) book. Pleasantly surprised. One of the things I've always stressed to my students is that learning to draw is actually learning to _see_. People think the can see things clearly and objectively, but what they are actually doing is _recognizing._ (There is a small motor skill component to drawing, but _seeing_ is by far the most important.)

If you want to communicate visually, you first have to learn to see.

Design theories and formulas will only get you so far.

Those students who learned to do a little sketching improved dramatically.

And yes, it is hard to do. It is a process as deep as you are.

<comment><USER3> It's just not seeing, but also knowing. That's why some art schools have dissection labs where art students learn how human body is structured. And when you know anatomy, you can draw from imagination which is really a lot more valuable skill than copying a person's photo using a grid method :P

<comment><USER2> Drawing synthetically or constructively is a different skill. And learning to draw observationally, that is learning to _see_ , is still a prerequisite.

Knowing anatomy, by the way, doesn't necessarily help you draw. I've had doctors that specialize in anatomy in class and they were terrible at drawing until they learned to see. They could recognize and label the parts, and they could even do a simple 2D schematic type diagram of muscles, but put a real 3D, foreshortened person in front of them and they were just as awkward as anyone else.

<comment><USER3> Well, when you're drawing from a long pose (week or longer), the model is bound to change her/his shapes slightly.. So just drawing what you see is not enough, you have to understand the 3-dimensional structure of the thing you're drawing at least on a basic level.

But also, I agree -- foreshortening is hard until you learn 2-point perspective and can "see" perspective points that you can easily build up the foreshortened feature from.

<comment><USER2> Seeing isn't necessarily a 2D process; and not just because our vision is binocular. Our visual system is very complex. The hardware is, optically, very crappy. Our image processing and integration software is very complex, much more complex than we really are able to understand at this time.

And it behaves almost nothing like a camera. Even mechanically, the optical projection is very different than a camera makes, or what one would get from a linear perspective projection.

There is a projection, but the "image" is actually composed of multiple viewpoints over time. The adjustments an artist must make for small changes in the model's pose is nothing compared to the varying nature of the mental image you actually "see" inside your brain. It is far from static, and is in fact very dynamic.

Which is why that drawing from life is considered much more important than drawing from a photograph when learning to see.

Note that I'm not knocking the study of structure or synthetic processes like linear perspective. They are important tools and aids in perception and image synthesis. But a good drawing, or painting, or photograph for that matter, is not a mere 2D projection of light and dark. It is an encoded record of a multitude of perceptions, or perception artifacts that your brain then interprets, inside it's magic "seeing" box, which then produces a simulacrum of a perceived event or process.

Else making a good drawing or photograph would be an entirely mechanical process that anyone could make by following a few simple rules. Instead they are like moments of insight into a scene or event.

And all of this is relevant if you are creating software that is going to communicate visually. When you are building your data structures and models inside your head, it is a very different from that which the experience the user has. Your job is to make the important aspects of that model manifest visually, and usefully manipulatable.

</comment></comment></comment></comment></comment><comment><USER4> I tend to split design books into two related but somewhat distinct clusters: books about visual or aesthetic design, and books about engineering or technical design. Of course, it's not a clean split (architecture in particular strongly combines the two), but some books are clearly more on one side or the other.

For the engineering-design side, two good books, imo:

Herb Simon's classic _Sciences of the Artificial_ , which approaches design from the lens of an AI researcher trying to figure out what design really is, partly to develop it into a science of design, and partly with an eye towards formalizing a model of design that a computer could use: [http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&...](http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=5579)

 _Designerly Ways of Knowing_ by Nigel Cross, which positions design as a third kind of inquiry, neither fully science nor fully humanities, but a kind of constructive investigation of objects and their properties: [http://www.amazon.com/gp/product/3764384840/ref=as_li_ss_tl?...](http://www.amazon.com/gp/product/3764384840/ref=as_li_ss_tl?ie=UTF8&tag=abxxm-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=3764384840)

</comment><comment><USER5> why is this the "hard way"? is reading introductory books hard now? what's easy? and get off my damn lawn.

<comment><USER6> I believe this a popular new phrase thanks to Zed Shaw.

<comment><USER7> It's been awhile since I've read LPTHW, but as I recall from the intro, and from the LXTHW site, ""Less Talk, More Code" summarizes the philosophy." Given the lack of emphasis on doing here (outside the last book) I don't think this post really captures that philosophy

(That's not a commentary on the quality of this post though, or the recommendations)

</comment></comment></comment><comment><USER8> Drawing on the Right Side of the Brain is a very well written book which highlights perceptual issues of representing space. It also does a great job of mixing in developemental psychology to help you understand how a human's representation of the world changes as they grow older.

One of the best examples from the book explains why hands in children's drawings of people are always so large. Essentially, as a child focuses more on complex details (each individual finger) they unconsciously enlarge the object in order to fit in all the detail. Its a good illustration of our perception of scale vs scale relative to other objects.

There are plenty of other great observations about the way humans think visually in the book as well.

<comment><USER9> +1. I think anyone could learn to draw from life by reading and do the exercises from this book. The trick is to stop trying to draw symbols ( left brain ) and draw what you actually see ( right brain )

It's for anyone who ever told themselves they can't draw

<comment><USER2> The book is a marvel. I read the first edition when I was in college and it taught me more than two semesters of basic drawing taught by an indifferent "modern" artist. In most books that try to teach drawing as a mechanical process, as opposed as a purely "creative" exercise, they seem to leave out a "magic" step that makes things possible. Turns out that it isn't magic, but it is fairly subtle. The books makes a process explicit that is too often left to subliminal happenstance.

Don't mistake, the process is still hard, and requires much effort, but it does remove a lot of the magic feather aspect.

</comment></comment></comment><comment><USER10> _Thinking with a Pencil_ , by Henning Nelms, would be a better choice for practical drawing and design, rather than _Drawing on the Right Side of the Brain_.

[http://www.amazon.com/Thinking-Pencil-Henning- Nelms/dp/08981...](http://www.amazon.com/Thinking-Pencil-Henning- Nelms/dp/0898150523/ref=sr_1_1?ie=UTF8&qid=1322243364&sr=8-1)

</comment><comment><USER11> "The non-designer's design book" is really great, I learned a lot from it. It helps to know these things, even though I am a software developer and normally do little to no design work for my clients.

Currently I read "Visual Language for Designers" (-) which is also very interesting. It describes how our brain processes visual information and how you can use this to create better (easier to understand) designs.

(-) [http://www.amazon.com/Visual-Language-Designers- Principles-U...](http://www.amazon.com/Visual-Language-Designers-Principles- Understand/dp/1592537413/ref=sr_1_1?ie=UTF8&qid=1322229312&sr=8-1)

<comment><USER12> If you are interested in the theory design and if you can find them (no, they're not the A-Team, just maybe out of print), have a look at "Design and Form" and "The Elements of Colour" both by Johannes Itten and "Principles of Form and Design" by Wucious Wong.

</comment></comment><comment><USER13> No book on Information Architecture and User Interface? Human psychology of decision making? This is not the hard way.

Hard way is to study human behavior and then study how good things were designed around them. Study the thought process behind and try and solve some design problems yourself.

This is not the hard way.

<comment><AUTHOR> Can you recommend resources for those 2 topics?

<comment><USER13> For starters, see the footer: <http://www.andyrutledge.com/calculating- hours.php> (His home page is changed so doesn't link to them all)

<http://www.alistapart.com/> Does talk about psychology and logic behind design.

<http://52weeksofux.com/> UX

And Don't make me think. An awesome book on usability: <http://amzn.to/uZ4uH5>

I haven't found any great resource on Information Architecture yet.

<selfpromiton> I wrote a very brief intro to them all: <http://www.64notes.com/design/design-and-subsets-essay/> </selfpromiton>

<comment><AUTHOR> Thanks,

I also read "Don't Make Me Think", but I haven't included it (in this article) because I don't consider it a good book. It felt like some examples were just wrong and I also couldn't take away much value from it, although I may have been biased by my opinions on the matter. Its other flaw is that it bored me after the first third or so.

Also, "The Design of Everyday Things" (included) does talk about the psychology behind user actions. It's pretty good.

<comment><USER13> > It bored me.

> The hard way.

Words don't teach; life experience does. Books are good for intro.

</comment></comment></comment></comment></comment><comment><USER14> I'll probably have to check out the Color book by Betty Edwards. Any other recommendations for color-centric books?

I took a "color and design" course my first year of college, hoping for a lecture on color theory, but instead ended up pasting cardboard paper on poster board for four months.

<comment><AUTHOR> "Interaction of Color" was suggested as an alternative - <http://amzn.to/vnkSqW>

<comment><USER15> The main idea behind "Interaction of Color" is that the original was a large book that included (dozens of?) large colorful cards, and the focus of the book is on exercises in playing with colored paper and seeing the relationships created thereby.

The actual "theory" of the book is fairly basic, but I think the approach (i.e. learning by repeatedly doing) is definitely the right one. If you buy any recent printing, you have to force yourself to make your own and do the exercises, if you want to get the full value from the book. Comparing with other students working exercises at the same time would also probably be helpful, even if there are only two or three of you.

Here's a longer review: <http://www.handprint.com/HP/WCL/book3.html#albers>

</comment></comment></comment><comment><USER3> The ones that helped me the most were:

Universal Principles of Design

Bridgman's Complete Guide to Drawing from Life -- this is not related to design that much, but it's a staple life drawing book and once you can draw a person's face well, everything else becomes easier to draw.

</comment><comment><USER16> There is absolutely no harm in getting an appreciation of a complementary subjects -- quite the opposite, should in fact be encouraged -- and no book can teach the innate art of either programming or design, but really, isn't anything worthwhile hard?

</comment><comment><USER17> I don't personally believe you can "become" creative, but putting on good music and drawing for awhile makes things "flow" better for me. I suck at drawing tho...

<comment><AUTHOR> While I never think one could reach the levels of enlightenment of Michelangelo or Jonathan Ive :) I do believe one can exceed his creative potential. As with any other endeavor, like software development or sports, you can be better just by doing it repeatedly, getting out of your comfort zone, pushing your limits and all that crap other people keep saying.

Another thing I'm contemplating, besides drawing, is learning how to play an instrument, like the violin. A mere mortal like myself will never be a virtuoso, but I could be good enough for my own and my family's gratification.</comment></comment>


CentOS Linux 6.4 Released - <AUTHOR> http://lists.centos.org/pipermail/centos-announce/2013-March/019276.html <comment><USER2> Can HNers who have used both Debian-derived Linux distributions and CentOS/RHEL in production share their opinions on how they compare? I'm sure there's a lot of people here who, like me, are primarily experienced with the former and wouldn't mind learning about the latter.

<comment><USER3> CentOS / RHEL comes with a working SELinux setup out of the box, which is something that Debian lacks. For some, SELinux is just another pain in the arse to be disabled as soon as you run into a permission problem, for others, it comes with a really nice set of features to further lock down your system ( including disabling ptrace, which has been a great cause of concern security wise ).

Otherwise, things are somewhat different. No update-alternatives, vi is vim rather than nvi, Apache configuration is drastically different.

The packaging system is a lot stricter, packages may not touch each others files, checksums & permissions are stored in the package DB and used to verify on both install, uninstall and upgrades. there's no "recommends" system, there's no interactive upgrade packages. ( No offers to "merge your samba config" or anything like that ) as the installer system is made to be usable headless.

In "Enterprise" solutions, there's also support for Satellite ( [http://www.redhat.com/products/enterprise-linux/rhn- satellit...](http://www.redhat.com/products/enterprise-linux/rhn-satellite/) ) which is quite nifty.

RHEL has older kernels, with a lot of features&fixes backported from newer development, causing them to be very strange beasts.

Overall, I've used both, both have their place, but I really can't stand the fact that .deb archives need extra plugins to simply verify that nothing has fucked with permissions or file contents.

<comment><USER4> The added rigidity is the thing that stands out to me the most. I'm not really an IT professional, but from my limited experience it seems like Debian is a bit more flexible and a bit more suited to smaller shops, while RHEL (being more rigid) is a bit more suited to really big shops.

<comment><USER3> You tend to struggle a bit against it to begin with. "what do you mean, conflicts?!" "do as I want, dammit" and so on ;)

But after a while you realise that rpm -Va is a wonderful tool that you'll miss.

</comment></comment></comment></comment><comment><USER5> Very nice. I wonder if they finally upgraded openssl to 1.0.1

Anyone know the kernel version bump? It's always hard to figure with the backporting.

Okay tried it on one box

        2.6.32-358.0.1.el6

Looks like there are some reports of problems with xen with the update.

</comment><comment><USER6> Thanks for all your hard work, CentOS-volunteers!

</comment><comment><USER7> Allegedly xen dom0 is going to make a return in this release at some point. Can't wait.</comment>


Our calendars skipped 11 days in 1752 - mac-r https://en.wikipedia.org/wiki/1752 <comment><AUTHOR> Not quite that simple. It depends on what country you're talking about. For example, in Greece it happened in 1923. If I recall by then it was 13 days.

1752 is when Great Britain and its colonies adopted the Gregorian Calendar.

[https://en.m.wikipedia.org/wiki/Gregorian_calendar#Adoption](https://en.m.wikipedia.org/wiki/Gregorian_calendar#Adoption)

</comment><comment><USER2> Proper calendar reform would return New Years Day (Spring Equinox, currently 21st March) to 1st March. That would also have the extra advantage of relocating months seven ( _Septem_ ber), eight ( _Octo_ ber), nine ( _Novem_ ber) and ten ( _Decem_ ber) back into their original place in the calendar year.

</comment><comment> mac-r Just run the following command in your terminal: "cal 9 1752"</comment>


Using Trello for Agile Software Development: The Complete Guide - <AUTHOR> http://buildbettersoftware.com/with-trello/

<comment><USER2> We are already using Trello to track our projects, but this process is going to make things even easier. This will work great for my small team of just a handful of developers, plus my own solo side projects. If you use something like this from a solo project you can easily bring on new dev or other people at any time with much less effort and will help keep multiple projects very organized.</comment>


BuzzFeed News has found articles that do not meet our editorial standards - tech-historian https://www.buzzfeednews.com/article/markschoofs/a-note-to-our-readers <comment><AUTHOR> Some of these articles have been up for years. What triggered their investigation into this reporter now?

</comment><comment><USER2> Buzzfeed has editorial standards?</comment>


New monkey species found hiding in plain sight - <AUTHOR> https://www.nationalgeographic.com/animals/2020/06/new-species-monkeys-found-most-endangered/?MvBriefArticleId=7604 <comment><USER2> > Ang and a team of international colleagues turned to fecal samples. Animal > scat, Ang says, is an underutilized resource for scientists: It contains a > wealth of information ranging from an animals' DNA to evidence of its diet, > microbiome, and parasite load.

The future is autonomous PoopBots that can non-intrusively locate and collect samples. There are only so many reclusive primate species to discovery but bat viruses and the nocturnal mammals they co-infect require constant surveillance.

</comment><comment><USER3> [http://archive.vn/s6l1x](http://archive.vn/s6l1x)

</comment><comment><USER4> Another front in the never ending taxonomic wars. Today the Mergers have lost another battle, as the Splitters take another victory...

<comment><USER5> I guess so, yes, and it's almost unavoidable, as splitting is better for your career than merging. Splitters can "discovered a new species" on their CV and, as the de facto expert, apply for research on the new species. Mergers halve the breadth of the field.</comment></comment>


Is Samsung preparing to drop Android? | ExtremeTech - <AUTHOR> http://www.extremetech.com/computing/97565-is-samsung-preparing-to-drop-android?obref=obinsite <comment><USER2> Samsung will not drop Android, at least not in the near future. Their goal of achieving hardware platform domination against the fellow Android rivals and Apple is far more pressing than having OS independance from Google. Samsung is flattering with other OS though. Windows, Bada, and now Tizen.</comment>