Moving Fast and Securing Things - <AUTHOR> https://slack.engineering/moving-fast-and-securing-things-540e6c5ae58a <comment><USER2> One of the things I think about when analyzing organizational behavior is where something falls on the supportive vs controlling spectrum. It's really impressive how much they're on the supportive end here.

When organizations scale up, and especially when they're dealing with risks, it's easy for them to shift toward the controlling end of things. This is especially true when internally people can score points by assigning or shifting blame.

Controlling and blaming are terrible for creative work, though. And they're also terrible for increasing safety beyond a certain pretty low level. (For those interested, I strongly recommend Sidney Dekker's "Field Guide to Understanding Human Error" [1], a great book on how to investigate airplane accidents, and how blame-focused approaches deeply harm real safety efforts.) So it's great to see Slack finding a way to scale up without losing something that has allowed them to make such a lovely product.

[1] [https://www.amazon.com/Field-Guide-Understanding-Human- Error...](https://www.amazon.com/Field-Guide-Understanding-Human- Error/dp/0754648257)

<comment><USER3> Having recently escaped from a "control and blame" environment, this is also horrible for releases as left unchecked, more energy is expended trying to double-down on architecting for perfection in fault tolerance. Risk aversion goes through the roof cripples decision making, and before you know it your entire team of developers have become full time maintenance coders, you stop innovating and spend cycles creating imaginary problems for yourself and begin slowly sinking.

We had a guy who more or less appointed himself manager when previous engineering manager decided he couldn't deal with the environment anymore, his insistence on controlling everything resulted in a conscious decision to destroy the engineering wiki and knowledge base and forced everyone to funnel through him-creating a single source of truth. Once his mind was made up on something, he would berate other engineers, other developers and team members to get what he wanted. Features stopped being developed, things began to fail chronically, and because senior leadership weren't made up of tech people-they all deferred to him-and once they decided to officially make him engineering manager (for no reason other than he had been on the team the longest-because people were beginning to wise up and quit the company), the entire engineering department of 12 people except for 2 quit because no one wanted to work for him.

Imagine my schadenfreude after leaving that environment to find out they were forced to close after years of failing to innovate, resulting in the market catching up and passing them. Never in my adult life have I seen a company inflict so many wounds on itself and then be shocked when competitors start plucking customers off like grapes.

<comment><USER2> For those for whom this excellent description has resonance, I strongly recommend the book, "Why Does He Do That? Inside the Minds of Angry and Controlling Men". [1] It's nominally written about domestic abuse, but its descriptions of abuser psychology and its taxonomy of abuser behaviors have been really helpful to me in a work context.

[1] [https://www.amazon.com/Why-Does-He-That-Controlling- ebook/dp...](https://www.amazon.com/Why-Does-He-That-Controlling- ebook/dp/B000Q9J0RO)

</comment></comment></comment><comment><USER4> I am in favor of checklists for certain critical tasks, even if they are repetitive and/or boring. I think checklists are underrated.

<comment><USER5> I am in favor of (check)lists for everything. I am actually surprised about how few developers take notes and make list. It's one of the most important part of my workflow.

<comment><USER6> I've been convinced that checklists are great (by theory and by practice), yet I still write way fewer than I should.

I strongly dislike repetitive mental work, and writing a checklist is essentially resigning myself that such work will be necessary. Until I write it, I can still convince myself I'll be able to automate the process.

<comment><USER7> I use checklists to turn mental work ("uhh, let me think, what all do I need to do...") into straightforward physical work ("check, next step..."). I also use checklists as a first step towards automation and a stopgap until automation is complete, since I live in a constant state of infinite backlog.

If I run through the checklist a couple times and it seems to:

        [ ] Cover everything
        [ ] Not require complicated decision making or value judgments
        [ ] Has few edge cases in need of handling
        [ ] Doesn't require automation-opaque tooling
        [ ] Not change more frequently than I execute the checklist

Then I know I have a prime candidate for automation, and already have great documentation of exactly what to automate.

<comment><USER8> Awesome, a meta-checklist.

</comment></comment></comment></comment></comment><comment><USER9> I love this! If you're a part of a security team and you are not automating your processes and procedures then your team is going to drown. You must automate.

It seems like some simple checklist app but having a non Jira process that takes only a few minutes is so valuable, and "security reviews" and "threat models" as part of your SDLC take insane amounts of time and honestly aren't super helpful.

<comment><USER10> What I think is brilliant here is that that sort of work can take place separately and provide feedback to these checklists when problems or deficiencies are found. Basically the security checklists are a deliverable that can be iterated on independently while they still benefit from the existing one.

</comment></comment><comment><USER11> > At the start of 2015, Slack had 100 employees. Today, we're over 800 people!

That's a lot of people...

<comment><USER12> Seems like their client memory usage scales with their headcount

</comment></comment><comment><USER13> I like the addition question if you are using C/C++: «We confirm that we really, really need to use a non-memory-safe language.". PHP/Python/C/C++ get Medium Risk directly, Low Risk: WebApp/API/MessageServer/iOS/Android/Electron/WindowsPhone

</comment><comment><USER14> So glad they finally published this, saw the OWASP AppSec talk, was eagerly awaiting it.

However - I would want to caution: I think this model works because Slack has a self-described "culture of developer trust". I tend to think, they hire bright engineers and ensure they are equipped to do the right thing. I believe the vast majority of organizations are NOT ready for this. I direly want them to be, but simple fact is there are too many mediocre developers, and they can't be trusted without guardrails (and some straight up need babysitters).

</comment><comment><USER15> And I thought 'security' itself is friction ;-)

No seriously, I was wondering if that tool has a CLI interface? Might make it more accessable for some devs.

</comment><comment><USER16> A security app written in PHP. Nice touch.

</comment><comment><USER17> The company I work for has been offering an enterprise level service like for about 8 years now: [https://www.securitycompass.com/sdelements/](https://www.securitycompass.com/sdelements/)

</comment><comment><USER18> Well written and timely for me. I would like to see this capable of something other than Jira though :/

<comment><USER19> There's instructions for working with Trello in the repo's README, but so far it seems to be just that or JIRA Enterprise (not Cloud).

</comment></comment><comment><USER20> this is really cool.

</comment><comment><USER21> > The process of deploying code to production is very simple, and takes about > ten minutes total. This results in a life cycle in which we deploy code to > production approximately 100 times per day.

What? They spend 1000 minutes out of every 1440 deploying to production? The deployment process is occurring over 16 hours out of every 24? Am I the only one who is nonplussed by this?

EDIT: Ok I get it, I get it. I guess I always worked in much smaller companies where CD meant deploying about 10 times a day tops. TIL big companies are big.

<comment><USER22> Not a slack employee but worked at a company with similar CD views:

(Likely) various groups of people are deploying to production throughout the day. Out of those 100 deploys, an individual is probably only involved in 1 or 2 a day. As soon as you're ready to deploy your code, you queue up and see it all the way through to production along with probably a few other people doing the same thing.

The actual "change the servers over to the new production code" process is usually instantaneous or extremely quick, the 10 minutes is mostly spent testing/building/etc.

People (including myself) enjoy this because you can push very small incremental changes to production, which significantly reduces the chance of confounding errors or major issues.

Note that this is would be a Sisyphean task if your company doesn't have great logging/metrics reporting/testing/etc.

<comment><USER23> It's usually a Sisyphean task. Everyone wants to look and act cutting edge ("but Netflix!") but nobody wants to make the necessary investments in the tooling, org structure, and management ability/support that is required to support that sort of deployment cadence (if your org focuses on who broke something instead of the process, and management doesn't want to change that culture, all hope is already lost [based on experience in a large enterprise, YMMV]).

There are some legitimate needs for continuous deployment, the rest of it is cargo culting.

<comment><USER22> > There are some legitimate needs for continuous deployment, the rest of it is > cargo culting.

Maybe, but I wouldn't go that far. Small companies already often do CD, because there's rarely a rigid deploy schedule. It's a practice people understand and feel the benefits of immediately. If you ask someone who moved from a small startup to a huge company what their biggest complaints are, I bet "longer/stricter deploy process" comes up 8/10 times.

When I think of cargo cult programming I think more of TDD or Agile: Practices that people aren't familiar with and often implement without understanding the benefits or reasoning.

<comment><USER23> For every developer that complains about the longer/stricter deploy process, I'd offer up for consideration deployments that went out through the CD pipeline where production data was mangled with no rollback possible. As with everything, its determining your appetite for risk.

<comment><USER22> Hmm, I don't see how that changes with longer/stricter deploy processes - unless you have some of the tooling around that makes CD very possible in the first place (automated checks/etc.)

I've certainly worked in places with very long and strict deploy processes that managed to mangle production data frequently. Even worse, because the deploy process was so strict and long the bad code managed to stay on production for much longer than 10 minutes (the deploy time mentioned in the article).

There's some vague notion out there that long deploy process == safe, but there's very little evidence to suggest that's the case. If anything, it seems much more dangerous because larger changesets are going out all at once.

<comment><USER23> It goes back to my original comment above; if you have the proper tooling (tests executed that must pass prior to deploy given a green light, green/blue deploys, canaries, automated datastore snapshots/point in time recovery, granular control of the deployment process), I think continuous deployment provides a great deal of value above what you've invested into the process. But that investment is critical if you've bought into CD. Otherwise, it's "deploy and pray".

<comment><USER22> Sure, and I guess my point is: If you haven't invested in those things, waterfall-esque deploy processes are just as bad and perhaps even worse because there's more chance for confounding changes to cause a nasty error.

The only reason waterfall-esque deploy processes work without those things is because companies often waste tons of people-hours on testing things out in the staging environment (which requires time, obviously).

<comment><USER24> The thing you're missing is that you're amortizing the cost. Yeah, it's typically prohibitive to run the manual testing on every CL. However, if you have any manual testing you need to run, then at some point you have to batch the changes & test them out together anyway. Automated tests don't necessarily solve this problem either. 1) Some automated tests can be time-consuming & so require batching of CLs to run too 2) it's impossible to predict if you are going to catch all issues via automated testing 3) there's always things it's easier to test for manually.

