Darwin's lost beetle specimen found - <AUTHOR> http://nautil.us/blog/darwins-lost-beetle-is-back <comment><USER2> TLDR;

Chatzimanolis is an insect systematist, and he is not a generalist.

He specializes in a subtribe of rove beetles called Xanthopygina.

In February 2012 Chatzimanolis was working on a revision of the Trigonopselaphus genus—a relatively small group of neotropical rove beetles contained within the Xanthopygina subtribe.

When taxonomists embark on the revision of a genus, they often discover new species. They find discrepancies:

For the revision, Chatzimanolis requested all the unspecified Trigonopselaphus material from the Natural History Museum in London.

The specimens arrived by mail in a small box. Inside the box were 24 pinned beetle specimens, all supposedly belonging to the Trigonopselaphus genus.

Among them, misidentified, was the specimen Darwin collected at Bahía Blanca in 1832.

Chatzimanolis was one of just a handful of people in the world—perhaps the only person—who could tell at a glance that the beetle was misplaced. "I was able to easily figure out that this was not Trigonopselaphus," he says. "This is something new." Then he realized it was a Darwin specimen.

</comment><comment><USER3> Is a slow relate, but stil interesting to remember how many species sit in drawers in the museums, waiting to be discovered and named. Some of them probably extinct yet and only exist as specimens. If one researcher just misplace a bug and put it in the wrong box, the specimen can be "lost" and unreachable for thousands of years.

Taxonomists able to fix this bugs, in literal and figurated sense, are vanishing quickly on the other part, both by lack of resources and new blood. To save hundreds of insects that nobody knows and nobody cares because they are just another almost identical bug, is a titanic task.</comment>


Show HN: Realtime Audience Feedback - <AUTHOR> http://feedback-225.herokuapp.com/f/hn

<comment><AUTHOR> The creator here.

You can find the source at: <https://github.com/dfjones/Feedback>

The app is built using NodeJS with express and socket.io.

I hacked this together in a matter of hours, so there are definitely things that could be done much better. However, I think this is a great proof-of- concept.</comment>


Introduction to Unix shell - <AUTHOR> http://matt.might.net/articles/settling-into-unix/ <comment><USER2> I actually got to know Unix with a little paperback reference book: [http://www.amazon.com/Pocket-Guide-Unix-Michele- Petrovsky/dp...](http://www.amazon.com/Pocket-Guide-Unix-Michele- Petrovsky/dp/076453226X) After you learn the "unix basics" the most valuable thing I found was reading the description of every single common Unix command. I'm pretty sure I also had a small pocket reference which had the same information in a more compact form, and I found myself reading that everywhere I went. Here's a similar book from O'Reilly: <http://shop.oreilly.com/product/9781565924277.do>

Here's another little guide which goes over all the general topics: [https://docs.google.com/viewer?a=v&q=cache:4oBqPlq1f7oJ:...](https://docs.google.com/viewer?a=v&q=cache:4oBqPlq1f7oJ:www.csus.edu/training/handouts/workshops/unixgde.pdf+&hl=en&gl=us&pid=bl&srcid=ADGEESihmAvYFNhgCgnMZrGG0awgUfwOAuOwe- SWuZUpZFZaP1BlyTWhkwC2kheCyc9IVwB_Uc0yH_Phfh4qvv-1C3-ctdv5l4mrupy_dZswTvxF0trsviN1V1TSM2dzN- yVxOFlnNAP&sig=AHIEtbRFddqlsuQHR_AnZW4BP4Xl8g-s-Q&pli=1)

</comment><comment><USER3> I skip a beat, but any shell user will need this at some point in his life : <http://mywiki.wooledge.org/>

So many 'I wish I'd known earlier'

Other links straight from #bash@freenode

Topic for #bash is: FAQ: <http://mywiki.wooledge.org/BashFAQ> | Guide: <http://mywiki.wooledge.org/BashGuide> | ref: <http://xrl.us/bhk9ww> | <http://wiki.bash-hackers.org/> | USE MORE QUOTES!: <http://www.grymoire.com/Unix/Quote.html> | Scripts and more: <http://www.shelldorado.com/> | New official help mailing list: <http://tx0.org/31f>

They're all deeply useful

</comment><comment><USER4> Only slightly on topic, but the choice of shell discussion always interests me.

Within the open source world, I hear about sh, bash, zsh, fish, and occasionally scsh.

It is _only_ in the academic world that I ever hear discussion about things like csh or tcsh.

Anyone know why?

<comment><USER5> IIRC, the default shell on many BSDs is tcsh. I guess it was probably csh before that in some point in history. That might have something to do with it.

<comment><USER6> Only FreeBSD. OpenBSD and NetBSD aren't that fucked up.

<comment><USER5> And OSX prior to 10.3 apparently.

<comment><USER7> Inherited from FreeBSD, of course.

Everyone complained so they changed it.

</comment></comment></comment></comment></comment><comment><USER8> > It's a near certainty that a bash interpreter will be available on a Unix > system; bash has become the JVM of the Unix world.

Don't assume this if you want your shell scripts to be portable. Follow posix standard instead.

</comment><comment><USER9> I found what seems to be a small error in your article. In the vim section it says "To switch to command mode from insertion mode, press i." I think it should say "To switch _from_ command mode _to_ insertion mode, press i."

</comment><comment><USER10> For some reason I never thought of doing this before:

            alias might='ssh firstname.lastname@example.com'

So you can do things like "might df" as he mentions. This seems super-useful if you deal with remote servers.

<comment><USER11> You might be better off using a .ssh/config file, as in this tutorial:

<http://fabien.potencier.org/article/19/quick-ssh-tip>

It saves about as many keystrokes, also works in scp, and won't clutter up your shell dotfiles.

