The Fed suckered IBM into a failing cloud strategy? - <AUTHOR> http://www.cringely.com/2014/07/25/fed-suckered-ibm-failing-cloud-strategy/ <comment><USER2> Cutting costs isn't IBM's strategy to get out of the recession. Cutting costs is IBM's strategy. I interned there in 2003, and it was already apparent that they preferred to hire people overseas and let attrition reduce the ranks of folks locally in order to reduce costs. From all the complaints, it was clear at the time that was causing serious problems with R&D.

The joke around the office was that we'd replace one person locally with three people overseas, losing the output of two people, since the three overseas people were so clueless they'd need a local person holding their hands full- time. I was doing microprocessor design at the time, and the community is small enough that everyone know that Intel was getting good folks overseas. But even at the reduced wages outside the U.S., IBM was cutting corners and not hiring the best people.

Even locally, they try to reduce costs. A friend of mine who stuck around long enough to make it into management told me that they try to keep salaries at about the 40%-ile to save costs. On finding that out (as well as a few other gems), he left. Until I heard that, I couldn't figure why brilliant friends of mine often got raises that didn't even cover inflation. Don't they know that people are going to leave because of that? They know, and that's their strategy.

The thing about Bernanke comes out of left field. IBM didn't use low interest rates to invest therefore "the companies that were expected to spend us back to better economic health didn't do so" therefore low interest rates didn't make the recession less severe than it otherwise would have been? No comment on whether or not those last two statements are actually true (I'm not an economist and haven't studied the issue), but Cringley certainly doesn't make a case for them.

<comment><USER3> My wife worked at IBM for many years and every year, like clockwork, right before the quarter was up, they'd shut down the power to entire IBM sites for a day or two to save money. Everyone would be told to work from home. That's how important cost-cutting is to IBM.

<comment><USER4> Poundwise Pennyfoolish no? (Or is it Pennwise Poundfoolish?)

If productivity doesn't drop, why not telecommute 50%?

</comment></comment></comment><comment><USER4> First of all, Cringely is right on the first part. IBM, and many other companies, are taking advantage of the low rate environment to borrow money and buy back stock. This is capital structure optimization, and many companies do it. He is tongue is cheek about the problems being the Fed's fault.

There are impacts to this policy. By borrowing to buy back equity, you are increasing the chance of distress. You don't increase your cash position, but you do increase the amount of interest payments you have to it. (Albeit less due to the low rate environment) This means it is more difficult to bet on anything that isn't a sure thing.

That said, perhaps this is the best way for shareholders to wind down a company that can no longer innovate. At some point, large companies can cease to be innovative, and cease to profitably handle acquisitions. Then what? Especially if you're too big to be bought out yourself.

There are two options... One - Split yourself up and sell the parts to the highest bidders. Two - Buy back the shares. Shrinking the outstanding shareholder base will increase the per-share value even if the total corporate value is flat. Rather than waste money on innovation (if you can't) or M&A (if you overpay and underintegrate) better to give it back to the shareholders and let them invest capital in companies that can grow.

Borrowing to buy back shares is just taking case #2 to the extreme, and ultimately passing the buck to the long term bond holders.

<comment><USER5> See The Fed's Financial Repression At Work: How Big Blue Was Turned Into A Wall Street Slush Fund, by David Stockman at Seeking Alpha [http://seekingalpha.com/article/2324305-the-feds- financial-r...](http://seekingalpha.com/article/2324305-the-feds-financial- repression-at-work-how-big-blue-was-turned-into-a-wall-street-slush-fund)

It's a good piece, even if you don't share Stockman's view of the US economy and its impending doom [http://seekingalpha.com/article/2324315-the-implosion- is-nea...](http://seekingalpha.com/article/2324315-the-implosion-is-near- signs-of-the-bubbles-last-days)

<comment><USER6> That first article is really good (the second reads like the breathless ranting of a conspiracy theorist).

If other major companies are doing the same thing as IBM (seems likely), then it's the best explanation I've seen for the stock market boom over the last couple years. There has to be a way to incentivise these companies to create _real, long-term value_ over short-term stock price manipulation.

<comment><USER4> After a while they just get too big to do it. But that's ok. As long as someone is willing to buy the bonds, there's nothing wrong with shuffling the capital structure.

In theory, some people need fixed income instruments (say insurance companies) so there is a market for it.

If the people with risk capital want to place it on smaller more innovative companies, why not?

</comment></comment></comment></comment><comment><USER7> My wife is an ex-IBM and the cut-to-get-growth story rings true.

But it overlooks a core problem that IBM faces. The cloud is a competitive platform for problems that previously required mainframes. They successfully defended (kinda) against Oracle/Sun in areas like running large banks and stock exchanges.

What happens to IBM when you can solve hard real-time transaction problems on 1000 loosely-coupled distributed computers instead of 1 large mainframe (made up of a 1000 processors with shared state)? That day is either here or close.

My take is that they can't ignore the cloud but they can't win it either. Tough place to be.

<comment><USER8> In some ways, I think Cringely underestimates IBM's potential. (Or maybe he correctly estimates IBM management's inability to see IBM's potential.)

One way Google kicked the ass of their competition was to radically their cost of computing through smart use of commodity hardware. It seemed like a small thing, but it gave them a lasting advantage, because nobody could afford to deliver the same search features.

Given IBM's deep pockets and deep experience with hardware, I'd think there must be some strategy there that would let them create cloud computing infrastructure with radically lower cost than the competition. We regular people are stuck with off-the-shelf colocation setups, off-the-shelf hardware, off-the-shelf processors, and off-the-shelf software. IBM can afford to change any of that from scratch. Any of it.

I just can't believe that, less than 10 years into the cloud computing era, we have already happened upon the optimum approach.

<comment><USER9> What deep experience with hardware? Yes, there was a company called IBM that had a lot of hardware experience, and there is currently a company called IBM. But most of the parts of IBM that have deep experience with hardware got sold off to Lenovo.

<comment><USER10> Z-series (mainframes) and Power systems (high-end UNIX servers). Yes, both are in a shrinking market, but they've got significantly higher margins on both sales and support than commodity x86. They're also what's keeping IBM's domestic hardware manufacturing going.

</comment></comment></comment></comment><comment><USER11> The article says that because of expansionary monetary policy, "[Businesses] tended to borrow money and invest in their own shares." To me, this statement seems nonsensical. Here's why:

Fed policy affects things by changing the aggregates. But stock ownership can never change in the aggregate. If you have extra money and you buy some stock, for every dollar you spent buying stocks, someone else now a has a dollar from selling you the stocks. A common myth is that money can go "into" an asset class. It cannot. It's impossible for extra money to end up invested in stocks in aggregate, because for every buyer there must be a seller. Individually, you may have less money, but that's balanced by someone else having even more money now. Stock sales will never change the aggregate money supply nor aggregate investment nor total stock ownership. So what is cringely saying here?

I'd appreciate if anyone could explain the logic. I don't want to pre-judge, but my suspicion is that monetary policy is a subtle issue and that blaming the Fed is fun, both of which lead to mistakes such as this one.

(In fairness, perhaps the author means to say that specifically IBM used low interest rates to buy stock and not that businesses generally did this. That is a charitable interpretation that makes more sense and deviates only a little from what was actually written.)

<comment><USER12> About this:

"It's impossible for extra money to end up invested in stocks in aggregate, because for every buyer there must be a seller."

If I buy a share for $1, and then a year later sell it for $10, then the new buyer is putting $9 extra dollars into that asset class.

<comment><USER11> If person A buys a share for $1, then another person must sell a share for $1.

A year later, if person A sells a share for $10, then another person must buy a share for $10.

At all times, someone is always holding the money created by the Fed. The money never "went in" to stocks. Sure, the valuation of the stocks changed, but the aggregate money supply and the aggregate stock ownership never changed.

<comment><USER13> The money supply is constantly changed by the Fed in response to demand for cash, to maintain consistent inflation.

In 2008 when everyone started selling their stocks, the Fed had to create massive amounts of money to match the appreciation of the stocks that were being sold. Thus, because the money supply grew in that situation, people said money was "coming out of" stocks. In reality it was value coming out of stocks, and the money was being created by the Fed. So think of it as shorthand for what's really happening.

<comment><USER11> Ah, but you're committing the very same fallacy! It's not possible that "everyone started selling their stocks" in 2008. That statement makes zero logical sense. Every seller was matched by a buyer. We might just as well say that everyone starting buying stocks in 2008.

I think what often links stock prices with demand for money is risk preferences. If stocks become more volatile (which they tend to do while falling), investors deleverage. This deleveraging reduces the velocity of money and thereby increases the demand for cash. If unchecked, this will cause deflation and requires the Fed to create more money in response.

<comment><USER13> Every seller was matched by a buyer but not at the same price. If a stock starts selling at $100/share and after 1,000,000 transactions is selling at $50/share, then some money came out of the stock despite the number of shares not changing.

<comment><USER11> No, no, no. :)