When it comes to data integrity, I would think you need a structured mechanism (at least for larger teams that have a high cost for failure) for rolling back any given CL either by tracking writes, making sure to have a plan in place to recover from any given CL (e.g. nuking the data doesn't break things), being able to undo the bad writes, or just reverting to a snapshot. Without being careful here CD-style development feels like lighting up a cigarette beside an O2 tank. Now for web development this is fine since it's not touching any databases directly. More generally it feels like a trickier thing to attempt everywhere across the industry.

<comment><USER22> > However, if you have any manual testing you need to run, then at some point > you have to batch the changes & test them out together anyway.

Wait, why is that? Manual testing should be reserved for workflows that can't be automatically tested (or at least, aren't yet).

I'm not sure I see why doing any amount of manual testing would necessitate manually testing everything.

> Some automated tests can be time-consuming & so require batching of CLs to > run too

I'm not sure I see why this is a problem, and CD certainly doesn't require that only one changeset go live at a time.

> it's impossible to predict if you are going to catch all issues via > automated testing

This is also true of manual testing.

> there's always things it's easier to test for manually.

I'd go further and say it's almost always easier to test manually, but the cost of an automated test is definitely amortized and you come out ahead at some point. That point is usually quicker than you think.

> I would think you need a structured mechanism...

This paragraph is entirely true of traditional deploys with long cadences as well. The need (or lack thereof) for very formal and structured mechanisms for rolling back deploys doesn't really have much to do with the frequency that you deploy.

> Now for web development this is fine since it's not touching any databases > directly.

Maybe we're speaking about different things here, but the trope about web development is that it's basically a thin CRUD wrapper around a database, so I'm not sure this is true.

<comment><USER24> > Wait, why is that? Manual testing should be reserved for workflows that > can't be automatically tested (or at least, aren't yet). I'm not sure I see > why doing any amount of manual testing would necessitate manually testing > everything.

I never said you need to manually test everything. This is about continuous deployment where typically a push to master is the last step anyone does before the system at some point deploys it live shortly thereafter. In the general case, however, how do you know in an automatic fashion if a given CL may or may not need manual testing? If you have any manual testing then you can't just continuously deploy.

> This is also true of manual testing.

I never opined that there should only be one or the other exclusively so I don't know why you're building this strawman & arguing it throughout. A mix of automatic & manual testing is typically going to be more cost effective for a given quality bar (or vice-versa - for a given cost you're going to have a higher quality) because (good) manual testing involves humans that can spot problems that weren't considered in automation (you then obviously improve automation if you can) or things automation can't give you feedback on (e.g. UX issues like colors not being friendly to color-blind users).

> The need (or lack thereof) for very formal and structured mechanisms for > rolling back deploys doesn't really have much to do with the frequency that > you deploy.

That just isn't true. If you're thorough with your automatic & manual testing you may establish a much greater degree of confidence that things won't go catastrophically wrong. You deploy a few times a year & you're done. Now _of course_ you should always do continuous delivery so that to the best of your ability you ensure in an automated fashion an extremely high quality bar for tip of tree at all times so that you're able to kick off a release. Whether that translates into also deploying tip of tree frequently is a different question. Just to make clear what the thesis of my post is, I was saying continuous deployment is not something that's generally applicable to every domain (continuous delivery is). If you want an example, consider a FW release for some IoT device. If you deployed FW updates all the time you're putting yourself in a risky scenario where a bug bricks your units (e.g. OTA protocol breaks) & causes a giant monetary cost to your business (RMA, potential lawsuits, etc). By having a formal manual release process where you perform manual validation to catch any bugs/oversights in your automation you're paying some extra cost as insurance against a bad release.

> Maybe we're speaking about different things here, but the trope about web > development is that it's basically a thin CRUD wrapper around a database, so > I'm not sure this is true.

The frontend code itself doesn't talk do the DB directly (& if it does, you're just asking for huge security problems). The middle/backend code takes front- end requests, validates permissions, sanitizes DB queries, talks to other micro-services etc. Sometimes there are tightly coupled dependencies but I think that's rarer if you structure things correctly. Even FB which can be seen as the prototypical example of moving in this direction no longer pushes everything live. Things get pushed weekly likely to give their QA teams time to manually validate changes for the week, do staged rollouts across their population to catch issues, etc.

In general I think as you scale up continuous deployment degrades to continuous delivery because the risks in the system are higher; more users, more revenue, more employees & more SW complexity means the cost of a problem go up as does the probability of a catastrophic problem occurring. When I worked at a startup continuous deployment was fine. When I worked at big companies I always push for continuous delivery but continuous deployment would just be the wrong choice & irresponsible to our customers.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Chrome to Firefox is, what IE was to Netscape - <AUTHOR>

Don't let it happen again! Support open source and use Firefox. <comment><USER2> Except for the part about WebKit being open source... And the Chromium project...

</comment><comment><USER3> WebKit and Chromium are as open source as Firefox.</comment>


Show HN: TimeBank, Ethereum dApp - <AUTHOR> Hi everyone,
I made TimeBank https://timebank.tech , a Fullstack Decentralized Application that lets anyone lock away Ether or ERC20-standard compatible tokens (like those you seen in ICOs)for arbitrary periods of time.
Its backend is entirely on the Ethereum blockchain, 95% of the dev work was the UI and writing the smart contracts.
It doesn't handle any private keys directly, but relies on Injected Web3 (such as via the Metamask Chrome extension) or a local Ethereum node running on localhost:8545, and composes the transactions for the user to sign and broadcast. <comment><USER2> Nice, but I think you should post the link directly.