</comment></comment><comment><USER12> [http://en.wikipedia.org/wiki/The_UNIX_Programming_Environmen...](http://en.wikipedia.org/wiki/The_UNIX_Programming_Environment) all you'll ever need?

<comment><USER13> This book is excellent!

</comment></comment><comment><USER14> I can't wait for the next articles...

<comment><USER15> This was the lecture for Matt's scripting languages class today. If you'd like a head start on the material, take a look at the materials section of the course page:

[http://matt.might.net/teaching/scripting- languages/spring-20...](http://matt.might.net/teaching/scripting- languages/spring-2012/#material)

</comment></comment><comment><USER16> _Tip: The default Bourne-shell-compatible prompts end with $ while the default C-shell-compatible prompts end with % or >. (zsh is an exception to this.) Root (super-user) prompts often end with # by default. Of course, this behavior is configurable. _

Gee, who could ever find that confusing?!

As much as I love Unix now, I can't help but understand when the author says students see the above as a "baroque regression". It just seems so ridiculously arcane when you're used to clicking on things. Of course things are much better once you're on the other side of the learning curve, but it can be a doozy.

<comment><USER17> Well, the above descriptions of shell prompts _are_ the defaults.

If you strip out all configuration files, this is the behavior you'll see.

Of course, it's better to explicitly check to see what shell you're running ('help', 'ps up $$', grep $UID /etc/passwd | cut -d: -f7').

</comment></comment><comment><USER6> >It's a near certainty that a bash interpreter will be available on a Unix system

Someone confused "linux" and "unix". Linux systems almost certainly have bash installed. BSDs and commercial unixes don't.</comment>


Compromise Bitcoin for just $1.2M - <AUTHOR> http://matthall2000.tumblr.com/post/48520639291/can-the-bitcoin-blockchain-be-compromised-for-1-2m

<comment><USER3> This may seem cheap, but there are already many, many orders out there for ASIC, and all of the factories are backed up. Butterfly Labs only recently released models that have been on order for many months (I want to say greater than 6). If you put down $1.2 million, it could be months before you got your machines and by then you would no longer control 50% of the mining.

This dollar amount is also particularly low because ASIC technology is new - most people who have put money into ASICs aren't even mining yet. Once the technology is settled in, controlling the block chain will become more expensive.

Furthermore, the number of things that you can do while controlling the block chain is actually really limited. You still can't spend other people's money. You can prevent people from spending money, but you can't make them spend money. You can double spend yourself, but if the bitcoin community was aware that someone was manipulating the block chain, they would be much more careful about accepting transactions from new wallets, and would reject all transactions from a wallet they knew was controlled by the double spender.

Furthermore, if you did take control of the block chain I personally would dump a few thousand into miners myself, to help regain control of the system. I'm sure that I'm not alone, and the act of bitcoin users simply 'fighting back' may be enough to minimize your control of the market.

And finally, as other people have stated, you can always change the hashing algorithm. Most people use 1 bitcoin client. In fact, this client once had an update that caused an error and forked the block chain and allowed at least one person to double spend $10,000. In the event of a major crisis, there would most be enough bitcoin users willing to fork the block chain that you could indeed get a new hashing algorithm designed to be incompatible with the attackers hardware. The choice is between that and watch your 'distributed' currency fall under the control of a tyrant.

Someone taking control of the mining process IS a risk, and there are some powerful things you can do with that (like mine 100% of all the new bitcoins, taking control of the supply, and double spending, and rejecting transactions by others), but it would probably take a lot more than $1.2 million dollars because people would fight back, and you are still at risk of the rest of the community forking away from your control. That said, you could still do terrible damage and the price would probably plunge, and you may be able to double spend millions of dollars before enough people noticed to start rejecting your transactions. (are there even millions of dollars worth of things you can buy? and would you have to worry about a government getting involved because you committed financial crimes?)

And even if you manage to maintain control, all that will happen is people will stop using bitcoin until you let up. It's much like a DDOS. It takes power (electricity) to maintain that much computation, and the longer you maintain control, the less bitcoin will be worth.

Edit: I want to add that the scariest attacks only happen at 50% control. At 40%, you can only double spend -sometimes-, and I don't think that you would be able to block transactions at all. Furthermore an organized network (and there is much debate about how organized bitcoin could get, after all it is designed to be distributed) could undo any double spending and you would be limited to slowing bitcoin down. At 20% market power, the probability of you achieving a double spend or undoing some transactions is very small.

<comment> bitcoin-fool I agree it would take a long time and be unlikely for a single ASIC-purchasing party to reach 50%. Another organization, an ASIC-datacenter-hoster, could do it.

BFL has an "ASIC hosting program" where those purchasing more powerful BFL machines can put their machines in an affiliate datacenter. There is real incentive to have one's ASICs hosted there, especially given that power requirements are 6-7 times originally forecast (one needs commercial space to run these now), and that this new hardware has an unknown failure rate and a real tangible cost to not working. The hosting center provides direct maintenance from BFL personnel, so one's machine shouldn't be down for more than a day or two for any failure. _I wouldn't be surprised if a majority of BFL ASIC purchasers opt to host their hardware in this datacenter._

The hosting program could lead to the mining pool (the default option is for your BFL ASIC to join the mining pool) at the datacenter having > 50%, under complete control of the affiliate datacenter.

<https://news.ycombinator.com/item?id=5584783>

</comment></comment><comment><USER4> I don't expect this to happen, ASICs will be pretty widely distributed before anyone can pull this off. However there is a contingency plan for when this happens: switch the hashing algorithm (for example to scrypt, or something memory hard w/ lots of random flow control). This puts all ASICs out of the game at once. Miners will not like it, but if the other alternative is a non- functioning currency, they will likely cooperate.

<comment><USER5> > switch the hashing algorithm

OH boy now _this_ is interesting -- to an outsider like me, explain who would decide this? Some central committee? The source-code "custodian"? Will BTC fork at that point so every holder can "vote with their (pardon) dollar" but would also need to bet on everyone else's choice?

<comment><USER6> Changes to the Bitcoin protocol can be ratified by a majority of miners, in the same "longest blockchain" method.

<comment><USER7> This is a common misconception, I think. If you try to model the protocol economically, it's pretty clear that it's a majority of currency holders (what the core developers call an "economic majority"), not a majority of miners that matters in determining whether a protocol change is valid.

Exercise for the reader: determine whether these sets are different in a meaningful way.

<comment><USER8> > This is a common misconception, I think. If you try to model the protocol > economically, it's pretty clear that it's a majority of currency holders > (what the core developers call an "economic majority"), not a majority of > miners that matters in determining whether a protocol change is valid.

Actually, its neither, if you really think about it. Currency users (in exchange) are more important than either miners or holders (with the caveat that you need some number > 0 of miners to validate exchanges) to whether a protocol change has economic effect, but once some group adopts a protocol change, what you have is a fork into two separate currencies until a consensus is achieved.

Passive currency holders have little driving force in this; currency users are the main driving force, because wherever its being used is where it will have value. Miners have some force because without some of them, the system collapses.

And among currency users, the ones that matter the most are the ones that _accept_ bitcoin for goods and services, not the ones that spend it. (In the "steady state" those should be approximately the same, but as long as mining is still producing coins you can have miners/spenders that aren't accepters, and even in the steady state you could have people who inherit hoards and slowly deplete them as users that aren't accepting.)

</comment></comment></comment></comment></comment><comment><USER9> In comparison, Amazon EC2 offers GPU clusters for $2.10000/hr [1]. Each cluster contains 2x M2050 Fermi cores [2] which each put out ~80MHash/sec [3].

To get the requisite 64686 GHash/sec, you'd need to spin up 404287 of these things, which costs you $849000/hr. This is of course assuming Amazon has 400000 instances of the GPU compute clusters.

The cheaper alternative is to utilise spot GPU instances, costing only $0.346/hr [4]. At that price, i's $139900/hr or so. I am willing to bet that they do not just have 400000 spare GPU instances laying around unused, however.

All this was purely academic, but it kind of amuses me that for a theoretical $140000/hr, you could hyjack bitcoin as it is currently.

[1] <http://aws.amazon.com/ec2/pricing/>

[2] <http://aws.amazon.com/ec2/instance-types/>

[3] <https://en.bitcoin.it/wiki/Mining_hardware_comparison>

[4] <http://aws.amazon.com/ec2/pricing/#spot>

<comment><USER10> "To get the requisite 64686 GHash/sec, you'd need to spin up 404287 of these things, which costs you $849000/hr."

Really, I don't think even Amazon has enough of this hardware. And AFAIK these (GPU clusters) are not virtualized.

Makes me wonder what happens if you have a cost advantage in taking the cheapest PC hardware and plugging high-end GPU cards (beyond ASICs)

</comment></comment><comment><USER11> Keep in mind that a plan like that would take, at best, half a year to put in place. In that time the amount of ASICs in existence will already be far higher than it is today (I would guess at least three times what it is at the moment.)

<comment><USER12> 3x? More like 300x, I'd say. Once the first few roll out of BFL these things will be coming online as fast as you can say "money press".

<comment><USER13> That assumes BFL won't just run off with all the money.

</comment></comment></comment><comment><USER14> If the bar is that low, this does suggest that, contrary to some conspiracy theories, governments aren't really out to destroy Bitcoin, since they could've done so by now if they had really wanted to.

<comment><USER15> There's other things they could be doing.

Bitcoin isn't intrinsically anonymous, so maybe they're just keeping an eye on anyone not being anonymous.

Wait until someone sells polonium or uranium on Silk Road to see if Tor / Bitcoin stand up.

<comment><USER12> Correction: bitcoin is only "not anonymous" if the transaction history network contains a contact point with the physical world, that is, if some transaction is associated with a physical good shipment or traditional world identity.

<comment><USER15> Bitcoin is not inherently anonymous. Users have to do stuff to be anonymous when using Bitcoin. To say otherwise is wrong and dangerous.

([http://www.newscientist.com/blogs/onepercent/2011/07/bitcoin...](http://www.newscientist.com/blogs/onepercent/2011/07/bitcoin- is-not-inherently-anon.html))

(<https://news.ycombinator.com/item?id=2800790>)

(<https://en.bitcoin.it/wiki/Anonymity>)

([http://anonymity-in- bitcoin.blogspot.co.uk/2011/07/bitcoin-i...](http://anonymity-in- bitcoin.blogspot.co.uk/2011/07/bitcoin-is-not-anonymous.html))

</comment></comment></comment></comment><comment><USER16> AFAIK you don't need much computing power, you just need to be lucky to be the first one to solve the problem and create a new hash. I case you have lot's of tries even a 0.05% chance every 10 minutes might be enough.

Not sure if i make a mistake here, but it seems to be easy.

0,5 < (n choose 1) * (1-0.0005)^n

0,5 < 1 * (1-0.0005)^n

log(0,5)/log(1-0.0005) < n

1385.95 < n

13860 minutes < 10 days

So a 50% chance in 10 days. If you have a 0.05% of the computing power of the whole network.

</comment><comment><USER17> I'm not sure there's $1.2M worth of ASIC hardware made yet. Also, for that amount of money you could do a lot of malicious things, even to traditional banks.

<comment><USER18> "I'm not sure there's $1.2M worth of ASIC hardware made yet."

I am pretty sure a large government could make its own ASICs...

<comment><USER19> You don't think the NSA could free up a few machines and have a couple of Terahash/Sec available in a weekend?

</comment></comment></comment><comment><USER20> There is probably no business case for such an operation. To benefit from an extreme price crash you either have to short bitcoin or buy a ton of stuff with it. In the latter case it is hard to imagine a merchant honoring such orders if he is not convinced the blockchain is sound.

As for shorting bitcoin... It's certainly not impossible. But shorting a few Million of Dollars of Bitcoin? If this is done in any kind of trading account (without the money being physically in the hand of the attacker), the trading institution would probably be out of business because of the price drop anyway, before paying the profits to the attacker...

For everyone else... You shouldn't have more than 20 BTC on hand anyway. Preferably a lot less, depending on the rest of your portfolio. In these cases any price drop isn't going to wipe you out and the network resumes normal operation.

</comment><comment> bitcoin-fool See <https://news.ycombinator.com/item?id=5585166> for information on BFL's hosting program. It's likely that BFL and affiliate datacenter personnel will control > 50% of the bitcoin hash rate at some point. Here's my comment on that thread ...

\--

BFL has affiliate data centers where those purchasing the more powerful BFL machines can have their systems hosted, for a fee. The default option: "Your hosted units will be added to a mining farm and you will be paid out regularly based on their collective output." Datacenter and BFL personnel will be monitoring the machines for defects and maintaining them. The hosting option makes sense for new untested hardware like this ...

So, it's likely the BFL datacenter mining pool will control > 50% of the bitcoin hashrate at some point.

</comment><comment><USER21> And of course you forgot that the difficulty would increase?

Who sells ASICS 66GH for $1250? That page is outdated.

Avalons are going for 72BTC that's over $9000

<comment><USER22> Well, the difficulty increase wouldn't stop an attacker having >50% computing power. Only switching the algorithm would (assuming the attacker would use ASICs)

</comment></comment><comment><USER23> This would not disrupt Bitcoin for too long. I'd just move the blockchain to a different algorithm and BOOM your ASICs are worthless and Bitcoin will still go on.

$1.2M will shutdown Bitcoin for, at most, a couple days... and then you're left with a bunch of useless ASICs.

And all that assuming that nobody else will get ASICs, which will make the attack more expensive.

It's just not worth it.

<comment><USER24> Don't you have to get all other bitcoin users to also migrate over to this new algorithm?

And even if it's just down for a couple of days, that's terrible. Bitcoin is still pretty small in the grand scheme of things, but imagine if regular money stopped working for a couple of days.

<comment><USER23> Miners WILL switch (for their own benefit). Something like this has happened before[1] (though the mining algorithm didn't change) and the community did cooperate. Some miners will be happy about it, specially the ones with GPUs which will be thrown off the game once ASICs arrive (and will get back in the game once ASICs are killed).

Well, if I can get a government to spend $1.2 M just to shutdown a currency for a couple days, I guess _we won_ (specially hardware manufacturers).

Also: Bitcoin will never replace regular money, and it isn't meant to.

IMHO this attack will not kill Bitcoin, only ASICs.

[1] <http://bitcoin.org/chainfork.html>

<comment><USER25> The algorithm was not replaced, then it wouldn't be BitCoin anymore.

[https://en.bitcoin.it/wiki/List_of_alternative_cryptocurrenc...](https://en.bitcoin.it/wiki/List_of_alternative_cryptocurrencies)

<comment><USER23> It will still be Bitcoin, with a different algorithm... Bitcoin is not just a protocol and some algorithms behind it.

Bitcoin is a community and a currency. Your Bitcoins will still be called Bitcoin, you'll have the same wallet and the same number of BTC in your accounts. The webpage will still be www.bitcoin.org and we'll talk in #bitcoin as we used to do.

Changing Bitcoin to scrypt will not magically turn Bitcoin into Litecoin.

This scenario has been envisioned before. Nothing new here. Bitcoin will prevail.

<comment><USER26> I think the fact that Bitcoin is a community is its main problem. Miners have acted altruistically a few times in the past, but as the pool grows, getting them to do anything beyond the Nash Equilibrium will get progressively harder.

Bitcoin may prevail, but it will have to go through a painful 2.0 evolution at some point.

<comment><USER23> Economic majority will ALWAYS win by definition.

<comment><USER26> And a smart agent with enough resources can lead the economic majority like lemmings down a cliff once it reaches a certain size and becomes dumb.

While your miners are mostly hobbyists that you can access via Skype, it's easy to say "hey guys, let's stop this chain and switch to that other one." Once you have large companies with dedicated ASIC racks in the game, and any change that could impact the short-term bottom line has to go through four levels of management, you are SOL.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> That's assuming you could get your hands on ASIC hardware. None of it has shipped to customers yet, and once it has, the difficulty will skyrocket.

<comment><USER28> It has but only that first batch. The author also makes the mistake only that first batch sold at they rate the new batch is priced at 75btc.

Interesting to know how much it would cost to build your own machines only reasonable solution at this time.

<comment><USER29> > _Interesting to know how much it would cost to build your own machines only > reasonable solution at this time._

Finger in the air calculation: $3-4M. Assumes knowledgeable designers, and good ops people with decent offshore assembly experience.

None of this is particularly difficult from the standpoint of a VLSI. The issue is that profitability is questionable: If you're successful, you pretty much destroy the economic niche that forms your customers.

<comment><USER29> Whoops: s/VLSI/VLSI designer/

</comment></comment></comment></comment><comment><USER30> If you wanted to damage/degrade BTC with $1.2 million I think the "smart money" wouldn't be investing in the custom hardware to compromise it - <USER2> instead to flood the markets with liquidity. BTC is still so thinly traded that a million dumped in pieces could have a serious destabilizing affect. Not that reducing price was the actual subject of the topic but...

</comment><comment><USER31> I think longest blockchain attacks only apply to double-spending, so you still can't "compromise" coins that are not your own

<comment><USER32> If a few agents start double-spending, that creates a strong disincentive for anyone to accept bitcoin at all, which can doom the entire currency.

</comment></comment><comment><USER33> Assuming nobody else buys any of this hardware too. That's how I see this anyway. All of these theories assume that nobody else is going to try and do the same...</comment>


Apple Seems to Be Losing PR Battle Over Unlocking iPhone - <AUTHOR> http://recode.net/2016/02/22/apple-seems-to-be-losing-pr-battle-over-unlocking-iphone/ <comment><USER2> And here we have a perfect example of when the crowd doesn't always offer wisdom. While it would be great to hear the majority of American citizens would be far more hesitant to capitulate on privacy and security in the face of that spectre, terrorism, these findings are wholly unsurprising.

</comment><comment><USER3> I have been incredibly disappointed at the coverage on NPR, which often does a good job with complex subjects but has completely blown their coverage of the Apple FBI story--reducing it to simplistic sound bites.

</comment><comment><USER4> Perhaps it shows how flawed the so called online polls are. They obviously don't represent the fact, nor the concern of the majority; rather outputs the interest of the highly motivated biased group.</comment>


Lunar volcanism produced a transient atmosphere around the ancient Moon - <AUTHOR> http://www.sciencedirect.com/science/article/pii/S0012821X17304971?via%3Dihub#! <comment><USER2> On fiverr you can buy quite decent illustrations from $5 and up. It would work well for so many scientific articles. I bet their readers would appreciate great articles like this accompanied by drawings and other illustrations instead of just text and numbers and primitive graphs like here. Researchers often work in teams for years or months costing hundreds of thousands or millions in equipment and salaries. A few hundred bucks would make their work much more interesting and accessible. I wonder how many more would actually read the articles if they were illustrated. My guess is a factor 10 or more, even among their peers.

<comment><USER3> Many universities have news services whose job is to do make popular articles with cool pictures. It's usually not a skill scientists are trained in.</comment></comment>


Show HN: Rust, ARM Cortex M, and a Generated HAL - <AUTHOR> http://jamesmunns.com/update/2016/09/26/teensy3-rs.html <comment><USER2> I ran into some of the folks behind this at RustConf; they're doing some really interesting work. They're running Rust on bare-metal with a minimalist embedded OS, and providing easy ways to get access to twiddle hardware, without having a dozen intermediate layers between your code and that hardware.

<comment><USER3> With the way rust is developing, it could nudge C as the main programming language for embedded. Kudos this the team.

<comment><USER4> Good luck with that. There ain't no way rust is getting a misra complaint setup anytime soon. Not to mention, the current vendors are entrenched in their ways to ridiculous levels. Companies like keil for example don't bother to have a Linux complaint tool chain.

<comment><USER5> I do embedded development (for 8051 8 Bit micro controllers), so IMO it has nothing to do with entrenched, and everything to do with with the following (at least from my point of view).

But before i explain my reasoning, i will the define the term 'embedded development' for this comment as follows: \- No gigahertz (not even close). \- No multi core. \- No giga- and no megabytes of RAM. \- No OS. \- Micro second respond time, but truck loads of computation. \- No ARM processors.

So here goes.

1.In my world memory safety is simply not an issue, because we don't allocate dynamically. So neither the borrow checker nor lifetimes are an advantage.

2.The micro controllers are piloting a complex machine with all kinds of actuators and sensors. So the code is actually (and that is really a rough generalization) a big state machine. So the functional elements of Rust don't help that much because, although functional programming and state machines are doable, the code is IMO far from ..... let's say elegant.

3.If you do real time systems with micro second respond times (like i do), you really want to know what kind of code will be generated from a specific line of code just by looking at it. Maybe experienced Rust developers are able to do that, input would be appreciated here (looking at you Steve ;-).

4.I'v read about the guaranties the Rust developers give regarding stability of features, breaking changes etc. This combined with the (at least in this domain) neck breaking speed of development (i see the Rust community already talking about optional GC) is pretty much a show stopper in this domain. Why? Because (warning generalization coming) most embedded developers are already dealing with really hard problems, they simply don't have the time to keep up. Furthermore, if you have code that needs to be not only compilable, but also functionally working after twenty years (yes you read that right), you do not want things developing that fast. Remember, this kind of code is keeping all the infrastructure we all rely on working.

5.Rust is a complex language to build a compiler for. You will have to persuade Keil and friends to invest the time and money to do that. And no, LLVM is no option, because it does not target enough architectures.

6.Rust is perceived as too complex by my peers. Don't say it is easy. It is may be easy for you or me, but not for everyone. And you know, those people are valuable too and need a job too.

So there you have it. Rust just does not buy you enough in that kind of environment.

<comment><USER6> Embedded dev here too. I worked mostly on bigger (processing power-wise) systems. Actually as big embedded as you can find (PC-level performance), I toy with smaller ones as a hobby. :)

1\. That is kind of true but only in tiny systems. Having some lists (with proven bounded size etc.) is still often necessary, where pointer invalidation is a problem. But even tiny embedded systems will grow in processing power, get SMP etc. - it's just a matter of time. And there is way more that Rust has to offer.

2\. Rust is not functional programming language. Rust allows to write parts of the code in functional fashion and the resulting code is very efficient (because it's functional and can be optimized well), so you can employ it when needed. The thing is: C does not support functional programming well, so you write code imperative way. But imperative ways are neither inherently faster, nor easier. In many cases functional style code is both easier to understand _and_ generates better code. Sometimes because it's easier to understand the code, you can spent more time optimizing the performance, instead of fixing bugs.

3\. Actually after couple of years writing Rust code, I can predict the asm generated by `rustc` almost as well as C compilers. Abstractions provided by rust map very directly to CPU instructions. Also, there have been numerous times when working on C code, I had to give up on optimal runtime performance because lack of C expressiveness, safety and sanity concerns. Rust static dispatch through generic traits, combined with optimizer and LTO does wonders, really. People just need to overcome the bias that abstractions are costly.

4\. GC in Rust is going to be optional and "manual". Just like `Vec` does dynamic allocations, and you can just not use it. The "functionality working after twenty years" is IMO a wishful thinking. Real C code is ridden with bugs, especially undefined behaviors dependencies, that after 20 years compilers tend to expose rather easily as they got better at (ab)using them. UB is actually my biggest problem with C and C++. I have been working with very smart people, following all the standards, using static analysis, carefully testing and reviewing and we still were hit quite often with C-quirkiness and UB. It's common in embedded to pin the version of the toolchain for the precisely that reason: changing a toolchain version can expose new bugs in your code (not to mention bugs in the compiler, but that's another story). Also, the building system: good luck running `make` (or something like it) on a project from 20-years ago.

> Remember, this kind of code is keeping all the infrastructure we all rely on > working.

A lot of human suffering had to been thrown at the problem to make C code do the job there, and countless list of bugs in critical widely-deployed software tells much about how well it worked. It is sooo relieving, when you don't have to debug weird bugs due to UB, data races, pointer invalidation, memory allocations bugs, and you can actually express your code in a way that is both fast and impossible to mis-use.

However I agree that Rust is, from serious embedded work perspective, completely immature.

5\. Agreed. Not to mention that in some application the compiler (and all toolchain elements), as well as the compiled software needs to be certified. Good luck building a certified Rust compiler. :)

6\. That is true. Rust is way more complex, and many people does their job well using tools they know, goes home and have better things to do then learn new programming languages.

IMO. Rust won't overtake neither C, nor C++ places any time soon (let's say 20 years), but for some applications and some people is going to be very valuable proposition. There are some things that C just completely sucks at: it's ridden with UB instanity, lack of expressiveness, worse performance (yes, I really believe C performance is going to be worse than Rust one due to aliasing and static dispatch), lack of integrated building system (yay cargo!) which to this day makes it really hard to reuse code. As micro-controllers become more and more powerful (SMP!) and bigger-embedded systems more popular, Rust might be gaining some traction.

<comment><USER7> > People just need to overcome the bias that abstractions are costly.

C++ (which has a lot of zero-cost abstractions) tried to shift this bias since several decades with very limited success. Languages like Nim (or even Matlab with Embedded Coder) have the advantage there's intermediate C output that can be manually inspected for unintended runtime abstractions.

<comment><USER8> The irony is that C was in that spot on the 80's and early 90's, but somehow it became so ingrained in the industry that people forget how it was like when C only mattered to UNIX workstations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Sweet! The Teensy might be the most accessible ARM dev board right now, so this is great news for embedded rust.

Ever since Rust was announced, I've been eagerly awaiting it's practicability as a replacement for C/C++. The only place you really _have_ to use either of those these days is embedded systems, so this is kind of the final step towards getting modern languages in every subfield of software development.

<comment><USER10> > The Teensy might be the most accessible ARM dev board right now

Disagree. It's nice enough as an Arduino-alike, but it doesn't have any debugging capabilities -- the only commands exposed by the loader[1] are "write block" and "reboot".

As an ARM development board, I'm much more a fan of ST's Discovery series[2]. Most of their boards are in the $10-$20 range, and they all include a USB- based programmer/debugger compatible with open-source tools.

[1]: [https://www.pjrc.com/teensy/halfkay_protocol.html](https://www.pjrc.com/teensy/halfkay_protocol.html)

[2]: [http://www.st.com/stm32discovery](http://www.st.com/stm32discovery)

<comment><USER11> I second this. The STM32 discovery series boards are really great for messing around with!

</comment></comment></comment><comment><USER12> im trying to learn rust right now. its really hard

<comment><USER13> Just so you know and hopefully are encouraged--learning C is really hard, too. Most people just never _actually_ learn it.

Rust makes you come to grips _immediately_ with the things that will bite you in C later.

Keep at it. It's a continuing process regardless of language.

<comment><USER14> Knowing C, and liking Rust and struggling to learn it. I think Rust is more like C++ than C in the type of difficulty of learning.

C is more like chess: the rules are not that complicated and you can figure out how to write code. It will be a long time to learn to write good C code.

With Rust it is hard to figure out the rules, even to get start writing code. They are more like complicated board games with lots of rules to learn.

As an aside, after I wrote that it reminded me of this map: [http://goldns.ru/cppmap-2012.png](http://goldns.ru/cppmap-2012.png) C++ devs will get all the inside jokes there, Alexandrescu's castle, curiously recurring template, exceptional swamps and others...

<comment><USER15> Rust seems very much like modern C++. Borrowing, references and the like have nearly direct analogs to C++ references, unique_ptr and other STL constructs. Except the compiler enforces them with (my opinion) relatively more clear error messages most of the time and in some cases the syntax is actually clearer (others not necessarily).

My biggest struggle so far is overcoming the differences in the implementation of generics. I have yet to "fight the borrow checker," but the generics implementation is something of a hurtle for me.

</comment></comment></comment></comment><comment><USER16> Woo-Hoo! This is super exciting! Thanks!

</comment><comment><USER17> Dope !

</comment><comment><USER18> D seems like an easier language than Rust. It's too bad D didn't catch on.

<comment><USER19> D is garbage collected, which rules it out for embedded systems.

<comment><USER8> Really?! Java doesn't have any problems with that.

[http://www.ptc.com/developer-tools/perc](http://www.ptc.com/developer- tools/perc)

[https://www.aicas.com/cms/en/JamaicaVM](https://www.aicas.com/cms/en/JamaicaVM)

[http://www-03.ibm.com/software/products/en/real- time](http://www-03.ibm.com/software/products/en/real-time)

The problem with D's garbage collector is that it just a very old implementation, with performance problems and they lack contributions to improve it.

<comment><USER19> Those are all running on RTOSes such as RT Linux on an X86/PPC or full ARM platform.

Those won't run on an ARM Cortex M chip, where your current options are effectively ASM, Ada, or C if you want high performance and low price and power consumption.

<comment><USER8> They also run bare metal.

Do you want commercial products specifically targeted for ARM Cortex M chip with GC enabled languages?

Bare metal Oberon compilers for ARM Cortex-M4 and Cortex-M3:

[http://www.astrobe.com/default.htm](http://www.astrobe.com/default.htm)

MicroEJ developed in a mix of Java and C.

[http://www.microej.com/products/device-software- development/...](http://www.microej.com/products/device-software- development/microej-os/)</comment></comment></comment></comment></comment>


Accessurl – Share accounts without giving away your password - <AUTHOR> https://accessurl.com/ <comment><USER2> Basically cookie/session hijacking as a service - what could go wrong?

</comment><comment><USER3> is it just me or does this seem like a bad idea?</comment>


How Bacteria Eat Penicillin - <AUTHOR> https://www.the-scientist.com/?articles.view/articleNo/52456/title/How-Bacteria-Eat-Penicillin/ <comment><USER2> "Life finds a way." ~ Some dude from Jurassic Park

IMO we should ban antibiotics use for farmers in the amount they use it today (probably overall, they shouldn't feed antibiotics just to promote growth) and get into research for phage-therapy.

Eventually we will have to face the inevitable superbug that lives in common desinfectant like a warm petridish. Probably already exists even.

Atleast the farmers can make more profit in the meantime.

</comment><comment><USER3> this whole fear "antibiotic super resistance bug" doomsday fear is narrative is totally out of control, where now doctors are resisting prescribing totally safe and proven penicillin based drugs, which is causing more damage then good. The "super bug" threat is not from penicillin based resistance, but this clarification is nowhere to be found in the mainstream media. This article and the researchers are totally out of character with what the problem is. It's gotten so bad that the WHO has now put out an advisory to say it is OK to prescribe amoxicillin because people are getting really really sick from doctors worried about this irrational fear because they believe in these lies.

<comment><USER4> Not to mention low dose antibiotics are sometimes very therapeutic. When the effective medicines become widespread big pharma has incentive to spend as much money marketing against them as it does to actually develop better stuff. Antibiotics never worked against biofilms anyway - and many of the cases of so-called evil bacteria are actually just full fledged biofilms.

<comment><USER5> A number of antibiotics penetrate biofilms just fine: [https://academic.oup.com/jac/article/65/9/1955/722668](https://academic.oup.com/jac/article/65/9/1955/722668)

Ciprofloxacin would be an awesome drug if it didn't promote the development of active C. difficile infection.

<comment><USER4> "...were grown on black, polycarbonate membranes placed on tryptic soy agar plates..." So ya, definitely not a walk in the park to eliminate the bacteria in the biofilms of grandma's old infection! I never really got the incentive for smart people like you to post sorts of "see, it's solved, we're so advanced" replies online. It makes sense with technology because that is easy to reference and prove one way or another. But implying something is solved in biology is very often problematic, isn't it?

<comment><USER5> Your objection doesn't really make much sense.

The description of how the biofilms were grown is precise because it's a peer- reviewed paper. That it uses big words doesn't mean it's complex. "We grew the biofilms on black plastic with food" is all that sentence says.

That's also _growing_ the biofilm, not penetrating it, which is what you seem to be under the impression it's referring to.

I also didn't claim that "It's solved." Biofilms are a bitch. But claiming that antibiotics don't work against bacteria in biofilms is _actively wrong_. "Hey, your information is wrong, some broad spectrum antibiotics penetrate biofilms" isn't claiming the problem is solved, just that someone has made a factually incorrect statement.

Which is, you'll note, also why I noted that Cipro has other drawbacks. Do you think I would have done that if I considered the problem "solved"?

To use a programmer example, if someone said "Python's 1-based indexing is a bad idea", would you chew someone out for replying "Python is 0-indexed" and linking to the language description?</comment></comment></comment></comment></comment>


How To Determine Market Demand For Your Startup - <AUTHOR> http://rahulvarshneya.com/how-to-determine-market-demand-for-your-startup/

<comment><USER2> It's a good article and seeing Google there was a bit of a surprise.

Maybe it's overlooked by people but I guess can be handy.</comment>


How Apple Dodged a Sun Buyout - <AUTHOR> http://www.eweek.com/c/a/IT-Infrastructure/How-Apple-Dodged-a-Sun-Buyout-Former-CEOs-McNealy-Zander-Tell-All-251679/

<comment><USER2> Interesting view of how Linux would have worked out, had Sun done the right things with x86 processors.

But this strikes me as denying Sun's position, as per Clayton Christensen's "Innovator's Dilemma". Sun passed on a number of opportunities for disruptive innovation. For example, the folks who started Auspex came from Sun, I think (and in turn, Auspex missed the boat that took Network Appliances away). Sun had a processor that was pretty darn good, when intel released the 80386. Let's face it, SPARC architecture still makes a lot more sense than x86. And Sun kept up for a surprisingly long time. How many people did Intel have squirrelling away at the x86 architecture? How many people did Sun have on SPARC? I imagine it was 10x less.

I think suggesting that Solaris could have taken the place of linux in the market is very much wishful thinking. Now, if Sun had listened to Larry McVoy's Sourceware Operating System Proposal in '93 (<http://www.bitmover.com/lm/papers/srcos.html>), that might have made a big difference.

<comment><USER3> I agree. Sun was dependent on selling proprietary hardware at $20k a pop. Even if they had launched a commodity-hardware line, no one would have paid the prices necessary to support a corporate structure built on high-end sales. SGI tried, and it didn't go so well for them.

<comment><USER4> Sun didn't even need an expensive salesforce to sell them - we were a government research customer in the 90s and had all our orders for Ultra sparcs cancelled - Wall St were paying above list price for any that Sun could build

</comment></comment></comment><comment><USER5> Assuming that google would be running on solaris "if only we had..." strikes me as being a bit myopic. I think it's more likely they'd be running on freebsd.

</comment><comment><USER6> Talking through his hat on a couple of these. Netscape was not open source, and there's a huge gap between distributed computing and cloud computing.

<comment><USER4> sun did have an early grid computing system - it was academic access only and based on RPC but all the bits were there

</comment></comment><comment><USER7> Sun never committed to the low-end. Their sales droids wanted to sell to the enterprise and big .edu .

Of course, now Linux is what enterprise and big .edu are running... I am told that Solaris has a tenacious hold on certain financial shops and banking, and other niches as well.

It is a shame, their $995-list 1U servers (V100, Netra X1) use only 70W including powering 2 hard drives. Had they kept up and released a follow-on series with SATA and more RAM expandability, they would be perfect for cloud applications.</comment>


How a Church Deacon Found the Biggest Prime Number Yet - <AUTHOR> https://www.nytimes.com/2018/01/26/science/prime-number-mersenne-church.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science&region=rank&module=package&version=highlights&contentPlacement=3&pgtype=sectionfront <comment><USER2> tldr: he set up computers to participate in the Great Internet Mersenne Prime Search; obviously the computer result has no relation to that person's religious role. In other news, the NYT are minor-league trolling.

<comment><USER3> You could say that, as far as trolling is concerned, the NYT is a PRIME suspect. XD</comment></comment>


MacOS Sierra - <AUTHOR> https://itunes.apple.com/us/app/macos-sierra/id1127487414 <comment><USER2> I'm wary of upgrading to the first point release of new OSX releases. There's always something that seems to break my dev environment.

<comment><USER3> broke my homebrew and gave me weird warnings in tmux :(

<comment><USER4> dang sorry to hear that man :/ that's exactly why I don't want to upgrade just yet.

</comment></comment></comment><comment><USER5> I guess it's time to roll the dice and see how much of homebrew and my build environments break.

<comment><USER3> Dice rolled, lots broken (it seems). Now to start trying to fix things...

</comment></comment><comment><USER6> None of the features I see really interest me, it's just stuff that integrates with their other services none of which I don't use anyways.

</comment><comment><USER7> I'm really confused. There already were two posts today regarding the new MacOS release:

[https://news.ycombinator.com/item?id=12541081](https://news.ycombinator.com/item?id=12541081) (App Store link)

[https://news.ycombinator.com/item?id=12541630](https://news.ycombinator.com/item?id=12541630) (product announcement)

</comment><comment><USER8> If you're using a Razer mouse, don't upgrade :) Causes kernel panics and a reboot loop (remove RazerHid kext to fix and launchctl remove all com.razer stuff, then replace Synapse with something like SteerMouse).

This was sure a weird one - everything works fine until you start moving a mouse at which point you catch a kernel panic.

</comment><comment> a-no-n List of petty annoyances:

\- Can't reinstall haskell-stack from Homebrew.

\- Karabiner can no longer remap keyboard keys, and seems to be no longer being maintained because development moved to another project.

\- CPU is stuck at 100% doing some sort of "optimization"

\- Macs Fan Control stops/starts controlling fans randomly

</comment><comment><USER9> Current discussion: [https://news.ycombinator.com/item?id=12541081](https://news.ycombinator.com/item?id=12541081)

</comment><comment><USER10> I've had 0 issues with Homebrew since upgrading at beta one. The only reason it broke with last years OS update to 10.11 was because of rootless.

</comment><comment><USER11> Also note: They removed support for PPTP vpn. While good for security may screw you if that's all you can use.

</comment><comment><USER12> Well, this broke Junos Pulse and Outlook 2013 sending

</comment><comment><USER13> Do I need it? Not sure.

Do I want it? Way ahead of you!

<comment><USER13> Update: Outlook Unclear

[https://puu.sh/rikNL/c0ecb8bcff.png](https://puu.sh/rikNL/c0ecb8bcff.png)</comment></comment>


Conway's Game of Life on Rails with Stimulus.js - <AUTHOR> https://game-of-life-turbo.herokuapp.com/ <comment><AUTHOR> This is a variation of the Game of Life, implemented with Ruby on Rails, where each generation is requested via AJAX and gets entirely computed and rendered server-side so that the browser only needs to replace the grid in the DOM. On top I sprinkled some Stimulus.js to add just enough behavior to make it shine. If you look very closely you will also see Turbolinks in action. Oh... and by the way: the Asset Pipeline was exchanged for a complete Webpack setup, so no Sprockets have been harmed in delivering JavaScript and Stylesheets.</comment>


Lessons from T-Mobile's support - <AUTHOR> http://www.37signals.com/svn/posts/755-lessons-from-t-mobiles-support <comment><USER2> I was a T-Mobile customer for 2 years, and was never treated that nicely. It seemed like every time I called, I was being pressured into signing another contract. Their systems were also always very slow, so while the rep was waiting for their service interface to load, they'd engage me in a lot of awkward small talk. I haven't been a customer for about a year, so maybe they've changed since then.

</comment><comment><USER3> I recently called to make a change to my account. I was shocked by how nicely I was treated. To top it off, the person on the line gave me some helpful relevant tips too.

<comment><AUTHOR> Customer service is the differentiator, especially in commoditized products/services except when hotel babysitting: <http://redeye.firstround.com/2008/01/some-thoughts-o.html>

<comment><USER4> That's a problem of information asymmetry where the only indicator of quality is the price.

</comment></comment></comment><comment><USER5> So VERY different from T-Mobile/Telekom in Germany. Here they still behave like the monopolist they once were.</comment>


Hot File Finder – Finding the 'hottest' files in a Git repo - <AUTHOR> https://github.com/colinhowe/hotfilefinder

<comment><USER2> Here's an alternate version I'd written to such identify files. Using the git command line, invoke the following function from within any git repo:

most-volatile-files () { git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10; }

<comment><AUTHOR> This is cool :) The difference between this and what I've made is that hotfilefinder looks at number of lines changed</comment></comment>


Google Services Experiencing Issues – How are You Holding Up? - <AUTHOR> http://www.droid-life.com/2014/05/16/google-services-experiencing-issues-how-are-yours-acting/

<comment><AUTHOR> Hangouts, Gmail and Play store are down for me in Chicago. On T-Mobile with a Nexus 5. Mobile data seems to work just fine, though.</comment>


Ask HN: Who Buys Data? - <AUTHOR>

Selling data isn't new, but the market for selling data is getting larger. If you were getting into selling datasets, who would you look to tailor your offerings to? (Assuming that you would pick a type of customer first, then gather the data to sell to them.) <comment><USER2> I'd see if I could come up with a profitable way to offer high frequency historical stock market data to retail/independent crowd.</comment>


Scamworld: 'Get rich quick' schemes mutate into an online monster - <AUTHOR> http://www.theverge.com/2012/5/10/2984893/scamworld-get-rich-quick-schemes-mutate-into-an-online-monster

<comment><USER2> The biggest pile of biased crap I've read for a long time and confirmation for me, at least, that The Verge is ultimately no better than any of the outlets it was trying to replace.

They take some bad apples from a niche and use that to extrapolate a whole business model and set of practices as being bad. I think it's sloppy, non- objective, ersatz journalism that merely peddles FUD. And even their choice of "bad apples" is questionable: <https://www.facebook.com/pages/Frank- Kern/137568852956377>

I can only speak for Kern and Jenkins but they've both put out some good products and are essentially info publishers who use certain high exposure and highly effective marketing techniques.

But if using cheap products to build leads who you then sell bigger ticket products to is a scam, well, a large amount of HN readers are involved in that "scam" too (yes, offering a webinar or a PDF to get people to sign up to your e-mail list is a "scam" supposedly!) Except, it's not a scam.. and this article is just a badly written pile of crap, all IMHO, of course.

<comment><USER3> I disagree. What are these great products you talk about?

</comment></comment><comment><USER4> While I agree with the author that there are so many scam artists out there and you do need to do your due diligence, I do not think how the following sentence defines marketing on the internet is correct:

"The term Internet Marketing describes both a particular business model used to sell fraudulent products and services online, and the community or subculture that embraces it."

</comment><comment><USER5> It's too bad this article didn't make it to the front page.

I've seen a few of these in HackerNews albeit not as complicated as the ones in the article.

Typically around teaching developers how to get extra income, becoming a millionaire, running a startup, having your own businesses, etc.

<comment><USER6> Sorry, but this article was written by an idiot. Please see the line:

      Raygoza is an Internet Marketer — a 21st century snake oil salesman.

or

      The term Internet Marketing describes both a particular business model used to sell fraudulent products and services online, and the community or subculture that embraces it.

Equating get-rich-quick scam artists with the entirety of the internet marketing spectrum is absolutely ridiculous.

</comment></comment><comment><USER7> Interesting article, it could've used a little editing - too long, fluffy, and has unnecessary descriptions that hurt the piece, e.g. "(which, for some reason is rated "M for mature," like Grand Theft Auto IV)."

</comment><comment><USER8> scammer on stage: "the economy is crappy, so there's never been a greater need for contrarian financial advice"

wut

scammer on stage: don't worry i'll explain to you how to make products and everything; that takes 4 minutes"

facepalm

</comment><comment><USER9> Hey, fuck you Verge. I'm reading this heart wrenching story and then suddenly "Boo Hoo! This video can't be played with your current setup".

Way to fuck up.</comment>


Ask HN: Django or Flask as first web framework? - <AUTHOR>

I am in the process of learning Python for web development and I think I am the stage where I should start learning a web framework(did not use one before in another language). My html and css is ok.
I have picked Python for fast web development and that is why I think I should just dive right into Django. However I have seen plenty of advice that it would be good to start with Flask(or other smaller framework) to learn better the inner workings of the framework.
What would you advise?
As I learn better from videos do you know of any good videos to learn the advised framework? What about books or tutorials?
What do you wish you knew or learn when you were just starting with the  framework?
Thanks, Adrian
Update!!!
Thanks everyone for your comments. So I will be starting with Django and so far I have as resources Django docs and the upcoming video series. Is there anything else you would recommend as tutorials?
Asuming I am a fast learner and I learn this full time how long should it take before I can start building my own web apps? <comment><USER2> You can never go wrong with Django. It comes with enough batteries included to get you up and running with complex projects quickly. Plus, there's a lively ecosystem of useful libraries built on top on Django that make complex tasks a breeze. If you want to _built useful webapps quickly_ , Django is the way to go.

The assertion that Flask gives you a better look under the hood is, in my opinion, incorrect. With Flask, you get almost nothing out of the box besides some basic URL routing and request handing. For most web development tasks, that's not enough. So you end up adding an ORM, a template engine, a session handling library, etc. on top. Eventually you end up with a set of libraries that have as much "magic" to them as your standard Django install, except now they're loosely held together by duct tape. Just take a look at SQLAlchemy, WTForms or Jinja2 -- three libraries that are often used with Flask -- and tell me whether they feel less like magic than Django's equivalents. Plus, now you have to look up documentation for _three_ libraries in _three_ different places, keep up with their developments separately, and get used to three different coding conventions. It gets complex very fast.

As adambard mentioned, Flask is a very effective tool when you want to do something highly nonstandard and rolling your own framework is your only option. For 9 out of 10 webapps, though, Django is the right answer.

<comment><USER3> I agree completely. However, personally I am using Flask only because tacking SQLAlchemy on top of Django feels so hacky. I wish there was a second full stack framework with SA.

<comment><USER2> Have you given Pyramid a look?

<comment><USER3> The core Pyramid setup is actually just as minimal as Flask is. You need to add a million different Pyramid_ addons to get "full stack" functionality.

</comment></comment></comment></comment><comment><USER4> Depends what you want to build.

Flask is better suited to apps that are a) small and single-purpose, or b) highly nonstandard.

Django has a lot of stuff built right in, much of which you won't need. But it's nice to have a database abstraction, forms, auth, admin, etc. when you need them. Plus, it's practically a CMS already all by itself, with the nice admin panel.

I'd probably start with Django. The tutorial isn't bad at all: <https://docs.djangoproject.com/en/1.4/intro/tutorial01/>

</comment><comment><USER5> I recommend Django because it's much more widely used. You'll find more write- ups, Stack Overflow questions, podcasts and conference videos. Instagram uses it. Disqus uses it. There's just a ton of help out there for a new developer.

While I agree that a lot of what Django does seems like "magic", getting to know how that magic works as you get more intimate with the framework will make you a better developer in the long run - so you can start writing your own magic.

<comment><AUTHOR> This is what puts Django on top of my list so far. It would be more fun and productive if I can just start doing web apps and I can always jump in and learn some of the magic behind it in the future.

</comment></comment><comment><USER6> Hi Adrian,

I would recommendation is django, but there currently are no good tutorials for it. Kenneth Love (<https://twitter.com/kennethlove>) is creating django video series that should be available in December.

In the meantime my recommendation is as follows:

1\. Make sure you have an understanding of Python before you get into Django or Flask. Do this by taking one (or all) of the following online classes:

a. Udacity.com: [http://www.udacity.com/overview/Course/cs101/CourseRev/apr20...](http://www.udacity.com/overview/Course/cs101/CourseRev/apr2012)

b. Learnpythonthehardway.org (There are video lessons for a price of $29)

c. <https://www.edx.org/courses/MITx/6.00x/2012_Fall/about>

2\. Once you have an understanding of python and can write simple scripts, I recommend the following video courses for web development with Python:

a. Flask: <http://www.youtube.com/user/calicoJake> (A great Flask video tutorial series)

b. Udacity: [http://www.udacity.com/overview/Course/cs253/CourseRev/apr20...](http://www.udacity.com/overview/Course/cs253/CourseRev/apr2012) (not flask or django, but still good)

c. Django: [http://www.kickstarter.com/projects/657368266/getting- starte...](http://www.kickstarter.com/projects/657368266/getting-started-with- django) (to be released in Dec 2012 or early 2013.

</comment><comment><USER7> You could start tonight. Master your art, choose your weapon - django or flask - and hit the ground running. oh and have fun.

</comment><comment><USER8> Either one is great. I started with Django and now prefer Flask; unless you are starting out with an enormous project I agree with the recommendations you have received--you will get a better sense of what's happening under the hood with Flask.

I don't like learning from videos so can't help you there, but <http://djangobook.com> is awesome for learning Django, and the Flask documentation is sufficient too.

<comment><AUTHOR> Is the Django book updated? The notice where it asks for help to get it updated it scared me as a newcomer(and probably many others) as I won't know to judge if what I read is updated material or not.

I understand this is an open source project but from the business perspective that notice is completely missplaced. The people looking there want to read the book and what they learn is that is outdated. The targeted audience that can actually help update the book most likelly hangs out somewhere else.

<comment><USER9> I can't speak to the status of the Django Book, but Django's official documentation is up to date and just as (if not more) comprehensive. Version 1.4: <https://docs.djangoproject.com/en/1.4/>

</comment></comment></comment><comment><USER10> I think if you end up in development as a career, Django is going to be used incredibly more often than Flask.

In the end, you will learn the internals either way. If you start with Flask, you'll still have to learn about Django internals.

Start with Django (and you'll probably never switch to Flask).

<comment><USER10> And to answer your last question--I'd think assuming fast learner, and you're already competent with python, I'd think a few days and you can have up a basic app (blog, wiki, something like that), and a few weeks and you'll be pretty comfortable with any normal CRUD app.

</comment></comment><comment><USER11> I started learning Django as my first web framework. If I had to do it over I would have spent a month with Flask, and then moved to Django. Django is a big app, and I found it difficult to build a mental model of its workings. Maybe starting with a smaller framework would have made it easier.</comment>


More diagnostics data from desktop - <AUTHOR> https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040139.html <comment><USER2> I see nothing in wrong with this as long as the checkbox is prominently presented, preferably on it's own "page" of the installer, it can be easily updated post-installation, and the scope of agreed upon data collection isn't increased for a given installation after agreement.

> Any user can simply opt out by unchecking the box, which triggers one simple > POST stating, "diagnostics=false". There will be a corresponding checkbox in > the Privacy panel of GNOME Settings to toggle the state of this.

By POST do they mean a POST to the same web endpoint? Why would opting out requiring notifying them of your installation. I get that they'd want to track installation counts but would expect opting out to be entirely silent. Or do they mean that opting out once you've opted in would notify them of such?

> And to reiterate, the service which stores this data would _never_ store IP > addresses.

Any idea what country / jurisdiction they plan to host this data and service?

<comment><USER3> I suppose it to have a "total number of installs" statistic.

<comment><USER4> They can already get an approximate number by counting downloads of package updates. It's deceptive to send _any_ information if the user opted out.

<comment><USER5> I doubt it's possible since many systems update from closest mirrors, most of which are not Canonical's servers.

</comment></comment></comment></comment><comment><USER6> I hope they checked this with their lawyers, otherwise they will be sued out of existence when EU GDPR directive comes into effect(only applies to EU citizens).

Just check the "Consent" section at [https://gdprchecklist.io/](https://gdprchecklist.io/)

Opt-out is not legal anymore... I'm not saying they are not allowed to collect, they can, just not by default. And because they are requesting "Location", they fall under GDPR even in lamest terms.

<comment><USER7> > We would like to add a checkbox to the installer, exact wording TBD, but > along the lines of "Send diagnostics information to help improve Ubuntu". > This would be checked by default.

This is about a choice presented as a checkbox that is checked by default during installation, not about a feature silently enabled by default you have to then opt out of.

<comment><USER8> The GPDR asks for a deliberate action to opt-in ("silence, pre-ticked boxes or inactivity" should not constitute consent). So they should make it a very prominent choice to opt-in. No more opt-out in Europe.

<comment><USER7> > "silence, pre-ticked boxes or inactivity" should not constitute consent

Could you give a reference for that?

I found this with a couple of examples[0] but my understanding so far is that as long as it's a separate isolated step dedicated to that question with clearly worded language explaining the collection, followed by a very explicit "I agree" button or checkbox, then it's fine. The step itself (not the checkbox) constitutes wilful agreement, as it requires action for that dedicated step: it's definitely not "inactivity" nor "silent". Here I assume the button to move to the next step is not simply labeled "next step", nor is it actionable by simply pressing the enter or space key, possibly by mistake.

[0]: [https://dma.org.uk/article/gdpr-in-practice-tick-box- consent...](https://dma.org.uk/article/gdpr-in-practice-tick-box-consent- forms)

<comment><USER8> It's right there in the regulation under (32) [0]

I find your workflow reasonable, but it would fall short under 'free'. Negative and positive action are two different things and in this case the wording is quite clear ("clear affirmative act", "pre-ticked box [..] should not").

[0] [http://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=CELEX...](http://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=NL)

</comment></comment></comment></comment></comment><comment><USER9> "We would like to add a checkbox to the installer, exact wording TBD, but along the lines of "Send diagnostics information to help improve Ubuntu". This would be checked by default."

That seems like a transparent way of collecting what appears to be not very personal data.

</comment><comment><USER10> This is almost nothing compared to what Microsoft with Windows 10 collects. And beyond that, Canonical is honest and presents an opt out, while Microsoft does waaaay more without even telling, and hides all the many opt-out's in loads of hidden setting dialogs.

Still, it's good to keep a sharp eye on Canonical. I have not forgotten about the "lens" sending your local query to 3d parties like amazon by default..

<comment><USER11> Canonical is no saint,

[https://www.eff.org/deeplinks/2012/10/privacy- ubuntu-1210-am...](https://www.eff.org/deeplinks/2012/10/privacy- ubuntu-1210-amazon-ads-and-data-leaks) (Amazon Ads and Data Leaks in ubuntu 12.10)

[https://arstechnica.com/information- technology/2012/12/richa...](https://arstechnica.com/information- technology/2012/12/richard-stallman-calls-ubuntu-spyware-because-it-tracks- searches/) (Richard Stallman calls Ubuntu "spyware" )

[https://www.wired.com/2013/11/fixubuntu/](https://www.wired.com/2013/11/fixubuntu/) (Linux Outfit Canonical Launches Campaign to Silence Privacy Critic)

<comment><USER12> That was shitty but they stopped doing it years ago (in 16.04 specifically), and it was easily disabled when it was there.

Meanwhile Windows 10 just keeps getting more and more invasive, and make it more and more difficult to turn off. Disabling web search in the start menu requires using either the registry editor or group policy now! And when you search for how to disable things everything you find is out of date because they keep changing it every 6 months. The trend has been going from actual option in settings menu -> require registry edit or group policy -> system ignores the registry and it becomes completely impossible to disable. I was pretty mad when they did this to the lock screen and it continues to be a mild annoyance to me every day.

</comment></comment></comment><comment><USER13> I'm surprised they didn't do this already. This is crucial data for them to actually improve the product.

Only thing I'm a bit concerned about is automatically sending crash reports. This highly depends on the programming language the crashing program was written in. It is very much possible for a program to include sensitive or personally identifying information in the stack traces right?

</comment><comment><USER14> One thing in Ubuntu's favour, they are upfront and clear about their intentions. So long as switching the data collection off actually does switch it off, I am fine with them going ahead with this.

Other OSes have much to learn...

<comment><USER15> Agreed; telemetry is valuable, and I have no problem with it... provided there is an option to turn it off.

</comment></comment><comment><USER16> Title is editorialized and should be changed. They are not saying they _will_ do it, they would _like to do it_ and they are asking for feedback.

</comment><comment><USER17> Well, Apple and Microsoft already have that data about my systems, so jump on board.

And if you don't want Canonical having this data you're probably savvy enough to uncheck the box, or you're already some other flavour.

</comment><comment><USER18> The article actually asks for input of the collection of diagnostic data.

The title by Santosh83 says instead "Ubuntu will collect data about your system by default, starting with 18.04".

</comment><comment><USER19> Seems like can opt out easily, and the information given appears reasonable so will quite happily check this box.

<comment><AUTHOR> It will also enable a program called Popcorn that will track and report the relative frequency of your app usage. That _is_ somewhat personal according to some people at least. And this option toggles Apport to send back crash reports without asking permission each time, which means it could(?) leak sensitive data in memory?

<comment><USER20> I think you mean popcon? Short for popularity contest[1]. It's been part of Debian forever, not sure when it first showed up but it was part of Woody at least. With Debian you could configure it to use PGP and encrypt the reports you send in. I generally disabled it on work computers but left it on at home. That probably didn't help them as much but I just couldn't see leaving this type of feature on for servers and computers that weren't mine.

[1][https://popcon.debian.org/](https://popcon.debian.org/)

<comment><USER4> Debian's installer requires explicit opt-in consent to install popcon. It's not enabled by default.

<comment><USER20> Yes, that's true. I do think that that's the better way to do it.

I understand Canonical is trying to make a user oriented system that "Just Works" and collecting this data can certainly help with that but I do think that this should be Opt In, not Out. If nothing else to support the precedent that, in general, Opt In is better for privacy that Opt Out.

</comment></comment></comment></comment></comment><comment><USER21> This generally sounds resonable, but I'm somewhat concerned about that part:

> Apport would be configured to automatically send anonymous crash reports > without user interruption.

Crash reports could easily contain sensible and private data (e.g. file names/paths or usernames) and I wouldn't be comfortable sending them to an unknown group of people by default. Canonical would have to convince the user that anonymization is working really reliable for me to activate that feature.

Right now I'm always drawn between fear of private data leaking and my will to support them in fixing annoying crashes (nemo crashes almost daily for me).

<comment><USER16> > private data (e.g. file names/paths or usernames)

Can you give an example of a path, file or user name that would cause problems to you (or anyone else) if Ubuntu engineers see it when fixing bugs?

<comment><USER4> ~/Pictures/Gay_porn/

<comment><USER16> How is an Ubuntu engineer seeing that some random computer somewhere has a gay porn folder a problem _for you specifically_?

<comment><USER22> Would you mind printing your output of "tree /" so we can take a look?

</comment></comment></comment></comment></comment><comment><USER23> In addition to the GDPR concerns mentioned in sibling posts, this type of collection is likely covered by Article 5.3 of the EU ePrivacy Directive, which requires consent for storing or reading information from end-users' devices (also known as the "cookie rule").[0] The Dutch Data Protection Authority recently applied this rule to Microsoft's collection of telemetry data through Windows 10.[1] Notably, this rule is not limited to personal data; it applies to all "information."

[0] [http://eur-lex.europa.eu/legal- content/EN/TXT/?uri=CELEX:020...](http://eur-lex.europa.eu/legal- content/EN/TXT/?uri=CELEX:02002L0058-20091219) [1] [https://www.autoriteitpersoonsgegevens.nl/sites/default/file...](https://www.autoriteitpersoonsgegevens.nl/sites/default/files/atoms/files/public_version_dutch_dpa_informal_translation_summary_of_investigation_report.pdf)

</comment><comment><USER24> Seems sane and reasonable amount of data collection.

</comment><comment><USER25> Welcome to Microsoft's world :)

I don't mind sharing data for software that I use for free but this kinds of bothers me a lot:

> This would be checked by default

Lol no, I know where are you going on this but please do NOT enable this by default.

<comment><USER3> Why not ? Some people just don't care, and these who don't care don't care to check the option. So to me it's more logical (in order to have more data) to check the box by default.

<comment><USER26> GDPR expressly forbids default checked boxes or "silent acceptance", setups which require opt-out to prevent tracking/data collection.

Data collection is OK, but it _must_ be opt-in only.

You're only looking at it from a "more data = better" perspective, instead of a privacy perspective, which is a lot more important.

<comment><USER18> It has been mentioned already above.

We are talking here about anonymized diagnostic data, not private indentifiable information.

<comment><USER4> Crash reports can contain any data that happens to be in memory, including private identifiable information.

Additionally, "anonymized" data frequently turns out to be identifiable when enough of it is collected.

</comment></comment></comment></comment></comment><comment><USER27> "Any user can simply opt out by unchecking the box"

They should at least do it the other way round and have people opt in instead of opt out. Still I would prefer a distro that does not have such functionality in the first place.

Since Ubuntu did their first "phone home" experiments in 2015, I stayed away from it. And I will keep it that way. It was just too much of a user hostile action. Shuttleworth even defended it. Showed me that his values are not compatible with mine.

Linux Mint has been a very user friendly replacement so far.

</comment><comment><USER28> Honestly fine with this, mostly given how bad 17.10 is. These folks are basically flying blind — a mess of a release.

</comment><comment><USER29> I wish GDPR allowed citizens to personally sue companies and take a cut of the winnings like the disability regs here. It would give the regulation teeth fron day 1 and send a strong message.

</comment><comment><USER30> It should really be Opt-In. It just tastes like Microsoft-Behavior.

</comment><comment><USER31> Please use the original, less inflammatory title: "more diagnostics data from desktop."

Understandably, Canonical wants to collect diagnostic data useful for software development and bug fixing. Other major OS providers like Google, Microsoft, and Apple do this.

I like the fact that Canonical is doing it in an open manner: anyone can opt out by unchecking a box at installation or afterwards on the privacy panel; and they will make aggregate diagnostic data available to the public.

<comment><USER32>
      > So you ask the user during install. Then the data is sent on first
      > boot. At what point can the user inspect the data, given that some of
      > it can't be collected until after installation is finished? It seems
      > like the first opportunity will be after it has been sent, unless you
      > ask the user a second time. So why not just ask them on first boot,
      > when you have already gathered all the data? That way user can inspect
      > the data there and then before deciding how to answer.

      Yes, I think the first opportunity would be after it has been sent.  I'm
      generally against asking more questions on login though, I think it would
      be clunky.

Do I understand it correctly that they want to send the data the first time unconditionally after installation, and _only then_ present the user with the opt-out choice? I really hope I understood it wrong.</comment></comment>


Tencent says there are only 300,000 AI engineers worldwide – millions are needed - <AUTHOR> https://www.theverge.com/2017/12/5/16737224/global-ai-talent-shortfall-tencent-report <comment><USER2> What is an AI engineer?</comment>


10 reasons to believe P != NP - <AUTHOR> http://www.scottaaronson.com/blog/?p=122

<comment><USER2> Article is about believing P != NP, entirely different title

<comment><USER3> I was really confused before I realized that there's a "!" missing.</comment></comment>