Every seller is matched by a buyer at the same price!

I think you are making claims without thinking them all the way through. Let's go through an example:

Imagine there is a company with 1,000 shares. Alice buys a share from Bob for $100. This trade implicitly values the company at $100,000. Later, Carol buys a share from Dave for $50. This new trade implicitly values the company at $50,000.

The value of the company fluctuated by $50,000, but if you look at every trade, an equal number of dollars and shares were exchanged on each side. Alice lost $100 of money while Bob gained $100 of money. Carol lost $50 of money while Dave gained $50 of money.

No money "came out" of the stock.

The aggregate stock ownership stayed the same: 1,000 shares were owned both before and after.

The aggregate money supply stayed the same: $150 were in people's pockets both before and after.

The only thing that changed was the market consensus of the price of the company. The bottom line is that price changes of an asset class don't mean money is being soaked or released. Individual ownership can change, but aggregate ownership cannot.

Does that sound reasonable? I hope this conversation is helpful for people reading this comment thread.

<comment><USER13> You're missing a few pieces of the stock market. The total number of shares increases over time, and some shares pay dividends.

Edit to add: My point is that the total value of the stock market fluctuates over time. If every sale is zero-sum, how are such fluctuations possible?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> _The result of all this is that IBM management has lost touch with reality._

I see that the author needed some connective tissue between the bit about The Fed and IBM's cloud plans but any IBMer/ex-IBMer can tell you they're out of touch. The disagreement is about when they lost it.

Most, including this author, will point to whenever the domain they're experts in was mismanaged to hell. But IBM will keep on trucking right past their foray into "the cloud," constantly chasing the latest fads, and letting older divisions wither and die because nobody in charge understand the tech domain well enough to salvage them.

</comment><comment><USER15> The headline got me to click, but I fail to see how cheap interest rates makes IBM's potential cloud failure the fault of the Fed.

You could argue low rates force the hand of some firms - the stock buyback argument made sense in the article and had me following. How a strategic decision like "Cloud is where we're going as a company" can be traced to the Fed? That's where I lose the thread. What if they had decided on another investment area? Would you be writing the same article? Would one write an "The Fed suckered Amazon into a successful cloud strategy" article?

<comment><USER8> I don't think it's the fault of the Fed. If somebody making $16 million a year can't be held responsible for their choices, it's a sad world we live in.

But I do think cheap money has let IBM coast a little. Our business culture has a theory, one I think mainly dumb, that if we tie executive rewards to stock prices, they'll do good things for their companies. In this case, cheap money lets them get paid without doing anything useful.

</comment></comment><comment><USER16> The article has two good points about IBM buying shares back and not being able to compete in the cloud market. However, I fail to see how the Fed directly caused IBM to fail in their cloud strategy? Seems that IBM management fail to spend/borrow money wisely.

<comment><USER17> I read it as Cringely being sarcastic, esp when you read the last para taking a potshot at Ginni.

</comment></comment><comment><USER18> I dunno.

What I do know is that IBM seems to be the #2 advertiser on TV and in magazines after that stupid gecko.

It is trying more and more to be like those Indian outsourcers like Wipro and Infosys, but the difference is that Wipro and Infosys pay the CEO at Indian rates and spend customer money on solving customer problems rather than sponsoring tennis and golf tournaments.

</comment><comment><USER19> Why exactly does Cringley have such a hate on for IBM?

<comment><USER20> He seems like a sensationalist who has certain vendettas against specific companies and entities. I'm not sure why he's taken seriously at all...