Contract source, apparently: [https://etherscan.io/address/0x459f90b6e8dc23bbf1ff4c2f22aa2...](https://etherscan.io/address/0x459f90b6e8dc23bbf1ff4c2f22aa2149b4bd4cff#code)

<comment><AUTHOR> And the ERC20 contract is here [https://etherscan.io/address/0x18ce0b9fedceb66e9fb7783bbddb4...](https://etherscan.io/address/0x18ce0b9fedceb66e9fb7783bbddb4565232a9c22) The site uses both contracts and both are linked on the Navbar FAQ.

<comment><USER2> Sorry, I'm an Ethereum novice.

<comment><AUTHOR> No worries</comment></comment></comment></comment>


Mitsubishi: We've been cheating on fuel tests for 25 years - <AUTHOR> http://money.cnn.com/2016/04/26/news/companies/mitsubishi-cheating-fuel-tests-25-years/index.html <comment><USER2> [https://en.wikipedia.org/wiki/European_emission_standards#/m...](https://en.wikipedia.org/wiki/European_emission_standards#/media/File:Euronorms_Diesel.png)

As a layman these sorts of reductions always seemed pretty strict to me. It seemed like a backdoor way of banning ICE's.

We know that we need to hit zero CO2. I think that regulations on emissions are the complete wrong way to go about it, though. Health issues in cities are irrelevant if global warming means the cities are underwater.

Tax the fuel, give incentives to renewable energies and batteries, and let the market sort it out.

Or, have the government seriously attack on the research front.

It feels a bit like we're sitting here with this 'money' abstraction and pretending that energy research is too expensive, when realistically, governments across the world have the might to make clean energy the next Apollo project. Why aren't they? That would be a fantastic legacy for any president/prime minister/whatever.

The UK could take bits of land it owns, chuck homes there, give some fresh university grads in shit economic situations some research to crunch on. Like Manhattan 2.0.

You can't just say to people 'oh, your car is impossible, let's go and sniff each other's armpits on the subway, and you'll have to walk to the countryside'. It just doesn't work.

<comment><USER3> > _" It feels a bit like we're sitting here with this 'money' abstraction and > pretending that energy research is too expensive, when realistically, > governments across the world have the might to make clean energy the next > Apollo project. Why aren't they? That would be a fantastic legacy for any > president/prime minister/whatever."_

Apollo wasn't very successful. I say this as someone who is personally an aerospace nut, and owns every space or aviation documentary he can get his hands on.

Apollo succeeded in getting a dozen men to the moon, but it did not succeed in promoting the exploration of space, or creating a great deal of technological innovation which benefited the populace at large (for the amount of money spent). Apollo was also very unpopular, except for a little while between Apollo 9 and 12. Most of the population would have been happier with a new refrigerator or air conditioner, and those appliances would probably have had a better lasting impact (for a number of reasons).

<comment><USER4> Sorry to sound harsh but your point doesn't meaningfully contribute to the discussion at hand. We knew what he meant.

<comment><USER5> The only way that I can think of to respond to a derailing comment in an effective and meaningful manner would be to engage its substance while synthesizing it with the underlying topic of the thread. Otherwise one is just perpetuating the obfuscation of the original topic of conversation. Whether the Apollo project was "successful" depends on how one views its nature and objectives; germane at least insofar as whether this is a plausible model for research as a strategic state investment, whether such action would be possible or effective, as contrasted with the alternative course of reframing the context in which undirected economic activity was occurring so as to induce a similar degree of investment and subsequent change in the commonly used technologies.

So what nickff is actually saying is that when considering the Apollo program as a model for the response to the CO2 crisis, it would be important to understand the ways in which it failed the putative goal of human expansion into space. I think that he would view the Apollo program as analogous to the discovery by Americans that the Chinese had succeeded in generating a net gain of power for a few minutes from a research fusion reactor. Responding to this by declaring that the US would build the first commercially functioning fusion reactor "not because it was easy, but because it was hard" might go a long way towards quelling the moral panic brought about by the appearance of Chinese ascendency and American decline, but it might be problematic insofar as sustainable and optimal investment in energy (source) research was considered.

<comment><USER6> As a self described "space nut" how can you fail to see the investment in innovation without the immediate return on ROI that the program brought? That's what makes the Apollo program special. We did something outside of the capitalism system but was funded from it, to achieve something no other company would even touch. That's where the magic lies.

</comment></comment></comment></comment></comment><comment><USER7> Perhaps we are at the extreme limits of emissions reductions and no real further gains can be made unless more active equipment is used on the exhaust such as electrostatic precipitators for diesels, and extra direct treatment like catalytic converters do.

<comment><USER8> Which is why the penalty to automakers should be to force them to build electric vehicles.

<comment><USER9> The penalty for automakers should be based on the law as it was written. They need no exemptions based on the scale of their crimes. If they broke the law and knew about it, then someone has to go to jail. That's how the law works, and the only thing that will prevent another 25 years of false governance.

<comment><USER8> I agree decision makers should still go to jail, but we're not going to suddenly dissolve automakers who employee hundreds of thousands of people (witness the US government stepping in to save GM).

If you can't build petrol cars that meet emissions standards, you must build electric vehicles.

<comment><USER10> It's ok for them to just not make cars if they can't make them right.

<comment><USER11> OK for whom? The US gov't clearly does not think its OK. I doubt the employees think its OK. I don't think its OK. We need cars now. In the present. Not in a decade or two when the major ones manage to make affordable electric ones and when our electric grid can handle that.

<comment><USER8> Battery technology is already five years ahead of predictions. If Tesla can make a $35K electric vehicle that 400k people are waiting 2 years for, why can't major automakers?

Also, the current electrical grid (at least in the US) can easily support 100% of light vehicles if they all transitioned to electric vehicles. The DOE did a study on this about 6 years ago. Need more power? Build more solar and wind, and use electric cars to soak it up.

<comment><USER11> The major automakers can of course make 100K luxury automobiles, electric or not. They don't replace the 17 million normally-priced cars the rest of us buy each year.

Studies and predictions are nice, but to build it and make it work takes decades. We have a massive infrastructure in the country. And of course, it won't work the way we planned. Everything changes and pivots, not just SV startups.

<comment><USER8> > Studies and predictions are nice, but to build it and make it work takes > decades. We have a massive infrastructure in the country. And of course, it > won't work the way we planned. Everything changes and pivots, not just SV > startups.

No, no it does not. Existing overnight electrical generation can satisfy replacing every internal combustion vehicle with an electrical vehicle, today, in the United States. Any statements contrary are outright lies.

<comment><USER12> > Existing overnight electrical generation can satisfy replacing every > internal combustion vehicle with an electrical vehicle, today, in the United > States.

This isn't so obviously true that it can be asserted without justification. Based on the statistics I'm seeing from the EIA, replacing every light-duty automobile in the USA with a Tesla Model S would increase demand on the electric grid by more than 50%.

[https://www.eia.gov/tools/faqs/faq.cfm?id=96&t=3](https://www.eia.gov/tools/faqs/faq.cfm?id=96&t=3)

[https://www.eia.gov/energyexplained/index.cfm?page=gasoline_...](https://www.eia.gov/energyexplained/index.cfm?page=gasoline_use)

<comment><USER8> Three years ago:

[http://insideevs.com/dont-worry-us-grid-capable-of- supportin...](http://insideevs.com/dont-worry-us-grid-capable-of-supporting- up-to-150-million-electric-vehicles/)

"The US Department of Energy's Pacific Northwest National Laboratory calculated that the grid's excess capacity will support over 150 million pure electric vehicles.

150 million means that nearly 75% of the vehicles on our roads today could be electric and the grid would have the capacity to support them all."

That leaves 25%, right? Right. Considering this is three years ago, it doesn't take into account the rapid expansion of solar and wind generation capacity (which is ~98% of all new generation capacity in 2016). The production tax credit has been extended for another 6 years; you're only going to see more wind and solar projects on the horizon.

[http://www.greentechmedia.com/articles/read/The-U.S.-Solar-M...](http://www.greentechmedia.com/articles/read/The-U.S.-Solar- Market-Now-One-Million-Installations-Strong)

"It took us 40 years to get to 1 million installations, and it will take us only two years to get to 2 million," said Dan Whitten, vice president of communications at the Solar Energy Industries Association (SEIA). "This is a time to mark when the solar industry started to accelerate at warp speed."

"At the end of 2015, the U.S. solar market hit a total capacity of 27 gigawatts. That represents just 1 percent of the current U.S. electricity mix, but it could triple to 3 percent by 2020. This year alone, the U.S. solar market is projected to grow 119 percent, which represents an additional 16 gigawatts of new installed capacity and more than double the record-breaking 7.3 gigawatts added in 2015."

Did you know they give wind power away for free in some parts of Texas because of the excess power they can't transport out? Delicious, clean wind power for electric vehicles.

[http://www.nytimes.com/2015/11/09/business/energy- environmen...](http://www.nytimes.com/2015/11/09/business/energy- environment/a-texas-utility-offers-a-nighttime-special-free-electricity.html)

So! You said my assertion wasn't obvious. I concede that is correct. The statistics you're seeing from the EIA are grossly inaccurate for comparing internal combustion vehicles to electric vehicles when you compare how much more efficient an electric vehicle is.

I stand by my thesis: the current US electric grid has sufficient generation capacity to support 100% electric vehicles

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> The article says:

"Investors responded by pushing Mitsubishi shares down by 10%. The fuel test scandal has now erased half of the company's market value, and its shares are sitting at a record low."

Shouldn't a 10% drop in their shares result in a 10% drop in the company's market value? Not 50%? I don't know much about this kinda stuff - please be chill.

<comment><USER14> "has now" = from first news of a scandal to this point

The mentioned latest 10% drop brings them down to about 50% of their market cap before the scandal broke.

</comment></comment><comment><USER15> Those small vehicles (kei cars) were reported to be under attack during the TPP trade agreement negociations because they had special tax breaks.

[http://www.japantimes.co.jp/news/2012/01/27/business/lower-t...](http://www.japantimes.co.jp/news/2012/01/27/business/lower- tax-rates-for-kei-cars-arent-ok-with-american-automakers/#.Vx_hr3qPW70)</comment>


L.A. County gets state approval of new open-source vote-counting system - <AUTHOR> http://www.latimes.com/politics/essential/la-pol-ca-essential-politics-may-2018-los-angeles-gets-the-state-s-approval-1534946283-htmlstory.html <comment><USER2> I hope open source does not become a feel good buzzword for vote tallying security efforts. Nothing precludes open source based voting firmware from being modified before deployment on the machines (and perhaps with less effort as the source code is easily studied). Without end-to-end documentation of the entire build process for the final image, and secure hashing of the binary, open source means nothing. And even then...

> The ballot-counting equipment is part of a broader redesign of Los Angeles > County's voting system, which will include new equipment while relying on a > traditional paper ballot

Article is light on details, and it's difficult to tell exactly what this sentence means, but if it means the new software will produce paper ballots that can be verified and observed by humans, that's a good thing at least.

<comment><USER3> In Minnesota we have a hybrid system where you fill out a paper ballot. The then you feed it through a scanner that indicates that it counted your vote, counts it, and it rolls into a locked box.

The machine and ballots are tied together right there. I really like the system as if all else fails you can get a paper trail and I belive even ID machines.

<comment><USER4> The machines seem to work well too. I don't know why everyone doesn't do it like we do.

<comment><USER5> Because the people in power are terrified that just _maybe_ there actually is some funny business going on and they are benefiting from it (by having been elected), and if they fix the system they will lose the next time around. It's probably an irrational fear in many ways, but there's always that little bit of them wondering.

Also, they could have granted long term contracts to existing suppliers, don't have a budget to replace existing machines, don't want to make the person who bought them look bad, or even possibly don't want to say the old machines are bad because it calls into question the integrity of past elections.

</comment></comment></comment></comment><comment><USER6> Is this the same thing that Smartmatic company was hired for?

[https://abc7.com/politics/new-voting-system-approved-by- la-c...](https://abc7.com/politics/new-voting-system-approved-by-la-county- board-of-supervisors/3595736/)

That seems to be the case:

> _" Separately, Logan signed a contract on June 13 with Smartmatic USA, > making it the VSAP prime contractor and systems integrator. Smartmatic USA > will help Logan's office in managing the manufacture and implemention of > components scheduled for introduction in the March 2020 California > presidential primary election."_ [https://www.techwire.net/news/la-county- > oks-open-source-elec...](https://www.techwire.net/news/la-county-oks-open- > source-election-system.html)

Why are all these "voting machine" companies so shady?

> _" The Venezuelan-owned Smartmatic Corporation is a riddle both in ownership > and operation, complicated by the fact that its machines have overseen > several landslide (and contested) victories by President Hugo Chavez and his > supporters. The electronic voting company went from a small technology > startup to a market player in just a few years, catapulted by its > participation in the August 2004 recall referendum. Smartmatic has claimed > to be of U.S. origin, but its true owners -- probably elite Venezuelans of > several political strains -- remain hidden behind a web of holding companies > in the Netherlands and Barbados. The Smartmatic machines used in Venezuela > are widely suspected of, though never proven conclusively to be, susceptible > to fraud. The company is thought to be backing out of Venezuelan electoral > events, focusing now on other parts of world, including the United States > via its subsidiary, Sequoia."_ > [https://wikileaks.org/plusd/cables/06CARACAS2063_a.html](https://wikileaks.org/plusd/cables/06CARACAS2063_a.html)

<comment><USER7> Smartmatic is a CIA operation.

</comment></comment><comment><USER8>
      The ballot-counting
      equipment is part of a
      broader redesign of Los
      Angeles County's voting
      system, which will include
      new equipment while relying
      on a traditional paper ballot.

So they're paper ballots but the machine to count them is open source?

<comment><USER9> It seems the larger plan will be to have tablet kiosks where you can either select your choices, or scan a QR code from your phone (with your pre-selected choices) and then your ballot selections are printed to the paper ballot.

They have been asking for suggested areas for "Voting Centers" recently where LA County citizens can vote at the location of their choosing. Many people here have long commutes from traffic or public transport. For this reason (and maybe others) the County wants to make it so people can vote at any of the available "vote centers", rather than one assigned polling location by their home.

You can watch the video that they were sending around here: [https://www.youtube.com/watch?v=fC_-8Nl-O3U](https://www.youtube.com/watch?v=fC_-8Nl-O3U)

<comment><USER10> This just sounds like a really expensive pencil if all it does it print it out on paper.

<comment><USER11> People marking paper ballots manage to screw up the marking in every conceivable way, and when those are recounted in a close race, whoever is doing the counting can exercise some discretion in edge cases. Presumably a machine could guarantee that the ballot was filled out correctly and not spoiled.

For example, in a 2017 election for a seat of the Virginia House which would have switched party control, an election recount came up one vote in favor of the Democrat, but then GOP officials declared that a (clearly spoiled under any reasonable interpretation of the official rules for counting) ballot should count for the GOP candidate, making the vote a tie. Another GOP official then decided the contest in the GOP candidate's favor by drawing his name from a hat. [https://en.wikipedia.org/wiki/Virginia_House_of_Delegates_el...](https://en.wikipedia.org/wiki/Virginia_House_of_Delegates_election,_2017#Recounts)

<comment><USER12> I've been a poll worker. This is true. Once a race has two columns of candidates the voter errors spike, no matter how well designed the ballot is.

I wish election results came with a margin of error calculation, because too many people assume that a vote result is 100% accurate. Especially to justify the result of a winner-take-all election.

</comment></comment></comment></comment></comment><comment><USER13> Electronic voting conflates authenticity with legitimacy. Same problem in digital identity.

To me it seemed actually stupid to believe that the only thing preventing algorithms from yielding the sympathetic magic required for a peaceful transfer of sovereign power, was their lack of complexity. Arguably, without the ritual element, democracy reduces to a lottery with a biased mechanism, and for it to work, it must necessarily be more than that.

It's a larger philosophical question, to be sure, but it's like comparing a Turing test to an Indifference curve. The first is to determine whether something can convince people it is another person, the second is to predict the point at which you will cease to care enough to choose something else. These are analogous in that, like an AI, we can design an e-voting system that can act convincingly as though it facilitates democracy, but mainly it is just an acceptable substitute for people who no longer care whether the democracy they are dealing with is real or not.

In the case of voting, it's not just a thought experiment, or a product dev question, as by real, I mean sufficiently legitimate for people not to reject the results and cause civil disturbances.

It might sound a bit extreme, but we should really be asking when we institute electronic voting (or counting) whether we are willing to accept a simulation of the ritual we use to grant sovereign powers to people.

</comment><comment><USER14> Voting is an area where we don't need automation or fast results. Typically a newly elected person doesn't take office for days or months after an election, right?

Paper ballots cannot be hacked at scale.

Properly designed paper ballots and a national design and education rolled out about them would propel us forwards as a nation.

<comment><USER15> The first argument does not hold for traditional paper ballots. Paper ballots are all already counted for the critical evening news at 8pm, and are all seen by multiple eyes.

</comment></comment><comment><USER16> LA Times not available in the EU: can we stop posting links to it?

[https://www.techwire.net/news/la-county-oks-open-source- elec...](https://www.techwire.net/news/la-county-oks-open-source-election- system.html)

</comment><comment><USER17> Looks pretty good. I think it's too bad that the filled out ballot just goes into the place where the unfilled ballot is printed. Makes it feel like it could be over-printed or something. Taking the filled out ballot over to a box is not that much of an inconvenience. If they're worried about observation during that transfer, put the box by the voting system, but more obviously separate.

</comment><comment><USER18> Open Source voting is a great start. Transparent voting is better. Random auditing is a complete solution.

</comment><comment><USER19> What we should have instead is a cryptographically secure voting system where no one can prove how they voted but can verify that their vote was counted properly.

The trick is just to have people scan a QR code when they register, to make sure it's one vote one person.

<comment><USER20> I wonder if you are being downvoted because you said "cryptographically" and people think you are suggesting something with a blockchain?

Anyway, such a system as you want has been designed, and is inexpensive and works well with existing systems, and makes it easy for third parties to audit the results: [https://en.wikipedia.org/wiki/Scantegrity](https://en.wikipedia.org/wiki/Scantegrity)

<comment><USER21> How can the system prove that my vote counted correctly if I can't personally verify who my vote was counted for?

This system obviously requires centralized trust (which I'm not against in practice) — but is there any provably secure way to make such a system decentralized? (Yes, blockchain..)

<comment><USER20> > How can the system prove that my vote counted correctly if I can't > personally verify who my vote was counted for?

In the Scantegrity sysem you can personally verify who your vote was counted for.

</comment></comment></comment></comment><comment><USER22> Article light on details, to save me the searching, can anyone link to the source code?

<comment><USER23> If I'm reading the contract correctly[1], the source won't be available until 2020. There's also some limitations put on the licensing that are IMO stretching (or maybe abusing) the definition of open source.

[1] [http://file.lacounty.gov/SDSInter/bos/supdocs/123460.pdf](http://file.lacounty.gov/SDSInter/bos/supdocs/123460.pdf)

<comment><USER24> They reserve the right to make it open source in that contract, but they may or may not do so.

<comment><USER23> LA County has the right, and elsewhere they've said that they will (although of course plans change, with some caveats about device firmware and using it for your own elections

</comment></comment></comment></comment><comment><USER25> It's open source, so that means you can see for yourself why the votes were counted correctly!

How do you safely pass votes from the machine to the counter?

</comment><comment><USER26> Relevant: [http://vsap.lavote.net/](http://vsap.lavote.net/)

</comment><comment><USER27> I hope that as part of the design, it will also [optionally] enforce some form of voter identification (passport, drivers license, passport card, or even a credit card with a chip or apple pay for all I care).

I suspect above might be unpopular idea. Especially since obvious downside is that if poorly implemented (or exploited) it could allow establishing who voted what and in any case allow establishing who did and didn't vote. And no, I don't think voter fraud is widespread, or has had any impact of consequence to overall results. But in this age and day, I think we should have a system where a registered voter is first identified by the system before presenting them with the ballot. This way, assuming systems were interlinked, one could vote anywhere in the country, and be given the right ballot for where you live.

And then the obvious next step would be allowing voting via browser. One vote for one registered ID. If system thinks your ID has already voted, have an escalation mechanism to re-cast the vote and investigate.

<comment> fake-name The problem with enforcing voter ID laws is that it's a solution to a non- existent problem.

If you want to increase the bar for people to vote, you _HAVE_ to demonstrate that the current system is problematic.

There have been multiple attempts to find ANY significant voter fraud that would have been at all affected by forcing voter-ID requirements. They have universally found nothing.

As such, there's no _real_ reason to support voter-ID laws, aside from deliberately trying to disenfranchise low-income voters.

<comment><USER28> >As such, there's no real reason to support voter-ID laws, aside from deliberately trying to disenfranchise low-income voters.

This is a common point, but I think it assumes too much about low-income voters. You need an ID to access essentially all of the government services that low-income folks would need. I'm really skeptical that mandating voter ID would have any real effect on these groups (understand that we _do_ sound a bit Elitist talking about what's good for the proles ... I like to err on the side of them being competent enough to use their ID to both get access to welfare programs and, also, vote).

<comment><USER29> There are more people who lack ID for one reason or another (e.g. over 600,000 registered voters in Texas lacked the necessary types of ID to vote under its voter-ID law in 2014) than there are fraudulent voters, so if you're going to address one problem or the other, I think the one that actually happens is the better direction to err.

<comment><USER30> My proposed solution is somewhat more simple:

Universal, automatic voter registration moots this entire sideshow.

Just like every other mature democracy.</comment></comment></comment></comment></comment>


Is Coding the New Literacy? - <AUTHOR> http://www.motherjones.com/media/2014/06/computer-science-programming-code-diversity-sexism-education Tasneem Raja, of Mother Jones, on computer literacy, problem solving, education and diversity. <comment><USER2> Although this is a long article, it's one of the best things I've read about computer literacy, diversity, and being prepared for the future. The main point seems to be that we should teach "computational thinking", first and foremost. Not everyone needs to learn how to "code", in the sense of learning Java syntax or whatever. Even if they couldn't implement the program, it would be helpful if more people in all professions were more comfortable with generally how computers could improve a process in their government or community. Plus, it seems that if you start with that, learning to code per se will be more appealing to a broader group of people. So in that sense it's win/win.

<comment><USER3> tl;dr: Engineers think the world would be a better place if only everyone was an Engineer.

<comment><USER2> Well if you read a few paragraphs into the article, there are examples like Code for America doing an adopt-a-fire-hydrant app in Boston. Which gets repurposed as an adopt-a-tsunami-siren in budget-strapped Honolulu, at a cost of ~$20/month. I don't think people need to be rabid nerds to see processes in government that could be improved. The article is about more people having the general mindset about _how_ they could be improved.

In the middles ages, maybe some scribners thought the world would be a better place if everyone were literate? That doesn't mean everyone should be a professional author. But they should be able to participate in a world full of writing and reading.

By the way, the article has a comment by rms, so it's worth at least scrolling to the end, even if one lacks time to read the whole thing.</comment></comment></comment>


Tips for naming variables - <AUTHOR> http://makinggoodsoftware.com/2009/05/04/71-tips-for-naming-variables/

<comment><USER2>
      void swap(int* x, int* y)
        { int t = *x; *x = *y; *y = t; }

Small blocks with very obvious code are perfectly Ok to have short variable names in. All other rules in this post can be criticized as easily.

Hence, rule #8: forget about the previous rules, just be a smart coder.

<comment><USER3> Indeed, I think one very useful rule for naming variables is "the length of the name should be proportional to the scope". If you're iterating through a list of objects representing unfilled orders, it's OK to do this:

      for uo in unfilledOrdersIterator():
          oid = uo.id
          status = uo.status
          email = uo.customer.email
          sendEmail(email, "Your order %s is in status %s" % (oid, status))

But if there's a 200-line method that does all sorts of other things with a single unfilled order, then calling the order "uo" is probably a bad idea.

<comment><USER4> Shouldn't there NOT be 200-line methods in the first place?

<comment><USER5> There are some cases where 200-line methods are perfectly acceptable, when breaking the logic into smaller functions only complicates the understanding and development of the algorithm. Not everything can be broken into multiple elegant 10-line functions without obfuscating the purpose or control flow.

<comment><USER3> One thing I've occasionally done to tame large functions is this:

      def frobWidget(widget):
          def frobCog(cog):
              ## stuff involving both cog and widget
          ## stuff involving widget
          frobbedCogs = [frobCog(cog) for cog in widget]
          ## more stuff involving widget and frobbedCogs

If frobCog were broken out into a separate function, then it would have to take widget as an argument, and if frobCog is never actually called from anywhere other than within frobWidget, then such separation makes the code harder to understand. Keeping the definition internal lets me take advantage of lexical scope; I can refer to widget within the definition of frobCog.

<comment><USER2> In the example you showed I'd probably do the same, true, but I think there is no evil in passing widget as an argument.

In general, there's nothing wrong with functions that take everything they use as arguments. This is kind of functional programming (or a good part of it): every function is as independent as possible, which makes them easier to debug, easier to understand, and safer in terms of bugs. Functions that deal with data from outer scopes risk being less readable and less reliable.

</comment></comment></comment></comment></comment></comment><comment><USER6> Stopped reading here: "Good example: daysFromDateRangeStartToEnd".

<comment><AUTHOR> Hi babo,

you are absolutely right with your observation, that variable name its just a bad example, I have just edited the post and I have changed its name to daysDateRange.

Thanks for your feedback

<comment><USER7> Neither your original daysFromDateRangeStartToEnd nor daysDateRange seem to capture what it is supposed to represent. Perhaps if it was seen in context, it would be understandable, but by itself I do not think it is a good example.

</comment></comment></comment><comment><USER8> > Example. If your customer just considers "order" an "order" that has been > approved, don't call "order" to a non approved one in your code, call it > "nonApprovedOrder".

Doesn't this violate his rule #5?

<comment><AUTHOR> Hi Deestann, good catch, I should have stressed that these are guidelines not rules, what I meant is if possible use positive logic, but it fits better the negative, use the negative one.

Thanks for the comment

</comment></comment><comment><USER9> Ideally should be using short methods, so what's wrong with using generic names?

</comment><comment><USER10> "Don´t use negative logic for your variable names."

Obviously written by a software weenie who lives far, far away from the actual hardware. ;-) (Digital logic often uses active-low signals for good electrical reasons. And some purely historic reasons: do memory chips actually _need_ to power up in the activated state?)

<comment><USER11> What what what?

<comment><USER10> Many circuits work with Boolean values that are true in the 0 state, and false in the 1 state: negative logic. That had better be reflected in the variable names.</comment></comment></comment>


Paul Buchheit: Tablet thoughts - <AUTHOR> http://paulbuchheit.blogspot.com/2009/12/tablet-thoughts.html <comment><USER2> Currently there is no computer, in any form, that is successful because it can be used together with other people in a physical sense. I think this new product must be great to use _alone_ or will not meet the masses.

So even if this vision can be reductive I continue to think at this new product as a larger more powerful version of the iPhone that is mainly a portable device.

Portalbe does not mean the only usage is to carry it around outside your home. It feels natural that such a device is something you can lean on the table while cooking to read the news from internet, or to watch a film while on the bed after a destructive 2010 party like I'm doing right now.

Also of course in the "outside" world it's a great experience if the device is light enough. For instance I never take my laptop outside in the plane when I flight, as I feel uncomfortable to do it, my macbook is too weight and requires too space. So what I use is my iPhone indeed, but it's totally inadequate to perform tasks like writing a blog post.

So actually I can see why this device can be a success.

I also can clearly see (it's years I think that I could start a startup about this issue) how people are not able to share an image with one click, but this is, IMHO, an entirely different problem that should be addressed in some other way.

When I heard about Google Wave the first time my first reaction was: now people will be free to share things with one click in real-time, but my feelings with Wave are not good, it's not as "simple" as I dreamed, so I guess we have to wait for a new solution.

<comment><USER3> >Currently there is no computer, in any form, that is successful because it can be used together with other people in a physical sense. I think this new product must be great to use alone or will not meet the masses.

Game consoles come to mind.

</comment></comment><comment><USER4> Paul's ideas for what could be possible with this device are very interesting. But I can't help but wonder if Apple's new tablet could turn out to be the Google Wave of consumer devices: a super-hyped disappointment.

Apple has a very good track record, but sooner or later, they are going to release a device that will fall short - maybe even well short - of the fever pitch of hype that precedes it. Could this be that time? I doubt it...but you never know.

<comment><USER5> Apple has released poorly received products before. Perhaps you recall the PowerMac G4 Cube, the Newton, the mighty mouse, iMovie '09...

<comment><USER6> Yep. If it happens, it won't be the first time, won't be the last time, won't be Apple's death knell, won't be a sign of decline.

</comment></comment></comment><comment><USER7> Bump folks! I hope you are listening to this!

Though for all I know your iPhone software already does Paul B's photosharing trick... I'm the world's laziest beta user so I don't know.

<comment><USER8> I think the Divyshot folks have something like this already.</comment></comment>


The Cheap Phones Quietly Winning the U.S - <AUTHOR> http://www.bloomberg.com/news/articles/2015-09-03/zte-s-cheap-phones-quietly-winning-the-u-s- <comment><USER2> Moto G seems be my baseline for what I expect a good enough phone to be. That honor used to belong to the Galaxy S III US. Ver.

I expect others like ZTE and Alcatel will catch up at some point. But probably will also face some fearce competition from the quality direct-to-customer type companies like Xiaomi, OnePlus, Wileyfox.

<comment><USER3> So what's the catch with the ZTE? Processor speed is boring. Is it the touch screen being unresponsive? Some software thing? Bad screen? Does it break easily?

<comment><USER4> The catch is you probably cannot root it.

ZTE has gotten VERY good at locking down their phones, the bootloader checks and undoes root and the kernel seems to detect attempts otherwise.

For me, non-root is a showstopper.

<comment><USER5> If they are preventing you from loading your own software, in my mind that lends credence to the idea that ZTE has some sort of spying capability (beyond the usual smartphone spying capabilities) that they really don't want to lose.

<comment><USER6> Perhaps that's why they're so cheap - their cost is subsidised by the listeners?

<comment><USER3> You know, 3 years ago I would have called that paranoid. Now? Not so sure.

</comment></comment></comment></comment></comment></comment><comment><USER7> I own a Nokia Lumia Icon (Verizon) and a Microsoft Lumia 640 (T-Mobile). The Icon was bought on a plan and was $199 subsidized. The 640 was bought off- contract for $99. I believe the Icon was selling for around $700 off-contract. I've used both extensively now (the Icon was my old daily phone, the 640 is my new one). The 640 is lacking in the camera. That's it. Every other experience on the phone? Identical. I don't miss the Icon at all, and I think that really says something.

Why would a phone 6-7x the price be roughly equivalent in experience? Why should it be? The 640 isn't subsidized by anything. $99 is the just the price of it. It's an amazing device, FAR better than an equivalent android.

People complain about Windows Phone not having "flagship" devices, but realistically, it doesn't need them. The cheap phones are great.

I've tried expensive android phones, iphone, as well. None of them stand up to the experience on WP for me. If Microsoft keeps making $100 phones like this, I'll never pay more than that for a phone.

<comment><USER8> Hey, I'm glad you're liking the WP. Honestly, I think WP should be great. That said....

Android phones are starting to get into this territory too. OnePlus 2 is $400. That is 4x the cost of your $100. But it is less than half the cost of my $1000 Note 2. (I don't buy on contract because I have a grandfather plan on VZ for unlimited data). My wife's phone was $700. Next refresh in about 2 years we'll be in the OnePlus store.

The reason I say all of this is that we should all, across every platform but Apple, be looking forward to getting less expensive, higher quality devices.

<comment><USER9> I'm hoping that Android gets a lot better on the battery usage before that happens in earnest though. I've read they've focused on this recently but I haven't had time to drill into details.

I love Windows Phone and have had 3 different models since Windows Phone 7. I'm currently on a Lumia 830 for my private phone and get about 3.5-4 days of battery life. Granted I don't call/text a lot relying on email, Lync and Skype. My previous Lumia 520 was about the same, and the previous LG E900 was 2.5-3 days.

My partner has a Moto G (1st Generation) and loves it but only gets about 1-1.5 days of battery life. Good phone, similar price levels after offers on the Lumia 830, but dramatically lower battery life.

</comment></comment></comment><comment><USER10> The last phone I had last for more than 2 years was made by Palm. After that:

1) lost the phone. We think it was left on the roof of my car

2) Dropped in toilet. Did not have removable battery, so it eventually shorted out

3) An OTA firmware update bricked it, the device was 2 months out of warranty so the manufacturer refused to fix it, despite their software being what bricked it.

I'm now on a 1st gen Moto X I got used for $100. I don't plan on spending much more than that for a phone ever again.

<comment><USER11> what do you use for a computer most of the time?

reason I ask: I'm on my galaxy note 4 probably 40% of time and going up.pc/mac get rest of time and going down.

got rid of all IOS devices.

<comment><USER10> Most of my time on the computer is at work, so I have a Dell Optiplex with 2 24" screens. At home, I have both a workstation and a laptop, and probably use the laptop more. I use the phone for a quick lookup something, or for reading articles, watching videos &ct.

<comment><USER11> getting multi-screens connected to my "phone" is the key thing I'm missing. I can do it with one now -- but its not as good as attaching a mac/pc to an external monitor for coding or similar big screen tasks.

I'd put cyanogenmod on my note4 - but then I'd loose the cool pen feature that I use a lot.

I wonder if intel and microsoft will succeeed in shrinking the tablet/pc all the way down to phone size before the phone guys figure this out - I would love that (disclaimer I work for intel).

</comment></comment></comment></comment><comment><USER12> Except of course for Apple with 44% of the market in the US, which is increasing, and somewhere around 90% of the profit. Winning in Android is a race to the bottom where only the cheap survive, exactly what happened to Dell and its competitors in the PC market. And someday Google will decide it needs to actually make money from Android and that world will fork into Google Android Phone and the seven dwarf versions.

<comment><USER13> I can't picture a day Google decides make money directly out of Android. It gets them tons of users to their services which gets them tons of money. And all companies building Android phones are doing the selling hard part instead of Google. Far more likely is an ever greater interaction between Android, online services and chrome OS until they all mix undistinguished or one takes over the others.

<comment><USER14> Google already makes money from Android. The base OS is free, but they charge for the application, store and play services bundle, IIRC.

</comment></comment></comment><comment><USER15> As phone subsidies go away there's going to be a lot more price pressure on mobile hardware vendors.

<comment><USER16> Well the issue is people STILL won't see the bottom line price. They will get the monthly price. A LG G3 is $17 a month and an iPhone 6 is $25. People do horrible math and don't see that they are paying $200 more for an iPhone 6.

<comment><USER17> People will pay $5K more for an equivalent Toyota. It doesn't mean they are doing horrible math. Maybe they've sold a previous Toyota and realized, used, they bring in significantly more than the Chevy.

<comment><USER16> Me: You know your paying $200 more for that phone right?

Them: No, really?

Me: It is $8 a month more and at 2 years that is 24 * 8. So in 2 years you are paying $192 more.

Them: Shocked look and than they try to do the math in their head and can't and just shrug.

This has happened with family members and strangers

People can't do simple math in their head. My definition of simple math is business math and specifically do a 2 digit times a 1 digit number.

<comment><USER17> Are you really an adult if you can't do basic maths? I mean in the modern, self actualized, responsible for you own actions, type of adult?

<comment><USER18> Yes.

I would say that the majority of adults fall into that category (not knowing they're paying $200 extra, that is), and they all manage to take care of themselves, somehow.

Many aren't very good at that, either.

</comment></comment></comment></comment></comment></comment><comment><USER19> This article reminds me of the "shitphone" story that got posted here a while back. Long but definitely worthwhile IMHO.

[https://medium.com/matter/shitphone-a-love- story-a44e6643480...](https://medium.com/matter/shitphone-a-love- story-a44e66434807)

Basically an exploration of value. An iPhone can cost 3x times as much as some of these other phones, and is certainly a more pleasant device to use, but does it really offer 3x as much functionality?

The basic (world-changing) functions of the smartphone (location services with GPS, decent point and shoot camera with you at all times, web access on the go, etc.) are present in both devices.

<comment><USER20> > _The basic (world-changing) functions of the smartphone (location services > with GPS, decent point and shoot camera with you at all times, web access on > the go, etc.) are present in both devices._

Generally, cheap ($30) phone's camera is awful. $200 Android phone's camera is good. iPhone 6's camera is excellent. (Though I am using iPhone 6 Plus, I still think iPhone 6 Plus is too expensive.)

<comment><USER21> Given the Sony makes $20 per iPhone 6 sold for providing the cameras to Apple, I would hope that they'd be better quality than the $30 phone!

</comment></comment></comment><comment><USER22> I had a ZTE Monte Carlo and used it for 3 years. It's surprisingly durable as a device. Everything works and there're minimal physical damage after my careless use for 3 years. Whereas my other Chinese brand phone (Umi) had more and more problems as it wears out just 1 year after.

<comment><USER23> I'm currently rocking the indestructible, inexhaustible nokia 105 (phone flashlight ftw), but next year when I go east to seek my fortune on the continent I've accepted that a smartphone and associated nightly charging ritual will become essential.

What would HN recommend as a cheap, durable android device? These ZTE things look pretty good...

Also, what happened to those ultra cheap windows mobile devices targeted at "emerging markets?"

<comment><USER24> It depends how much of an upgrade you're looking for. If you want a flagship- esque phone without the price the new $220 Moto G is an excellent pick. I absolutely love mine—it's fast, has a good battery and is much more stylish than other phones in the category.

The only thing keeping it back from being a flagship is the camera. Also possibly the 5.1 screen-size. But hey, I prefer the 5" screen over the 5.5" to 6" ones, so it works for me.

EDIT: Also, Motorola has almost no bloatware on the phones. The few apps they pre-install are actually quite good.

<comment><USER23> What is a flagship? Just a really good phone?

<comment><USER25> It just means the company's primary high-end phones. For example, the iPhone 6 and Galaxy S6.

</comment></comment></comment></comment></comment><comment><USER26> My wife tried the Moto G 2nd generation LTE $160, but didn't like the industrial design- too cheap. I think the first generation may have been nicer. We ended up with the Samsung Galaxy Alpha for $275: it looks nice, but not quite as expensive as their flagship phones:

[http://www.amazon.com/Samsung-Galaxy-G850a-Unlocked- Cellphon...](http://www.amazon.com/Samsung-Galaxy-G850a-Unlocked- Cellphone/dp/B00UCJ0IBU/ref=sr_1_1?s=wireless&ie=UTF8&qid=1441376187&sr=1-1&keywords=samsung+galaxy+alpha&refinements=p_36%3A18000-28000)

And yes, I think it's nuts to pay $100 for design, but happy wife happy life..

</comment><comment><USER27> I have used a MOTO FONE (F3)[1] for 3+ years now. I drop it terribly all the time.

It's very small and light and has advanced features like "redial" and "alarm clock".

I think it's my favorite phone I've ever had.

[1] [https://en.wikipedia.org/wiki/Motorola_Fone](https://en.wikipedia.org/wiki/Motorola_Fone)

</comment><comment><USER4> ZTE makes the best $10-$20 phone I've seen anywhere.

It is called the ZTE Zinger (T-Mobile) or ZTE Prelude 2 (AT&T)

The formal model name is the Z667 or Z667T or Z667G

Goes on sale that cheap a few times a year, otherwise $40

The screen is low resolution but you'd never know, works fine for all but the smallest text.

It is dual core and runs KitKat 4.4 so it is very smooth.

The problem is they are impossible to root and impossible to unlock bootloader. So they never took off. ZTE basically shot themselves in the foot and sold out to carrier desires.

It should be a crime in the USA to not be able to root your phone if you paid for it.

</comment><comment><USER28> This is a great example of Clay Christensen's Disruption. The cheap phone manufacturers, will emerge as big winners in the long run and push the current high-end manufacturers to either compete at their price point, or have their market share shrink dramatically.

Ref: [http://www.claytonchristensen.com/key- concepts/](http://www.claytonchristensen.com/key-concepts/)

<comment><USER29> I don't think you actually read that book. Disruptive innovation is moving a technology designed for one market, possibly a new one, into another existing market. Existing market participants focus on 'sustaining' innovations like reducing costs and inventing more expensive products. In today's environment, think using ARM processors, intentionally designed for low power draw in mobile phones, into laptops, desktops and eventually servers.

ZTE's success is just price differentiation within an existing market. Their 'innovation' is selling phone technology from 2 years ago at a discount. I don't think that even counts as a sustaining innovation, and the article notes that sales doubled but profits growing only 4 percent-- this implies huge cuts to profit margins. The same article also notes that this 'reduced margins' strategy might be subsidized by Chinese security interests.

<comment><USER28> From the author - Clay Christensen himself:

"Consider the hegemony of Detroit's Big Three—General Motors, Ford, and Chrysler. At one time, they dominated the auto industry, producing bigger, faster, safer, more comfortable cars with more and more features. But these improving products also "create a vacuum underneath them," Christensen says, "and disruptive innovators suck customers in with fewer features and a cheaper price." Toyota, Honda, and Nissan disrupted the Big Three's marketplace by introducing smaller, lighter, less safe, and less comfortable but reliable cars that needed few repairs and got good gas mileage—at a significantly lower price. Within a few years, they had garnered a large share of the market. Says Christensen: "The leaders get killed from below."

A Toyota car, is a Toyota car that was designed to be a car..it was not designed for some other purpose and re-purposed for transportation.

Reference: [http://harvardmagazine.com/2014/07/disruptive- genius](http://harvardmagazine.com/2014/07/disruptive-genius)

<comment><USER29> > A Toyota car, is a Toyota car that was designed to be a car..it was not > designed for some other purpose and re-purposed for transportation.

This explanation works cross purposes with his actual book, which uses the example of Honda, Kawasaki, and Yamaha vs Harley-Davidson and BMW. The Japanese offroad bikes are very precisely not designed for street driving, and were repurposed. It also covers backhoes vs diggers, and how people now use backhoes even for normal digging jobs. And hard drive minification. I lent out my copy to our marketing intern, or I'd pull quotes.

It also disagrees with his own quote: "Sustaining innovation makes good products better—but then you don't buy the old product. They're replacements. They do not create growth." Honda didn't just take a Ford Falcon design from 5 years ago and sell it at a steep discount. They had designs suitable for the Japanese market, that suddenly became popular when the oil embargo hit in '73\. Because Civics were a substantially different car, the Big 3 couldn't just pull their old designs off the shelves, and it's not like the market for the Big 3's used cars took off.

ZTE phones are essentially phones from 2 years ago, at market clearing (lower) price. You don't need to reach for disruptive vs sustaining innovation to explain why ZTE is gaining marketshare when simple supply & demand curves will do the trick. AFAICT, the only innovation on display here is making less profits.

</comment></comment></comment></comment><comment><USER30> I expect there won't be many other than the top Chinese brands left in a few years. Price/spec ratio is unbeatable

<comment><USER31> At one point in time people said this about Japanese electronic vendors. Most of those companies are now dead.

You can point at the Japanese automakers as a counter-point. However, I caution that comparison because they rallied around quality. In the early-70s the major American automobile makers were both terrible quality and expensive. The Japanese were able to create the holy union of both a more reliable and cheaper automobile.

Could a Chinese market sprout up to make quality and cheap phone? Probably, but there's no real issue of all the phones are expensive, but terrible devices.

<comment><USER30> In the long run, yes, when 3D printing and robotics makes manufacturing viable anywhere again. In the short term, iPhone and chinese android brands will rule

</comment></comment></comment><comment><USER32> The moto e is the best 'cheap phone' and service in the United States: [https://republicwireless.com/phones/](https://republicwireless.com/phones/)

The phone is absolutely sufficient and you can't beat the plan.

</comment><comment><USER33> Hard to justify the increased iPhone prices (and I'm a Mac user)

Especially when you prefer to buy unlocked phones

<comment><USER34> Personally, I don't see the price difference just in hardware or functionality, but in software and support.

When I buy a premium iPhone device, I pay for future years of security updates and optimizations. I also pay for kind, instant support online or in a network of certified resellers or Apple stores (if I'm lucky to be near one at least in EU).

Some people like to tinker with their devices or even have to from time to time when an app/service goes amok. I pay extra to not deal with that, because my time is worth more, then wasting it on things like that.

Now compare that to a sub 100$/€ phone.

</comment></comment><comment><USER35> For $60 I'd much rather have a 2003-vintage Nokia. The battery would last for weeks. Only thing is I can't live without Google Maps anymore.

</comment><comment><USER36> Are they running a non-Google version of Android? Because in these market share charts what I really see is just Google vs. Apple

<comment><USER37> As an app developer, that may make sense, but I don't think consumers see it that way at all. Perhaps that will change in the future, but the skins applied by HTC & Samsung, especially (Sony's & LG's aren't too overdone) make the UX completely different between brands, even if the underlying OS is the same. Add in the ability to use custom launchers and you very easily could end up with someone customizing their Android phone to the point where only they know how to use it.

<comment><USER38> I've been an Android user since forever but HTC's interface kept nagging me to configure the _HTC Experience_ after every little update, even though I'd dismissed it over and over.

It's like that pop-up wondering if you'd like to take a survey while you're entering your shipping address during check out.

It finally drove me to a cheap Windows phone.

<comment><USER39> Just get a Nexus or Sony. Vanilla Android is a much better experience. (or flash cyanogen)

<comment><USER40> Sony's experience (at least the Xperia Z3) is far from vanilla and not in a good way. They replace pretty much every app and UI component with an inferior in-house version, and add a bunch of unremovable apps to try to sell you Sony stuff.

I hear the Z5 is better though so hopefully they're getting the message.

<comment><USER41> Boy do you have that right. I love how small that phone is and the hardware is good in general, but everything they've done with the software is cringeworthy. What are the options for wiping it completely?

</comment></comment></comment></comment></comment></comment><comment><USER42> i really want a Firefox OS ZTE but it seems impossible to obtain in Canada through any of the carriers.

</comment><comment><USER43> Selling phones with plans for a subsidized (when someone can't count the total cost) is one of the biggest multi-billion dolar "scams" I've seen for a while. Here (Europe) buying a pre-paid card and a phone separatly is the most cost effective option, isn't it the same in the States?

<comment><USER44> It would depend on your use I suppose? I always found that I could never live off a prepaid system because I would blow through the data too fast.

<comment><USER45> Giffgaff offer unlimited phone data (no tethering) for £15 per month.

<comment><USER46> Which one?

[https://www.giffgaff.com/goodybags/15pound- goodybag](https://www.giffgaff.com/goodybags/15pound-goodybag)

Can only find that, 15 pound plan by giffgaff, 4gb limit on data and a 10p charge per minute for calling UK landlines.

Then there's their 'always on' which isn't unlimited, it's 6gb which to me is practically unlimited. After the 6gb your speeds get reduced to a fraction (which I like, and up to 6gb you can tether btw).

But if you look at the phone+plan deals giffgaff has, they're all slightly cheaper per month and with the phone included there's no upfront costs and it's still cheaper than buying the phone separately.

It does make sense of course if you can find a new-quality, second-hand phone, at a second-hand price, or if you travel so much that any plan no matter the pricing really makes little sense in the first place.</comment></comment></comment></comment>


H. M., an Unforgettable Amnesiac, Dies at 82 - <AUTHOR> http://www.nytimes.com/2008/12/05/us/05hm.html <comment><AUTHOR> This is kind of like finding out who Deep Throat is-- H.M. is in every psych textbook but has never been named publicly.

There are no (as far as I can tell) Google results for his name that predate his death. (! I would have said this was impossible...)

[http://www.google.com/search?hl=en&client=safari&rls...](http://www.google.com/search?hl=en&client=safari&rls=en- us&q=%22Henry+Molaison%22&btnG=Search)

<comment><USER2> Indeed, the Wikipedia page was updated to include his real name yesterday following the news of his death:

<http://en.wikipedia.org/w/index.php?title=HM_>(patient)&diff=255717057&oldid=255710373

(I'm not saying Wikipedia is an authoritative source, but it's a pretty good indicator)

</comment></comment><comment><USER3> Reading this, I acknowledge that there's some measure of good that comes out of being able to advance our understanding of how the brain works.

At the same time, the whole enterprise, a failed surgery leading to a life spent as a guinea pig, strikes me as very sad. How many of these scientists secretly thanked the heavens that this guy lost out on a normal life so they could further their own work?

How was he able to give consent to all this research without the ability to form new memories?

I think we need to keep studying the world and pushing along our understanding of it, I just hope we never stop asking these sorts of questions along the way to keep ourselves human.

<comment><USER4> _How was he able to give consent to all this research without the ability to form new memories?_

The same way any mentally-incapacitated patient consents to treatment: They or the courts appoint a relative or a guardian to hold medical power-of-attorney, and that person as well as the patient must consent to treatment.

Meanwhile, I'm not about to defend the ethical standards of mid-20th-century brain surgeons, but I will point out that H.M.'s surgeon was hardly operating outside the norms of his time: H.M. had epilepsy, which is a pretty scary disease; understanding of the brain was really poor, and psychosurgery was all the rage. Far more awful things were done in the 1950s and earlier. If you ever want to experience the real-history equivalent of a vampire film, google up the wikipedia entry on _Rosemary Kennedy_ (or, related: _Walter Freeman_ and/or _transorbital lobotomy_ ). Warning: I had nightmares for a couple of weeks. Seriously.

<comment><USER3> I don't know that I've got the fortitude to look into it just now. I once almost feinted at the wheel while listening to a truly horrifying NPR piece called "my lobotomy." <http://www.npr.org/templates/story/story.php?storyId=5014080>

And yes, by all accounts this was a case of people making the best of a bizarre situation. And I truly do hope that tangible good comes out this research if it has not already, beyond simply "we got a little smarter" which I find unsatisfying personally.

<comment><USER4> _I truly do hope that tangible good comes out this research_

No need to hope. I'm sure the H.M. case, once it became widely publicized among a new generation of doctors, did a lot to help discredit psychosurgery. Even without listening to your NPR piece (which I will _not_ do :) I'm pretty sure that that's a good thing.

</comment></comment></comment></comment><comment><USER5> This was a bit of an emotional moment for me. I'm not an amnesiac, but my memory is unusual, so I have a great interest in the research on the subject.

I just registered <http://henrymolaison.com> . I'm using it to post links to new info. about the guy. Anyone want to help out? It's wordpress, so I can easily give you an account.

<comment><USER2> I'm curious how your memory is "ususual", if you want to share. Or not, that would be understandable.

<comment><USER5> Be happy to if you send me a private email.

</comment></comment></comment><comment><USER6> If the title doesn't ring any bells (it didn't for me): _... He developed a syndrome neurologists call profound amnesia. ... As a participant in hundreds of studies, he helped scientists understand the biology of learning, memory and physical dexterity, as well as the fragile nature of human identity._

<comment><USER7> Also, H.M. is the main scientific basis for the movie Memento.

<comment><USER8> In fact Memento is pretty much the only movie that treats amnesia scientifically. In movies, when you get amnesia you forget who you are, but after that you are able to function normally. This almost _never_ happens in the real world, and when it does it is usually psychological rather than a blow to the head. Even less realistic is getting all your memories restored after a second blow to the head.

For more: [http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=53...](http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=535990)

</comment></comment></comment><comment><USER9> One of those great stories about patients who had a profound effect on an area of medical science. See also: <http://en.wikipedia.org/wiki/Henrietta_Lacks>

</comment><comment><USER10> Cases like these make me wonder where Psychology is going to get a new round of groundbreaking case studies. All the major ones were done decades ago when ethical guidelines were far looser.

<comment><USER4> Alas, so long as there are strokes, falling objects, cyclists (particularly the helmetless ones), football players, chronic drunkards, Alzheimer's patients, and wars -- i.e. most likely forever -- there will be brain damage. Many of the world's accident victims do not make such convenient test subjects as H.M., but there are more than enough of them for psychologists to get by.

The situation is much improved by the existence of modern brain imaging. It's no longer necessary to cut out a hippocampus to demonstrate that it's required for long-term memory formation.

Then there are other amazing tricks enabled by superior real-time imaging technology. I recall a study in which catheters were used to deliver anesthetics directly to individual hemispheres of people's brains.

<comment><USER10> Excellent point about the brain damage.

What I was mostly thinking about was studies like the Stanford prison experiment. Studies that require volunteers to be put in unethical situations.

</comment></comment></comment><comment><USER7> Thanks, Henry. We wouldn't be where we are today without you. You were an anonymous legend if there ever was one.

</comment><comment><USER11> A life of great importance to science. It wasn't just the idea of specialized memory, it was the idea of a specialized brain.</comment>


Ask YC: Lightweight Python HTTP server? - <AUTHOR>

We're starting a new server-side multi-platform project which will be 100% Python, and we need a Web UI for it. The software will have to run well on Linux and Windows.
This is NOT a public website, therefore the load will be quite low, within 1-5 requests a second in most extreme cases.
I am new to Python, coming from Ruby/C++ but I know about various Python web frameworks, and I'll look into all of them, but you still need to run a web server "in front" of all those frameworks.
Since we're not hosting the product (it will be sold as an installer to enterprise customers), we'd like to provide a "boxed" solution: HTTP server + Web Framework + Python Application in one tight and easily configurable package. Again, it needs to run on Windows too.
Since hackers news is heavy on good Python hackers, I figured I'd better ask for your advice. Can I bolt on Pylons or something like this on top of built-in Python HTTP server? Or shall I look around for Python-analog of Mongrel? Or "embed" something like nginx maybe? SSL is a must-have requirement.
Thank you. <comment><USER2> You can bundle a production server using CherryPy's server:

[http://www.eflorenzano.com/blog/post/hosting-django-site- pur...](http://www.eflorenzano.com/blog/post/hosting-django-site-pure-python/)

Then your users can proxy requests from a certain port to CherryPy.

The guys from silver stripe bundled their django app for a windows installer (only windows) using TooFPy:

<http://www.silverstripesoftware.com/blog/archives/51> <http://pyds.muensterland.org/wiki/toolserver.html>

</comment><comment><USER3> A little googling turns up

ASPN cookbook recipe for a simple SSL server [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/4424...](http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442473)

The MeTooCrypto package from the Chandler project <http://chandlerproject.org/bin/view/Projects/MeTooCrypto></comment>


Riffle: a high-performance write-once key/value storage engine for Clojure - <AUTHOR> http://blog.factual.com/how-factual-uses-persistent-storage-for-its-real-time-services

<comment><USER2> This is pretty similar to Sparkey[0] and bam[1]. Sparkey also comes from growing out of cdb's limitations. It supports block-level compression like Riffle does, and is optimized for accepting bulk writes. Riffle's linear-time merge behavior lifted from Sorted String Tables is a nice alternative to accepting writes at runtime. bam is cool in that it takes a plain separated values file as input, and builds an index file from a minimal perfect hash function over the input file.

[0]: [https://github.com/spotify/sparkey](https://github.com/spotify/sparkey) [1]: [https://github.com/StefanKarpinski/bam](https://github.com/StefanKarpinski/bam)

<comment><AUTHOR> There are a lot of variants on this design out there, I had seen 'bam' but not the Spotify implementation. An additional constraint we had that I didn't allude to in the post was avoiding JNI, which adds some nasty failure modes for remote installations that can be very hard to debug. This meant any C implementation was off-limits for us.

It's unfortunate that using the JVM means that some wheels need to be reinvented, but those are the breaks, I guess.

</comment></comment><comment><USER3> "While memory-mapping is used for the hashtable, values are read directly from disk, decoupling our I/O throughput from how much memory is available."

Whether you're mmap'ing or using read(), you're hitting the page cache before you hit disc, and potentially evicting the LRU page thereof. Glancing through the source it doesn't look like they're using actual "direct IO" (which, in order to be performant, would have to have its own caching layer).

That being the case, for lots of tiny reads & writes I'd expect mmap to be superior to read() and write().

<comment><AUTHOR> A caching layer for random reads where the dataset is 10x larger tham memory isn't hugely useful. If you get a hit, great, but you can't count on it.

For memory mapping to make sense you need to fetch a big chunk of data, whereas read() gets a page's worth. For the data size and read pattern described in the post, the latter is much more desirable.

<comment><USER3> It's the opposite. As I said, read() and a read into a mmap'do array both hit the OS page cache first, and will bring in ~4K of data on miss; read() also has the overhead of a system call. For tiny read/writes the advice is to use mmap. This is different if you're doing "direct io" and bypassing the OS page cache because you have your own caching layer, but I don't think they do.

<comment><AUTHOR> Whose advice? Check out RocksDB's front page: [http://rocksdb.org](http://rocksdb.org). Empirically what you're saying isn't true in my experience, rather mmap should be used when there's decent coherency w.r.t. the available memory. Without knowing what you're basing your belief on, I really can't address it.

<comment><USER3> It looks like they are making some claims about OS level bottlenecks specifically with the virtual memory subsystem. This is something I'd like to look into; all I can find is the particular quote but no explanation of where they think the bottleneck actually lies. The experience of, e.g., the SQLite folks seems to be different.

[https://www.sqlite.org/mmap.html](https://www.sqlite.org/mmap.html)</comment></comment></comment></comment></comment>


Linux on STM32 Microcontrollers - <AUTHOR> https://elinux.org/STM32 <comment><USER2> Is this just an experimental/fun exercise? The boards have 8 to 16mb of RAM and are likely more expensive than some other platform with more RAM.

Just seems like taking a good product and trying to use it in an odd/unintended way.

<comment><USER3> It does seem like it at a first glance - these are Cortex-M microcontrollers which are really not suitable for running a full-fledged OS. They don't even have an MMU, and they usually only have ~10-100KB of RAM on the chip. Plus, only some packages with >144 pins are able to memory-map external RAM chips like these evaluation boards do.

It's a very cool and impressive project, but I wouldn't use it to write an application. Besides cost, the biggest reasons to use these instead of Cortex-A chips are power efficiency and simplicity, and implementing things like process isolation in software seems like throwing all that out the window.

But on the other hand, if your device will be plugged in and power consumption isn't a huge concern, I could definitely see the appeal to having things like a Ruby interpreter or an X server running on your MCU. You could compile and deploy existing code, ideally. But I bet it would take more time to get all of that working well than it would to just write your application with an SDK and an RTOS.

Also, I'm guessing this project predates the STM32MP1: [https://www.st.com/en/microcontrollers- microprocessors/stm32...](https://www.st.com/en/microcontrollers- microprocessors/stm32mp1-series.html)

<comment><USER4> > They don't even have an MMU,

But they might have an MPU.

[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/Chdecfea.html)

<comment><USER3> The MPU does look more capable than I'd originally thought, but it still seems very restrictive for general-purpose computing. 8-16 slots and difficult data boundary/width conditions:

[http://embedded-computing.com/articles/security-and-the- cort...](http://embedded-computing.com/articles/security-and-the-cortex-m- mpu/)

Like I said, this is a very impressive project and I admire the people who were able to make it happen, but in the context of writing an application it sort of seems like a solution looking for a problem.

It reminds me of running Linux on the Nintendo DS. You _can_ , and it's a fascinating toy, but the games are written bare-metal for a reason.

<comment><USER4> If the Linux kernel on STM32 has something important to offer for the application, like quicker time to market, while meeting the requirements and hitting price targets, why not?

But yeah, if I needed to run Linux, I'd quickly pick something like Cortex A53, Cortex R52... etc. But hey, there might be a niche for Linux running on STM32.

Doing embedded (and drivers) at dayjob.

</comment></comment></comment></comment></comment><comment><USER5> I'm a much bigger fan of either bare metal or an RTOS for embedded systems; it's amazing how people will shoehorn Linux into places it doesn't belong, because Linux.

<comment><USER6> But on the other hand if you just want to collect a few sensor readings and don't want to learn an entire new stack....

<comment><USER7> If you want to collect a few sensor readings and don't want to learn an entire new stack...just use Arduino. Yes it's "learning a new stack" but honestly I bet it's easier than getting Linux to run on something it shouldn't be running on.

<comment><USER6> "something it shouldn't be running on"

That's not a law of nature though. Linus Torvalds hasn't decreed "thou shall not run this on an MCU". If it runs on an MCU that's fine. Theres a rich history of using computers for things they weren't designed for.

Id agree though, Arduino is in general the way to go, but STM32 is cheaper than Arduino and it depends what you're wanting to do.

<comment><USER2> _" STM32 is cheaper than Arduino"_

Wait, what? Did you mean the opposite?

<comment><USER4> Some STM32 chips can go below $0.50 (?). Not chips like in the article, though. Quick Digikey search came up with $0.83 for STM32L011F4U6TR (32 MHz Cortex M0+, 16 kB program memory, 2 kB data RAM, 512 bytes EEPROM).

Atmels ("Arduinos") were a bit cheaper in general, but then again it's hard to compare MCUs without application requirements in mind. Like if I needed 32 MHz Cortex M0+ class performance, comparable Atmels would be more expensive (I think).

The conclusion is, either one can be cheaper. Depends on the requirements.

<comment><USER6> I was talking dev boards not bare chips.

If you're going with an MCU that's uses Linux because you don't want to learn another platform you aren't the demographic to be buying bare chips.

Can you even get bare stm32s in hand solderable form factors???

<comment><USER4> > If you're going with an MCU that's uses Linux because you don't want to > learn another platform you aren't the demographic to be buying bare chips.

Say, you have an existing prototype running on Linux and production ready (or nearly) hardware. Porting it to another platform might delay the launch and make you go out of business.

Just playing devil's advocate.

<comment><USER2> The other choice is SOC setups that are already proven with uCLinux, like the various chips used in home routers. Also minus MMU, etc, but with dev boards that already have reasonable amounts of RAM and proven field success.

That's why I'm confused with this project. FriendlyARM, for example, already has cheap uCLinux proven boards with a bundled display, which seems to be what this is trying to be.

I'm assuming this project was just a personal _" itch to scratch"_, which is cool, but doesn't make it generally useful.

<comment><USER4> Yes, there are "better" choices, but perhaps not within product budget. Or perhaps missing some I/O feature, like high frequency ADC channels. Or any other parameter you need to optimize for. When you're making 100 000 gadgets, you really have to think about BoM.

> ... uCLinux proven boards with a bundled display, which seems to be what > this is trying to be.

I don't see any reason to think that's what this projects tries to be? Just because some dev board happened to have a display?

> I'm assuming this project was just a personal "itch to scratch", which is > cool, but doesn't make it generally useful.

Now, I don't see a need to personally use this project in production. But I don't either think it's outlandish if someone else does. In the end, nothing is generally useful in the embedded space, it's all just smaller and smaller niches.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>