(As in, I really don't understand why he keeps getting posted on HN, not just some throwaway insult)

<comment><USER21> Because he wrote the best book ever written on the rise of the PC industry, _Accidental Empires_ ([http://www.amazon.com/Accidental-Empires-Silicon- Millions-Co...](http://www.amazon.com/Accidental-Empires-Silicon-Millions- Competition/dp/0887308554)). And then turned it into a TV documentary miniseries, _Triumph of the Nerds_ ([http://www.amazon.com/Triumph-Nerds-Bob- Cringely/dp/B00006FX...](http://www.amazon.com/Triumph-Nerds-Bob- Cringely/dp/B00006FXQO)), which was best in class as well.

<comment><USER20> Hmm, perhaps you're right. But he seems to me to be in that category of authors who takes small bits of evidence and draws much to large of conclusions.

(And yes, I'm doing the same thing with this very comment)

</comment></comment></comment></comment><comment><USER22> Not only can they not make a profit on running cloud services, they can't make a profit selling hardware to the people who do, either. Something..something..selling the division to Lenovo...

<comment><USER23> They couldn't do that before either.

The people buying IBM x86 servers were people who were already snookered into buying POWER or Mainframe systems.

</comment></comment><comment><USER24> IBM makes its money on the consulting anyway, they don't need to make money off the cloud services. They just need to sell lots of $200+/hr consulting services putting people on them.

<comment><USER25> Consulting (and services in general) is a low-margin business. You can only increase revenue by tricking young college grads to work 80-hour weeks at low pay.

<comment><USER5> Margins on services are much higher than margins on hardware. While they're much lower than margins on software, margins on consulting services are also much harder to attack.

<comment><USER26> When they are paying someone $40 per hour and billing that person at $300 per hour there has to be a nice margin in there.

<comment><USER5> Sure, but software gross margins are typically above 80%. (And should be close to 100% in a serve-yourself online software business, where the manufacturing cost is zero.)

</comment></comment></comment></comment></comment><comment><USER27> IBM has stopped targeting excellence and started targeting EPS. You cannot operate a business without looking up from your spreadsheets once in a while, no matter how big that business is.

Earnings per share should be a natural byproduct of excelling in your market.

</comment><comment><USER28> Cringely should stick to commenting on tech as opposed to the validity of raising debt to do share buybacks in a low interest rate environment.</comment>


Ask YC: PR agency that invests in you? - <AUTHOR>

One of my local contacts remembers reading an article in a business magazine sometime back about a PR company that, instead of working for a flat fee, reviews your company and product and then works in exchange for a portion of the subsequent revenues, or part ownership, or some such thing. Basically, it's a PR firm that invests in your idea if they like it.<p>Has anybody heard of such a thing? I've searched everywhere. She thinks they were located in New York (of course). <comment><USER2> Most tech PR firms asked for (and got) warrants during the Bubble. I don't know if they still do.</comment>


Qualys Security Advisory – LibreSSL - <AUTHOR> http://seclists.org/oss-sec/2015/q4/87 <comment><USER2> Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this:

1\. OpenSSL (or this time LibreSSL) has a vulnerability discovered.

2\. Everyone gets in an uproar about how we need a clean implementation in a language that prevents stupid errors.

3\. Someone suggests unit testing. tptacek tells them to go away.

4\. Someone actually points out a Haskell project ([https://news.ycombinator.com/item?id=7557089](https://news.ycombinator.com/item?id=7557089)).

5\. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know?

6\. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies.

I see only two alternatives. Either as a community we actually stop bike shedding and throw our weight behind a project that might actually become a good alternative to OpenSSL, or we accept that the canonical TLS library will be written in C and have bugs that are periodically discovered and quickly patched.

<comment><USER3> > 6\. Someone points out that in higher level languages it's hard to write > code that is resistant against timing attacks. The discussion dies.

This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly language.

Anyway, my point is that all these things are solvable.

<comment><USER4> > This doesn't matter, because the code that should be resistant to timing > attacks should be written in assembly language

This would put you right back into buffer overflow territory...

<comment><USER5> It's unfortunate, but the approach would hopefully be to write the smallest possible primitives in assembly and then use a safer language for the rest of the code that either doesn't need constant time guarantees, or gets those guarantees by building on the primitives. This means that verification against these sort of basic attacks can be focused on a much smaller amount of code, rather than every single location in the whole code-base that manipulates memory (as in C). (And, one can go a step further: extract assembly from some higher-level language/DSL designed to create constant time code.)

In any case, the code in question for this post doesn't seem to be written to be timing sensitive.

</comment></comment></comment></comment><comment><USER6> > We would like to thank the LibreSSL team for their great work and their > incredibly quick response, and Red Hat Product Security for promptly > assigning CVE-IDs to these issues.

> Patch: > [http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_ob...](http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/007_obj2txt.patch.sig)

> Releases: > [http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/](http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/)

I am glad that bugs are found. It shows that the audit is thorough, since bugs can still be expected in LibreSSL (still quite new) and OpenSMTPD (audit was explicitly requested).

</comment><comment><USER7> > These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 > (the first public release) and LibreSSL 2.3.0 (the latest release at the > time of writing). OpenSSL is not affected.

<comment><USER8> I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code.

The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how anyone in their right mind writes C. If that is what is required to write safe C then I'm all for using another language.

Edit: I do like how Zed Shaw writes C, but I have no idea if the software he wrote is safe...

<comment><USER9> If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution?

Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely.

I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!

<comment><USER10> Well for a start lua not having integers would be an issue when implementing cryptographic primitives. The second issue is while lua is relatively lightweight, carrying a full lua runtime for each of the libraries you're using would still get unwieldy and costly, adding ~400K to each embedder according to the About page ("Under 64-bit Linux, […] the Lua library takes 414K")

<comment><USER9> Apologies. I should have referenced Lua 5.3 instead as it has both integer and bitwise operator support. This should satisfy the concerns regarding crypto implementation.

As for the space considerations, I have two ways to reason this:

* Wouldn't it only take up 1x414K? If you create luaSSL as a drop in replacement to OpenSSL, you'd only need one copy in your filesystem, just as you only have one OpenSSL.

* Even _if_ you bloat your binary sizes by 414K per executable, isn't it worth it to go from "yes, it could be unsafe, we'll never know... let's wait for the next CVE" to 100% guaranteed no memory faults EVER? Nothing is free, and this could be a cheap price to pay for the guarantee of memory safety, and the implications that come with it.

Edit: wording

<comment><USER11> For crypto-primitives, you usually want them to be constant-time. This is basically impossible to do in an interpreter or a JIT, indeed optimizing compilers can and will optimize contant-time operations out so inline assembly is commonly used.

<comment><USER9> Thank you for the info!

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> So you'd think that if anything, these kinds of 'trivial' bugs, memory leaks and buffer overflows, would not be present in LibreSSL. Especially not in the same function. I wonder what went wrong and how it can be prevented.

<comment><USER13> I know this opinion won't be popular, and I know encryption is a very complex topic, but ... TLS is simply _vastly_ too complicated. How many of us here could write a TLS library even if we wanted to? So you end up with code so complex that even the smartest people can barely understand it, let alone debug it, and you get terrifyingly long CVE lists like for OpenSSL as a result.

Compare that to a basic unencrypted HTTP server, which you can write in ~10KiB of code. Complexity breeds these kinds of problems as a natural consequence.

I do know that verifiability is significantly easier than all of this (signatures; hashing), but it's quite possible there is no simpler solution for the secrecy aspect of TLS. I certainly wish there was more support for HTTP+integrity, for those who didn't need the secrecy component. These constant CVEs in every TLS library put our servers at risk in cases where secrecy simply isn't necessary.

<comment><USER14> > Complexity breeds these kinds of problems as a natural consequence.

But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access.

> I do know that verifiability is significantly easier than all of this > (signatures; hashing), but it's quite possible there is no simpler solution > for the secrecy aspect of TLS.

In this case, the affected component was related to the identity part (certificates), which are needed for verifiability. It was not directly related to secrecy.

<comment><USER13> > the library is written in a language with manual memory management and > unsafe memory access.

C's simplicity is certainly a blessing and a curse. Right now, I'm of the opinion that C++ is the best we've got, even if not perfectly ideal. RAII, shared pointers and smart containers with bounds checking allows you to keep _nearly_ all of the performance without the drastic downsides of tracing garbage collectors (obscene amounts of memory usage, nasty stalls, etc.)

And when you get into the really high-level languages (Python, Ruby), they simply don't scale.

Everyone's darling right now is Rust. I still think it's too early in its life to know how it'll play out (hot new languages follow a predictable path of gaining negative baggage and shortcomings as they increase in real-world usage), but I guess we'll see. Maybe it will indeed be a great panacea to these issues.

> In this case, the affected component was related to the identity part > (certificates), which are needed for verifiability. It was not directly > related to secrecy.

Sure, but I'm generalizing here.

I can (and did) write a SHA256 hashing algorithm in 3KiB of code. Combined with a package gist updater (these use signing with local keys for updates), that's enough to secure binary package downloads on the BSDs over plain-text HTTP.

Surely we can come up with a less complex system for verification alone. Something akin to signify, perhaps. I know that doesn't solve how to universally handle anonymously verifying public key authenticity, but surely we can make something less complex than the clusterfuck that is TLS and the CAs. Yet it doesn't seem there's much, if any, interest in even trying. Everyone has hitched their wagons to HTTP/2 and mandatory TLS; which to me feels like a huge step backward by means of making tech _vastly_ more complex.

<comment><USER15> > And when you get into the really high-level languages (Python, Ruby), they > simply don't scale.

I think you need to qualify what "scale" means in this context. Otherwise java is, for all its warts, more or less as high level as ruby and python, and it's probably been proven to scale up (to big machines, or many developers) reasonably well.

<comment><USER16> [http://martinfowler.com/articles/lmax.html](http://martinfowler.com/articles/lmax.html)

> The system is built on the JVM platform ... in fact they ended up by doing > all the business logic for their platform: all trades, from all customers, > in all markets - on a single thread. A thread that will process 6 million > orders per second using commodity hardware

<comment><USER17> To be fair, one of the ways they achieved this is by using off-heap memory which needs to be handled in a way similar to how a C allocator would handle it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Why isn't static analysis or "sanitizers" finding this?

<comment><USER19> Good question. I'd expect static analysis to find the leak automatically - it's pretty obvious. The off by one however is behind many branches and only detectable if you know the buffer size at the call site... I'd be surprised if it triggered any scanning tool.

As a general answer though: static analysis will give you better answers if you write your code in a clean and well structured way. If you goto from a branch from a branch from a (potentially infinite) for-loop from a (not counting) while-loop - good luck :) OpenSSL's OBJ_/BN_/... functions seem to strive for complexity.

</comment></comment><comment><USER20> OS X 10.11 El Capitan is using LibreSSL: `ssh -V` How I patch this? ;) If anybody has infos when Apple is releasing a fix please tell me.

<comment><USER21> Install your own LibreSSL with Homebrew or wait for a fix from Apple.

I think Apple never discloses information about security vulnerabilities until a fix is out.

</comment></comment><comment><USER22> I have no knowledge of C, but reading their code I was surprised to see some gotos ... is this OK in C to use goto ?

<comment><USER23> Most languages use unconditional jumps to break flow when necessary, it might be called "exception" instead of "goto" but it's conceptually the same thing.

<comment><USER24> In many high level languages a break, continue, pass, that sort of thing (where you want to skip or escape a loop iteration) is usually implemented with a goto as well.

Also, a common use of goto in C is when you're doing something in nested for loops and want to break out of all of them. A goto is actually much cleaner here than using sentinel values or boolean flags, or naughty things like setting your loop variables to be outside of the conditional bounds.

<comment><USER10> Well if you go that way, fundamentally all structured programming techniques are implemented with a goto, that's what jumps are.

</comment></comment></comment></comment><comment><USER25> So much for LibreSSL being a better choice than OpenSSL.

<comment> glass- LibreSSL has had roughly half (22 to 43) as many vulnerabilities as OpenSSL since the fork and, before this, 0 sev:high, compared to OpenSSL's 5 sev:high.

Would you really disregard all that because of a 1-byte buffer overflow and a memory leak?

<comment><USER25> False:

CVE-2015-0204 affected LibreSSL, but they thought it was a low priority vulnerability, when it actually is a high priority. They fixed it, didn't notify upstream afaict and just issued a new release.

LibreSSL isn't a panacea, and based on that, they can't even classify vulnerabilities correctly.

Most of the vulnerabilities in OpenSSL are in parts (e.g. DTLS) which are disabled in lots of builds.</comment></comment></comment>


Average product lifespan of Google products before it kills them - <AUTHOR> https://gcemetery.co/google-product-lifespan/ <comment><USER3> I noticed in the "recent deaths" section, YouTube for 3DS. This made me laugh, because at Netflix, supporting the 3DS was always a big pain. Regardless, Netflix still supports it to this day.

In fact, as far as I know, Netflix has only ever killed support for one platform -- The PS2. And that was only because there were only about 10 people left using it.

So we sent them all Rokus and told them we're discontinuing PS2 support.

<comment><USER4> Netflix is the last app that works on my Sony Google TV from 2011. The YouTube app shut off after like 2015, but 8 years later Netflix is still trucking.

<comment><USER5> Why don't these devices run Android? Pretty sure you can run YouTube on a 2011 Android release. That's not important to Sony, of course, but even for new hardware it seems easier to make it run Android and shovel your bloatware on it than to develop your own half-assed OS for each TV model.

<comment><USER6> Youtube's required Android version is listed as varying depending on device on Google Play, but on apkmirror.com it says that the minimum version is Android 4.4+. That was released in 2013.

[https://www.apkmirror.com/apk/google- inc/youtube/youtube-14-...](https://www.apkmirror.com/apk/google- inc/youtube/youtube-14-43-55-release/)

<comment><USER7> That's for the latest version of YouTube, but I believe an old version of YouTube will still work fine with today's servers, at least for basic video watching (commenting etc. broke in the big Google plus debacle)

</comment></comment></comment></comment></comment><comment><USER8> Okay, so the page/statement is inaccurate, and not just because it's been spammed to HN three times before today (seven months ago).

Since I run Killed by Google, I feel it's important to clarify that the average Google product lifespan is much longer than four years thanks to flagship products like Gmail, Maps, Docs, etc. I can't actually get a solid number despite a lovely spreadsheet of products that I actively track because I haven't even compiled them all yet. Anyway, I made a choice not to draw stats in killedbygoogle.com for a reason, and it's because they're misleading to most people. When I'm asked about it, I say, "The products listed lasted an average of about four years." KBG is cynical view of Google's product strategy by any measure, but at least it's not drawing empty and misleading conclusions.

</comment><comment><USER9> Like always, I have issues with these lists. Project Ara is there despite never actually launching a product. Or Google Glass is on there despite a new Google Glass hardware that was released this year.

They also list Google Sky Map ( [https://gcemetery.co/google-sky- map/](https://gcemetery.co/google-sky-map/) ) which they call discontinued because Google released it as open source and handed over reigns to another group of developers, but looking at the github it still gets updates too, so I can see this one being either way. [https://github.com/sky-map- team/stardroid](https://github.com/sky-map-team/stardroid)

<comment><USER10> About a quarter of the projects in the graveyard had replacements, and often automated transfers to the new tools (writely, a bunch of analytics tools, songza, etc.)

Another quarter were explicitly experimental (labs, glass, ara, etc.).

And another handful are products that no longer make sense in the modern world (google desktop, various toolbars, browser sync, the gmail notifier, etc.)

Hell, one of them is apparently the webconferencing software google employees used internally in like 2012, it wasn't a product.

<comment><USER11> > Another quarter were explicitly experimental (labs, glass, ara, etc.).

How many years was Gmail in "beta"?

</comment></comment></comment><comment><USER12> Not a Google fanboy by any means, but couldn't this be read with the opposite conclusion as well - that the average time that Google keeps marginal products alive is 4 years?

Of course it's possible that everyone has some personal favourites amongst those 164, but if an idea really has legs what's to stop people from exhuming it from the Google graveyard?

<comment><USER13> It's probably more like a year with actual support and updates, two years where it's left to whither and slowly die, and then a year of notice before sunsetting it.

<comment><USER14> Yeah. By that logic MS has eternal support for everything, because MS has a legendary hardcore approach to backwards compatibility that they will release a product, push it hard, and then abandon development on it... but still have it "officially supported" for a decade while it bitrots into a nightmare... but never tell their users "stop using this, it's deprecated".

As much as I hate Google sunsetting products, I hate even more the companies that keep their zombies shuffling along in a state of undeath forever.

<comment><USER15> That makes no sense. Nobody is forcing you to use an abandoned product. So you're obviously better off with the Microsoft model than the Google one.

A good example is VB6, the runtime is still supported in Windows 10 -- and necessary for one our largest vendor products to run -- yet the VB6 IDE only runs in XP. Our business would have been really screwed if they just dropped support for it. We are, of course, working to move to a different product and have the luxury of time to do that.

</comment></comment></comment></comment><comment><USER16> I imagine Google views this as a positive thing, trying a million ideas, so that hopefully it increases the chances of having at least one good and popular idea. The downside is, a lot of products they killed were good ideas, but its sink or swim and they don't get the products the needed love and attention so they don't take off and thus they kill them. And now even when releasing a good idea or good piece of hardware people will always be worried if it will be gone tomorrow, which leads to less adoption and more axing of products.

<comment><USER17> Maybe, but some are exceptionally bad. Why did Allo exist at all for example? And the merging, demerging involved with Messages, Hangouts, and Voice have been a complete mess. There's more there than just trying some ideas, as some of the ideas actively damaged older ideas.

<comment><USER4> I don't understand why they announced that Google Hangouts (classic) is closing to move to Google Hangouts Chat, like it's a chat app am I going to notice a difference, but now you just made me think that the whole service is shutting down?

<comment><USER18> This is what happens when companies are disorganized and don't communicate internally.

</comment></comment></comment></comment><comment><USER3> I wonder what this is the _average_ of? It is the average of just things that were killed, or the average of all products, including living ones like Search? And is it really average or is it median?

> based on discontinued products listed on our website

This makes me think it is only dead products, which seems like it would skew things a bit.

If anything this tells me it takes them a long time to make a decision to kill something.

<comment><USER19> Exactly. This website is either making a very basic mistake or is just plain misleading.

<comment><USER8> This is part of the reason why I decided not to include stats at killedbygoogle.com . When you included flagship products things like Gmail, Maps, Drive, Docs, etc the 'average lifespan of a Google product' rises significantly.

</comment></comment></comment><comment><USER20> While some might be seeing 212 potential youtube scale success stories that google killed "for no apparent reason", I'm seeing 212 potential wework scale disasters that google avoided by killing off successful pitfalls and focusing on their core. The truth is somewhere in between, but obviously with google being what it is today, none of these cases chip-ed of anything from their success.

</comment><comment><USER21> Meanwhile on AWS I was using SimpleDB until recently on a small project - <USER2> make AWS _NO_ money - but they seem to still support SimpleDB even though it is not actually marketed? It's 12 years old and can't be generating a lot of new signups because it doesn't actually show up anywhere I don't think.

Does anyone know how AWS handles depreciating items on AWS. I've yet to be bitten despite beng a long time user (S3 still going / Simple DB was going last time I needed it etc).

<comment><USER22> As I've understood it, AWS keeps things alive as long as someone is using it. Once they want to get rid of it, they take it off the catalog of items you can provision, and start encouraging users to move to it's successor, and once it's abandoned fully they get rid of it. That's how they've always done old ec2 instance types, for example.

</comment></comment><comment><USER23> It surprises people that Google kills products because people them as traditional products. But they're exploratory vessels for selling ads. Of course Google's ads are the product.

It's unsurprising, to me at least, that they explore lots and lots of ways to sell ads. That's exactly what you do with whatever widget your company peddles.

</comment><comment><USER24> Average lifespan of products that have been killed, when they are killed. The actual average lifespan is probably much longer.

</comment><comment><USER25> As I understand it, a successful product launch is a strong addition to a "promo packet". What we are seeing is the inevitable result of a system that prioritizes new products above all else. If google wanted to combat the stigma that they kill 3 out of every 4 products they launch, they could just start rewarding promo packets that demonstrate maintenance and growth. I still have Reader bookmarked as a reminder to not get to invested. Show people that they are committed to the longevity of their products and you might just get more early adopters for you next big launch.

</comment><comment><USER26> I'm upset about Google Trips.

Trips was one of the few examples of how letting Google know everything about you lead to a great experience. It'll automatically figure out my time tables, hotel reservations, and flight times. The ability to download city info and store it offline was wonderful, and its recommended itineraries, while often silly in their listed time tables, were a great jumping off point.

Nothing else _can_ exist that does the same job, because only Google has access to literally everything about you.

<comment><USER27> I never heard of it, and I'm one of those people who would definitely use it.

</comment></comment><comment><USER19> Nobody is pointing the massive flaw in the headline ? This count does not consider products that have not been killed (e.g. Gmail)

It's only the average lifespan of killed products.

<comment><USER28> If you'd like a formal survival analysis which takes into account that right- censoring, I did one a while ago at [https://www.gwern.net/Google- shutdowns](https://www.gwern.net/Google-shutdowns)

</comment></comment><comment><USER29> RIP Google Inbox. I still think it was the best mobile email client they've made.

<comment><USER30> Hear hear!

</comment></comment><comment><USER31> [https://news.ycombinator.com/item?id=18509735](https://news.ycombinator.com/item?id=18509735)

</comment><comment><USER32> "The average lifespan of a discontinued Google product is 4 years and 1 month."

"The average lifespan of a _DISCONTINUED_ Google product..."

Note this does not mean the average lifespan of a Google product is 4 years. There numbers do not include products which have NOT been killed.

</comment><comment><USER33> "... they might develop their own emotional responses. You know: hate, love, fear, anger, envy. So they built in a fail-safe device."

"Which is what?"

"Four-year life span." \-- _Blade Runner_

Here, though, the emotional response is our attachment to a Google service.

</comment><comment><USER34> Most of these could have been a success but google has no idea how to connect with customers. An idea and a product is what we have. If customers accidently start using the product and it becomes a success it stays but if it doesn't meet some corporate goal it gets killed see g+(first they pushed it everywhere making everyone hate it, the moment groups of people started using it google saw it would never reach facebook and killed it. If they would have left it could have pivoted).

I don't know what many of these products are either. Cloud VR cloud, but it doesn't sound like something I would shutdown maybe sell.. maybe rethink.

</comment><comment><USER35> Reminds me of the Autodesk Graveyard:

[https://www.cadnauseam.com/autodesk- graveyard/](https://www.cadnauseam.com/autodesk-graveyard/)

</comment><comment><USER36> I'm still disappointed they killed off Google Reader, it was an excellent product as it was, and it had so much potential to be more.

</comment><comment><USER37> A better metric would be rate of death, not total deaths. For example, how many products does Google have now vs 2004 Google?

<comment><USER38> Not only a better metric, but the only way to actually compute life expectancy. We need the mortality rate for each year, then we can know the expected remaining time for any particular "age".

</comment></comment><comment><USER39> I interviewed at YouTube and I kid you not, the interviewer had no idea what YouTube Leanback was. As wrong as it sounds, I had to school her, a team lead at YouTube on their own product. YouTube Leanback is awesome and will be missed. I integrated it in a chrome extension I made called YouTube Share Enhancer.

</comment><comment><USER40> Does no one at Google HQ ever have the guts to raise their hand and bring this up? It's a meme by now.

<comment><USER41> There have been some comments on here about how career advancement optimization at Google involves hopping between projects, staying long enough to launch, and then moving on.

Whereas doing good work on product maintenance or evolution is much less rewarding.

True or not, it would explain a lot about how Google (as a whole) behaves towards products.

<comment><USER42> That's not a Google only problem. It's a cultural problem in Silicon Valley (ex drive to disrupt) and America (ex not respecting stay-at-home parents).

See the artwork of Mierle Laderman Ukeles: [https://en.wikipedia.org/wiki/Mierle_Laderman_Ukeles](https://en.wikipedia.org/wiki/Mierle_Laderman_Ukeles)

</comment></comment></comment><comment><USER43> I did not know that Chromecast audio was discontinued. That was pretty fast.

</comment><comment><USER44> my theory: [https://www.youtube.com/watch?v=H62sHBHq3pc](https://www.youtube.com/watch?v=H62sHBHq3pc)

<comment><USER45> Nice. So this is effectively what is keeping skynet at bay.

</comment></comment><comment><USER46> Inbox still hurts</comment>


OK, I will jiggle the mouse every 20 seconds or so to keep the system awake - <AUTHOR> https://pbs.twimg.com/media/CvHS2LKVUAA75Ko.png:orig <comment><USER2> [https://xkcd.com/196/](https://xkcd.com/196/)</comment>


Ask HN: Secure Search Engine - <AUTHOR>

Which secure search engine would you recommend? <comment><USER2> [https://duckduckgo.com/](https://duckduckgo.com/)

<comment><AUTHOR> Thanks</comment></comment>


Google on track to acquire a new company every 2 weeks - <AUTHOR> http://venturebeat.com/2010/09/21/google-acquisition-spending-spree/

<comment><USER2> How do you get on their schedule?</comment>


NPM's heavy-handed management prompts JavaScript code registry challenger - <AUTHOR> https://www.theregister.co.uk/2019/04/25/npm_js_challenger/ <comment><USER2> The Open-Registry

A JavaScript Package Registry funded, developed and maintained by the community, for the community

[https://open-registry.dev/](https://open-registry.dev/)

<comment><AUTHOR> I hope, building a new package registry entails weeding out package-spam like this: [https://github.com/sindresorhus/shebang- regex](https://github.com/sindresorhus/shebang-regex)

<comment><USER2> So true.. That module has 12 files, all of which to provide just 9 characters of a regular expression.

Kinda sad to see that this new open registry hasn't attracted more attention - especially considering all the people who have expressed strong reservations about NPM in recent years.

The site itself has been posted on HN numerous times, perhaps it just hasn't been lucky enough to get upvotes/comments.</comment></comment></comment>


GNU grep is 10x faster than Mac grep - <AUTHOR> http://jlebar.com/2012/11/28/GNU_grep_is_10x_faster_than_Mac_grep.html <comment><USER2> I'm not trying to start a theological war about grep/ack here, I'm just mentioning it in case someone hasn't heard about 'ack' before and they (like me) might find it extremely useful: <http://betterthangrep.com>

It's grep, just better. It highlights the selected text, it shows which files, and in what line the text was found (and uses vivid colors so you can distinguish them easily), ignores .git and .hg directories (among others, that shouldn't be searched) by default, you can tell it to search, for example for only `--cpp` or `--objc` or `--ruby` or `--text` files (with a flag, not a filename pattern), and many many other neat features that I'm sure grep has, but you have to remember and memorize them. ack has sensible defaults.

Why ack? <http://betterthangrep.com/why-ack/>

manpage: <http://betterthangrep.com/documentation/>

Oh, and ack is written in perl and doesn't require admin privileges to install.

<comment><USER3> Do you know of any C ports of ack? Ack is beautiful and productive, but nowhere near as fast as grep (orders of magnitude slower, in fact).

        gfind . -type f -exec grep -i mbr {} \; >| /dev/null
        1.10s user 0.81s system 90% cpu 2.113 total

        gfind . -type f -exec ack -i mbr {} \; >| /dev/null
        24.34s user 4.17s system 96% cpu 29.678 total

(Yes, I know about the flag to search recursively. This is the most fair comparison.)

<comment><USER4> I wrote a mostly-clone of Ack in C: <https://github.com/ggreer/the_silver_searcher> . Output format and most flags are the same. Besides the speed, most users won't notice a difference.

I spared no effort in optimizing. Pthreads, mmap(), boyer-moore-horspool strstr, it's all there. Searching my ~/code (5.2GB of stuff), I get this:

        ag blahblahblah  1.93s user 3.54s system 313% cpu 1.749 total

        ack blahblahblah  9.75s user 2.79s system 98% cpu 12.690 total

Both programs ignore a lot of extraneous files by default (hidden files, binary files, stuff in .gitignore, etc). The real amount of data searched is closer to 500MB.

<comment><USER5> Only that, Ack's core strength over time will always evolve and depend on Perl's regular expression and text processing powers.

So re writing this in C will fundamentally mean endlessly growing a language which will look similar to the Perl implementation. Or a Perl DSL.

Not that its a bad thing, I find it interesting though. I would say you better start with a specification.

<comment><USER4> Ag supports the same regexes as Ack. I use the PCRE library. I only call pcre_study once, and I use the new PCRE-JIT[1] on systems where it's available. These tweaks add up to a 3-5x speedup over Ack when regex-matching.

1\. <http://sljit.sourceforge.net/pcre.html>

<comment><USER6> If you use PCRE, you do NOT support the same regexes as Ack.

"Perl Compatible" isn't really Perl compatible, see <http://en.wikipedia.org/wiki/PCRE> for details.

<comment><USER4> Yes, there are a few edge cases, but hardly anyone uses those features. In fact, 90% of the time, most people seem to use literal string matching.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> 'why GNU grep is fast' from the FreeBSD mailing list: [http://lists.freebsd.org/pipermail/freebsd- current/2010-Augu...](http://lists.freebsd.org/pipermail/freebsd- current/2010-August/019310.html)

<comment><USER8> Also classic: [http://ridiculousfish.com/blog/posts/old-age-and- treachery.h...](http://ridiculousfish.com/blog/posts/old-age-and- treachery.html)

</comment></comment><comment><USER9> I notice these Mac tools becoming a bit stale. sort is derived GNU sort, but from some ancient version. I guess this might be due in part to these tools now being GPLv3 ?

<comment><USER10> Almost certainly. Apple stopped updating their tools past the GPLv2 versions, with the most noticeable example being gcc, which was frozen at 4.2 until they removed it.

</comment></comment><comment> X-Istence This may also be because the default grep, i.e. BSD grep actually pays attention to what you have set in your environment variable LANG. Default on OS X is en_US.UTF-8.

If the author were to set LANG to c. He would find that BSD grep suddenly speeds up tremendously.

<comment><USER11> GNU grep certainly honors locale settings, and recent versions are fast even when you're using UTF-8 (since release 2.7 or so).

<comment> X-Istence Hmm, interesting. Work is being done on BSD grep to make it faster than it is, so hopefully in the near future the two will be on par.

</comment></comment></comment><comment><USER12> For those using homebrew:

        brew install https://raw.github.com/Homebrew/homebrew-dupes/master/grep.rb

<comment><USER10> If you tap the `homebrew-dupes` repository, you will get updates in the future:

        brew tap homebrew/dupes
        brew install grep

<comment><USER13> Are there any other utils worth installing from that tap? Awk? OpenSSH?

<comment><USER10> The repository with all of the formulas is here: <https://github.com/homebrew/homebrew-dupes>

The two I end up using semi-frequently are gcc and apple-gcc, for those projects that Clang just won't compile.

</comment></comment></comment></comment><comment><USER14> You should tack a "LC_CTYPE=C" in front of grep to get comparable results. A multibyte CTYPE can slow down grep up to factor 30.

</comment><comment><USER15> Is speed really that much of a concern with grep? I typically use :vimgrep inside of vim, not because it's faster (it's orders of magnitude slower due to being interpreted vimscript), but because I hate remembering the differences between pcre/vim/gnu/posix regex syntax.

<comment><AUTHOR> I regularly search my whole Firefox clone for keywords. If this takes 2s, that's plenty fast; if it takes 20s, I'd have to come up with some other way of doing it.

<comment><USER16> Ctags?

<comment><AUTHOR> Firefox is quite complicated; we have code written in C, C++, JS, Python, Make, m4, plus at least three custom IDL formats. grep handles these with ease.

</comment></comment></comment></comment><comment><USER17> Obviously this means, Linux is 10x faster then Mac, ha!

Seriously though, it's really amazing what performance they squeezed of that tool. Always amazing to grep through gigabytes of files in a few seconds.

</comment><comment><USER2> I once tried a sed script on a couple million text files (60 GB in total) - they were web pages downloaded in some format (WARC? I don't remember what it was called) and I needed to change the formatting slightly (to feed them to Nutch) - Mac's default sed was literally 50 times slower than gsed (on the same machine). If I remember correctly, gsed finished the task in under two hours.

</comment><comment><USER18> just tried on snow leopard, not quite 10x but nearly 2x faster, certainly. (admittedly, by firefox checkout is mercurial, and hg locate seems to pass something invalid to xargs half way through, but I guess the first chunk of files are the same.)

Someone commented on the article that this might be caused by missing off the -F flag; I tried this, and -F makes both versions slightly faster again.

</comment><comment><USER19> Does "git grep" use a system grep or does it implement grep on its own?

<comment><USER20> It uses its own. See <https://github.com/git/git/blob/master/builtin/grep.c>

<comment><USER21> That seems to be the "command infrastructure" for the grep builtin. The actual grep engine is in <https://github.com/git/git/blob/master/grep.c>.

</comment></comment></comment><comment><USER22> Or...

      brew install ack</comment>


PiPhone – A Raspberry-Pi-based Smartphone - <AUTHOR> http://www.raspberrypi.org/piphone-home-made-raspberry-pi-smartphone/

<comment><USER2> Given that Broadcom originally designed the BCM2835 for smartphones, this could be said to be an actual "intended application" of the SoC. :)

$15 for a 2.5Ah battery is rather overpriced, however - as are the rest of the components like the screen and DC-DC. I found the SIM900 on eBay for $15, the DC-DC for $1.50, and ~ $5 for a battery of similar capacity. He could've put the whole thing together for <$100. Having done some electronics sourcing in China really changes your perspective on cost... amusingly enough, there was actually an iPhone 3G clone a few years ago called the PiPhone.

It's an interesting project but practically speaking $100 (no contract) can already buy a pretty good smartphone these days... and one with a more "unofficially open" SoC too.

The antenna sticking out of it is the best part.

<comment><USER3> _Having done some electronics sourcing in China really changes your perspective on cost_

Do you have any tips on doing this? Other than alibaba?

<comment><USER4> I've used [http://www.dx.com](http://www.dx.com) quite a bit. Prices are really, really low. Shipping is free. However, you may have to wait two months for your products to arrive.

Since most of this stuff is based off of open source hardware it's pretty much identical to the name brand stuff. So it pretty much comes down to a cost/time ratio consideration when first starting out. Before you know it though, you will have quite a large collection of parts built up.

Also remember you can hit garage sales, recycle yards, and thrift shops to find a lot of old hardware that you can salvage valuable parts out of for less than the price of the parts themselves.

Edit: made link clickable

<comment><USER5> Having ordered lot's of cheap prototype/evaluation boards through dx.com/ebay/aliexpress.com, I can say for sure, that quality does differ.

Seed and co have higher standards for soldering/reflow quality, wheras random factory churns out boards, probably even not doing any sort of testing apart of "hmm, looks connected".

That being said, most of the stuff still works fine despite shobby soldering and cheapest parts they could get at the market that week.

</comment></comment></comment></comment><comment><USER6> Off topic, but I think it is a good opportunity to spread the world about it: PiPhone is also an open source tool build by La Quadrature du Net in order to allow citizens to call their representatives (in France and the European Parliament).

[https://github.com/LaQuadratureDuNet/piphone](https://github.com/LaQuadratureDuNet/piphone)

[http://piphone.lqdn.fr/](http://piphone.lqdn.fr/)

</comment><comment><USER7> He should really consider smoothing it out a bit and selling it as a beginners' kit somewhere.

I would love to give my little nephew something like this where he would have to assemble all the separate parts and do some basic Linux configuration. Perhaps Adafruit could help him out with that?

<comment><USER3> _Perhaps Adafruit could help him out with that?_

That is very likely. Adafruit just previewed a cellphone platform called Fona, but its still in development.

<comment><USER8> Any source on that? Searching for Adafruit Fona only gives this thread and some junk results.

<comment><USER9> still finishing the final board layout (it's not out yet!) [https://plus.google.com/112526208786662512291/posts/2qmVHpkn...](https://plus.google.com/112526208786662512291/posts/2qmVHpknFZW) :)

<comment><USER10> will there be one with a 3G modem? GPRS is so slow.

</comment></comment></comment></comment></comment><comment><USER11> Direct link: [http://www.davidhunt.ie/piphone-a-raspberry-pi-based- smartph...](http://www.davidhunt.ie/piphone-a-raspberry-pi-based-smartphone/)

<comment><USER12> Thanks! We changed it.

HN strongly prefers original sources. The original url [1] was just a summary of this one, with a video.

Edit: The traffic seems to have killed the server within seconds of the URL change, so I'll change it back for now. If davidhunt.ie comes back, would someone please let us know?

Edit 2: Trying again. Edit 3: Down again. Probably best to give up.

1\. [http://www.raspberrypi.org/piphone-home-made-raspberry-pi- sm...](http://www.raspberrypi.org/piphone-home-made-raspberry-pi-smartphone/)

</comment></comment><comment><USER13> PhoneBlox-style fancy modular smartphones are an interesting prospect, but I really wish there was a simple replaceable-parts phone design based on ordinary development-board-style PCBs. Make it about 25mm thick and then it would be somewhat viable to carry around as a nerdy but genuinely usable phone, while still having enough internal space to be based on replaceable PCBs without too much pressure to miniaturise. Such a standard would have lots of utility: as a testbed for commercial phone development, as a place to experiment with new hardware or software for phones, as a phone (or just a gadget) incorporating niche (or "niche-of-one") hardware or software you can't get in a commercial device, as the equivalent of a self-build PC for enthusiasts.

</comment><comment><USER14> I'd love to put my own little cell phone together, but in my area the only reliable provider is Verizon, and I haven't been able to find a CDMA module for Pi or Arduino or otherwise.

Anybody got a tip on this?

<comment><USER7> You might want to try posting this question on specialist electronics subreddits and forums like r/electronics, r/rfelectronics, r/electronic_circuits/, r/hwstartups and r/hardware. So I guess my advice would be to treat it like a numbers' game :). There's bound to be _someone_ out there who can help you.

</comment></comment><comment><USER15> This is the first I hear of these Sim900 boards. Are there any other boards like it? Possibly 3G compatible models or slimmer versions with just soldering leads instead of jacks? I guess you could easily remove the jacks anyway if you needed to.

Combined with some of the slimmer boards out there (like one of the many old Allwinner sticks or Gumstix), this could actually be used to build a real open source DIY phone platform.

<comment><USER16> I've used the SIM900 boards a few times for a few moments with Arduino project. They are good and simple, but as you say not 3G (only GSM).

I assume the 3G modules are different or not as in demand by Chinese manufacturers, which is why I haven't seen any on eBay when I go looking.

I'd love a simple, cheap 3G module. It'd make the coverage better for a start.

<comment><USER2> 3G module with bonus GPS: [http://www.ebay.com/itm/261346638302](http://www.ebay.com/itm/261346638302)

Appears to be a Qualcomm QSC6270-based module.

<comment><USER10> Could one solder this 3G module on the board from the article?

[http://www.micro4you.com/store/sim900-gprs/gsm- module.html](http://www.micro4you.com/store/sim900-gprs/gsm-module.html) (just removing the GPRS module and soldering the 3G?)

<comment><USER2> Not possible, SIM900 has 68 pins and SIM5320 has 80.

</comment></comment></comment></comment></comment><comment><USER17> There is no way that phone is smaller than the ones he has had before. Unless you count the mammoths from the 90s and down.

Cool projects though.

<comment><USER18> Yeah, the point is to do it as a learning exercise. Nobody is going to carry this around in their pocket.

<comment><USER2> It'd also be a very very bad idea to try going aboard a plane with it.

</comment></comment></comment><comment><USER19> Heres to me hoping that I can have a tablet which I can use to documents and use rsync to keep the documents synchronized with my workstation. Have been waiting for the kde vivaldi tablet. Also unclear if the latest bay trail tablets will run linux without issue.

</comment><comment><USER20> How hard would it be to get Android installed and talking to the hardware properly?

<comment><USER21> The status of Android support on the Raspberry Pi doesn't seem very promising so far.

[http://www.raspberrypi.org/forums/viewtopic.php?f=73&t=71658...](http://www.raspberrypi.org/forums/viewtopic.php?f=73&t=71658&sid=7709e1adc29e25d4bcae7728dabcb718)

[http://androidpi.wikia.com/wiki/Android_Pi_Wiki](http://androidpi.wikia.com/wiki/Android_Pi_Wiki)

</comment></comment><comment><USER22> I know that there are relatively cheap USB line inputs available, but I didn't see what the PiPhone was using.

What components are used for the PiPhone's microphone?

<comment><USER21> Oh yeah, that's a good question. I've helped people with RPi audio projects before and getting external microphones to work consistently has been one of the biggest pains.

<comment><USER22> Now there is a video. In the video, he plugs a head set and a microphone into the SIM900. The audio out, 2 usb ports, and ethernet port are unused on the Pi.

</comment></comment></comment><comment> mike-cardwell Those touch screen TFTs look awesome, and incredibly cheap considering how much more you can do with a PI with one of them attached.

</comment><comment><USER23> You can also run Java Embedded and ME also on Raspberry PI!

</comment><comment><USER24> So... what's the battery life like?

<comment><USER25> He mentions he thinks a couple of hours on his blog post comments section.

</comment></comment><comment><USER26> Wonderful. I want a πPhone!

</comment><comment><USER27> PiBrick.

<comment><USER28> PiDick</comment></comment>


Started in Seattle - <AUTHOR> http://startedinseattle.com/

<comment><USER2> Fun approach to sharing Seattle Startups. Really like the interview format, lots of interesting non-traditional detail comes out of it.</comment>


"Go home or face arrest": the UK government's latest anti-foreigner stunt - <AUTHOR> http://www.migrantsrights.org.uk/migration-pulse/2013/go-home-or-face-arrest-uk-government-s-latest-anti-foreigner-stunt

<comment><USER2> "Is this just another ridiculous idea like the plan to pay for TV adverts in Romania trying to depict Britain as an awful country to would-be migrants?" That is a bit like telling a teenager they shouldn't smoke and drink.</comment>


Naples Opterons Give AMD a Second Chance in Servers - <AUTHOR> https://www.nextplatform.com/2017/03/07/naples-opterons-give-amd-second-chance-servers/ <comment><USER2> I don't think they should still be called Opterons. If the Opteron name was so great, AMD wouldn't have been completely wiped out from the server market, no?

So why not just use something fresh, better, and without all the baggage? I just don't see any significant upside for continuing to use the Opteron name.</comment>