Show HN: Find the best time to beat traffic - <AUTHOR> http://www.beatthetraffic.co.uk <comment><AUTHOR> This is in it's early staged - still needs to location auto-completion and tidying up. Obviously need more information in it and logo, title etc. But any suggestions and/or thoughts about the general idea would be great :)

<comment><USER2> [http://i.imgur.com/VimNiqU.png](http://i.imgur.com/VimNiqU.png)

Google Chrome Canary, OSX

<comment><AUTHOR> Thanks! I'll take a look into the CSS problem - since the autocompletion for location hasn't been completed yet and the API backend is still in it's early days, this can sometimes be thrown by bad location - perhaps try with just a postcode or something like that?

Thanks!! :D

Matt</comment></comment></comment>


Hamms: a misbehaving HTTP server for testing your clients - <AUTHOR> https://github.com/kevinburke/hamms <comment><USER2> Having written a web crawler recently, it's surprising just how many misbehaving servers are actually out there.

Without proper error handling, a wide randomly seeded crawl would hit some form of malformed response or bizarre header within 15 minutes at the most. I eventually gave up on trying to parse all the myriad odd behaviours and now just dump them all onto a blacklist and move the crawler on.

</comment><comment><USER3> This really is a cool one. The different ports makes it very suitable for handling a specific kind of problem. It might also be nice if there was a port that responded with a random selection from the errors (or with a proper response). e.g. "Port 5599: All of the above, at random"

<comment><USER4> Yeah this is a good idea. I think I'm gonna change the default behavior for that port

</comment></comment><comment><USER5> A friend of mine wrote bane, which does similar stuff in Ruby: [https://github.com/danielwellman/bane/](https://github.com/danielwellman/bane/)

</comment><comment><USER6> A thing along these lines that I have come across before is [http://pathod.net/](http://pathod.net/). How do they compare?

<comment><USER4> In terms of functionality they are basically the same :) pathod has one server that behaves differently depending on the request you send. Hamms has different servers listening on different ports. I thought the interface was a little nicer that way. (I'm the author of hamms).

I tried to add some things as well that make testing easier when I am writing a client. Testing retry logic is hard for example because the client is making the same request a bunch of times in a row so you have to either mock the client request or make the server return different things based on the same request. I added a server that errors twice and then returns a 200, to make that easier to test.

<comment><USER7> Having ability to forward requests to an actual API of my service seems to be nice-to-have feature. (Especially for 5512 and 5513 ports, where actual correct 200 OK responses are expected.)

Any plans on that?

<comment><USER4> Not at the moment... could use runscope.com or set up nginx as a proxy maybe ?

</comment></comment></comment></comment><comment> Ono-Sendai On this note, does anyone know about a 'misbehaving' HTTP client for testing servers?

<comment><USER8> From another comment [http://pathod.net/docs/pathoc](http://pathod.net/docs/pathoc)</comment></comment>


Can we try to tune out tech-blogger BS? - <AUTHOR>

I genuinely enjoy reading TechCrunch, AllThingsD, Verge, Gizmodo, Engadget, just about any of them depending on the day, but I've grown pretty weary of the bloggers and personalities becoming THE story.
I know they're going to play the game on their respective sites, but can we stop feeding the pettiness with submissions and up-votes here on HN?
I don't want to tread on what the community wants. If people genuinely think those stories have a place and are generating good discussion, ok. But I feel like a lot of them are only getting submitted or up-voted because we're falling prey to link-bait.
Anyone have any thoughts? <comment><USER2> Vote that shit down. Contribute to meaningful discussion about hacking; of computers and of the universe we use computers to simulate.</comment>


The best small computer in the world (1968) [pdf] - <AUTHOR> http://archive.computerhistory.org/resources/text/Data_General/DGC.Nova.1968.102646102.pdf <comment><USER2> I find it quite amusing that the photo-models are the president and the vice president looking manly.

<comment><USER3> and smoking!

</comment></comment><comment><USER4> Nothing like having Don Draper make promo shots for your new computer.

<comment><USER5> That photo of Herbert J Richman is a pure classic.

<comment><AUTHOR> This actually does remind me of classic Oglivy work.

</comment></comment></comment><comment><USER6> Wow... my first exposure to a computer was a Supernova, set up with four ASR-33 Teletypes and running Data General BASIC, for about eight or nine evenings in the spring of 1971. Changed my life--the next year, without a computer to use, I wrote programs in a notebook which I wish I had kept. Thanks, Data General, NSF, and thanks to Dr. Richard V. Andree.

</comment><comment><USER7> What would be the typical use of a machine like this? I'd assume basic roll-up accounting, with programs written on a custom basis per client.

Anyone with practical experience?

<comment><USER8> They were marketed for embedded control and data acquisition in laboratories and factories. See the text on page 5, in "The hardware", where it tells how you can send your program on paper tape to DG and they send you back a read- only memory you can plug in - so your program begins running on power-up without help from an operator.

I recall seeing a Nova used in an experimental psychology lab. The first production medical CT scanner included a Nova, see [http://en.wikipedia.org/wiki/X-ray_computed_tomography](http://en.wikipedia.org/wiki/X-ray_computed_tomography).

</comment></comment><comment><USER9> Before "The Soul of a New Machine."

<comment><AUTHOR> I actually just finish reading that and it's what lead me to this!

<comment><USER10> Here's a picture of the Eclipse MV/8000 "Eagle", the machine they were building in the book:

[http://www.foxdata.com/blog/wp- content/uploads/2012/08/Data-...](http://www.foxdata.com/blog/wp- content/uploads/2012/08/Data-General-Eclipse-MV8000.jpg)

"The Soul of a New Machine" is a great book, by the way, even if the technology in it is a bit old at this point. Hackers of hardware and/or software should definitely read it.

Another interesting book about the creation of a large system is "Show- stopper", by G. P. Zachary, which describes the building of Windows NT.

<comment><USER11> Does anybody know more about FHP (the Fountainhead Project) than what little I can read here:

[http://people.cs.clemson.edu/~mark/fhp.html](http://people.cs.clemson.edu/~mark/fhp.html)

<comment><USER10> Here's an account of the Fountainhead Project written by Rich Wingerter, who was a programmer working on the project:

[http://www.sonic.net/~richw/FHP.html](http://www.sonic.net/~richw/FHP.html)

While searching for this I also found an interesting paper on the Eagle project:

"Flight of the Eagle: The Birthing and Life of a Super-Minicomputer" (1996)

[http://www.faughnan.com/papers/eaglecomp.pdf](http://www.faughnan.com/papers/eaglecomp.pdf)</comment></comment></comment></comment></comment>


The Collective Intelligence Genome - <AUTHOR> http://sloanreview.mit.edu/the-magazine/articles/2010/spring/51303/the-collective-intelligence-genome/

<comment><USER2> This is brilliant but using 'genome' implies mutation/evolution. It seems that the content these companies/sites generate evolves over time but the Collective Intelligence Genome(rules for content management) remains more or less fixed over time.

<comment><USER3> Indeed. Why do people insist on calling things "Genomes" or talking about the "DNA" of concepts that have no relationships with the meanings of such terms?</comment></comment>


How Facebook Knows When Its Ads Influence Your Offline Purchases - <AUTHOR> http://www.wired.com/2014/12/facebook-knows-ads-influence-offline-purchases/ <comment><USER2> ...aaand facebook starts to buy news pieces to justify their ad network.

this is nothing more than a press-release for their atlas feature. A new low even for wired.

<comment><USER3> Odd. It seems unusual for a press release to include criticism from the EFF.

How would the article have to have been written for you to not think it was a press release?

<comment><USER4> I feel like PG's submarine piece has really made HN's view of PR very black and white. There are a lot more gradations, and likely this is a piece that was pitched by Facebook and actually was moderately investigated by Wired. The worst journalists are copy pasting press releases, the best are finding their own stories, but the vast majority lie somewhere in between. And I'm not convinced there is anything wrong with that.

</comment></comment></comment><comment> chestnut-tree Some commentators in this discussion question why anyone would give their phone number to shops when they make a purchase. Yet millions of people give their mobile phone number (and name, date-of-birth and gender) to Google when they sign up for a Google account. And yet the degree of tracking that Google can undertake is an order of magnitude greater than what any individual store can track. Does Google use your mobile number solely for two-factor authentication and absolutely nothing else? Who knows? Google doesn't tell you.

When you can sign in on your tablet/mobile/desktop/TV/thermostat/fridge and who knows what else - how hard can it possibly be to stitch together your spending and consumption habits with all the other data collected about you? In fact, it wouldn't surprise me if those joined-up journeys have already been compiled. It's pretty obvious that the information companies collect about you goes far, far beyond creating a simple "advertising profile".

Companies like Google and Facebook (and others) have no self-restraint when it comes to tracking you and they don't even do it anonymously. How do they get away with it? Because we happily let them.

<comment><USER5> Google uses Android phones GPS location to track people's store visits.

[http://digiday.com/platforms/google- tracking/](http://digiday.com/platforms/google-tracking/)

[http://www.datadrivenbusiness.com/google-quietly-testing- off...](http://www.datadrivenbusiness.com/google-quietly-testing-offline- store-visits-tracking)

If you turn it off, things like Google Now stop working.

<comment><USER6> Yep, im pretty sure just the mac address collection from wifi radios would be enough to track what store you have been in if you run an Android phone.

I have wifi and gps turned off except when i am lost.

</comment></comment></comment><comment><USER7> > The trick is that the hash of a phone number captured on Facebook will look > just like the hash of the same phone number captured in a brick and mortar > store, so the two companies can match the numbers without actually trading > them.

This just isn't possible. How many cents would it cost to brute-force hash all legal American phone numbers?

<comment><USER8> This is correct. As a zero-knowledge proof it is, sadly, trivially broken. (Not just in a theoretical sense. As you mention there just isn't enough entropy going into the hash. It's like asking for your age and gender, but only providing a hash to some other party so they can verify that you are who you say you are, without your divulging what information you were just given. That doesn't work - you would leak everything, because 1-100 (age) M/F (gender) only has 200 possible values. 200 hashes later your counterparty knows what you were asking to check.)

But that doesn't mean this _couldn 't_ be done properly.

There are actual zero-knowledge proofs. I liked this primer. You should read it!

[http://blog.cryptographyengineering.com/2014/11/zero- knowled...](http://blog.cryptographyengineering.com/2014/11/zero-knowledge- proofs-illustrated-primer.html)

It is 100% possible for there to exist absolutely zero-knowledge proof in many instances. (Such as the one in the article.)

So, it could be possible for example (I don't know an algorithm) to check whether a phone number you were given is in someone else's set of phone numbers - without either your learning what the other's set is, or the other learning what phone number you're testing.

<comment><USER7> If there is, the 'someone else' would still have to do some rate limiting. Otherwise, once again, I can just run this algorithm for all possible phone numbers.

<comment><USER8> No, no. Read my link :) The whole point is that the definition of 'zero- knowledge' is that (if you use a zero knowledge interactive protocol) you learn no further knowledge.

You are right that the hash-passing is _not_ zero-knowledge. Rather than just verify whether it's in a set, you've accidentally revealed a number. So if you have a set of phone numbers and I have 1 to check if it's in that set, then checking hashes doesn't work - I would end up divulging my number if I used it.

<comment><USER9> Intersecting a set of observed identifiers against another set is an issue Moxie dealt with on the TextSecures blog[0] (for phone numbers at that). He evaluated some ZKP algorithms and basically concluded this problem is hard or impractical today. I imagine an ad/referral network has many of the same real time constraints and scalability issues.

[0] [https://whispersystems.org/blog/contact- discovery/](https://whispersystems.org/blog/contact-discovery/)

<comment><USER8> thanks - this was interesting. Some of the numbers are interesting. So, for example, he says to have ten million clients updating daily, he would need to sustain 40 MB 116 times every second. . . that's like 37120 megabit so if you pay $10 per megabit monthly, that's $371,200 per month. It's pretty bad. On the other hand you do have ten million users.

so the numbers are off, but they're not five orders of magnitude off. If we're going to service ten million users, we might have something of a hosting budget for it.

So while I believe the author that the current trade-offs aren't goods, clever academic mathematics might help in the future. Cryptography itself came from there.

</comment></comment></comment></comment></comment></comment><comment><USER10> I see false positives. So last week I decided to do my first project that will use a Raspberry Pi. I googled around to the pi site, amazon, newegg, (gasp) radio shack, microcenter, etc... I figured out what I wanted to get but didn't put anything in any carts. So then Pi ads start showing up on Facebook. IIRC a Radio Shack Pi ad too. Whatever. But now when I buy one, is Facebook going to claim some responsibility for the sale? Because they honestly don't deserve it. I'm going to buy one anyway and I have not seen an ad for a place I didn't look already. While I often give a real store the business based on "I can get it on the way home" the price difference in this case is nuts. So NewEgg it will be and Facebook ads aren't going to influence that.

In this case, correlation does not indicate causation.

<comment><USER11> causation is implied on a population through test and control. causation and correlation for an individual is almost always impossible.

<comment><USER10> So are they going to use statistical models to figure out how much to charge for ads? That seems like a hard sell.

</comment></comment></comment><comment> dao- "It has happened to you, and it has probably happened more than once."

Umm, no. Why on earth would I give my phone number or email address to random shops? This is crazy. I surely don't want merchants to contact me "about other stuff I might want to buy." This assumption sold as a certainty in this article is somewhat disturbing. Do others from the US feel the same way? (I'm from Germany. Different culture?)

<comment><USER12> I can only think of a couple of retailers that have asked me for an email address here in Canada (coincidentally both were US companies).

I do get asked for my postal code fairly often but that's hardly a personal detail.

<comment><USER13> You postal code, name and the expiration date on your card is enough to positively ID you in many consumer databases, and by giving it to the retailer you're implicitly granting consent for its use for this purpose.

<comment><USER14> I am not a lawyer, but I'm pretty sure that in Canada, this would be in violation of the federal "Personal Information Protection and Electronic Documents Act", as well as many provincial laws.

[https://www.priv.gc.ca/leg_c/leg_c_p_e.asp](https://www.priv.gc.ca/leg_c/leg_c_p_e.asp)

"Use or disclose personal information only for the purpose for which it was collected, unless the individual consents, or the use or disclosure is authorized by the Act."

"Keep personal information only as long as necessary to satisfy the purposes."

If the client uses one of those "points" cards, yes, they are tracked, but otherwise they shouldn't. When a retailer asks for your postcode, it is mostly just for market study to identify where their clients live, but that's it (although I rarely get asked). You can also just answer "no thanks" to this question.

</comment></comment></comment></comment><comment><USER15> "People voluntarily link things like phone numbers and email addresses to their Facebook accounts"

People voluntarily are idiots. Never connect a phone number to your FB account and use another mail address if you really need to have an account.

<comment><USER16> I agree with you, but sadly it's not that straightforward; It's entirely plausible (perhaps even likely) that your "facebook friends" have your number, and do something stupid^H^H^H^H^H^Hconvenient like give fb access to their address book (as is often requested, and I wouldn't be surprised if it happens by default with their mobile apps), Facebook are only one name match away from having your number and perhaps DoB and other personal info anyway.

</comment></comment><comment><USER17> > _As Boland explains it, Facebook simply shows advertisers that a given > number of people who saw an ad for a product also purchased that product._

Facebook doesn't share my personalized shopping data with advertisers. That's good.

But the data still exists. So the data the advertisers receive is only really anonymous until there's some sort of security breach or economic decision whereby it's suddenly more profitable to sell the personalized data. Either or Both of which are inevitable.

All in all, a moderately informative marketing piece.

<comment><USER18> _Facebook doesn 't share my personalized shopping data with advertisers. That's good._

The stuff about you personally that can be gleaned from market analytics will make you shit a brick.

And this is what private industry can do, not even getting into three-letter agencies.

</comment></comment><comment><USER19> tldr; it doesn't, but offline vendors that collect your contact information they can anonymously check the proportion of purchasers which might [incidentally?] have been shown their ad on Facebook's network. Only a media buyer with a budget bigger than their brain would assume causality.

<comment><USER20> Couldn't Facebook easily demonstrate causality by running an RCT? Just randomly select half of a certain demographic to show the ad to, and then show that those users are more likely to make a purchase later.

<comment><USER19> Theoretically yes, but I think with standard Facebook ad units and regular consumer brands sold in stores they'd be pretty unhappy with the results...

(since _probability of giving stores your contact details post purchase_ and _susceptibility to marketing messages pre-purchase_ are probably positively correlated and Facebook is permanently running concurrent trials of different kinds and being very selective about what they share, any positive effect they did manage to identify should be viewed as an almost certain overstatement of the ads' actual effectiveness anyway)

</comment></comment></comment><comment><USER21> Who gives their phone number to store clerks? "Sorry, it's unlisted."

<comment><USER22> As hard as it is to believe, I'm sure plenty of people give out their phone numbers when asked. I have personally witnessed many many people (including my wife) give out their number at checkout without hesitation. I guess the fact that this is continued practice means that it actually works.

This may vary by geography...my observations are from Canada.

</comment></comment><comment><USER23> Is anyone else frightened the increasing efficiency of capitalism? Since when does user-experience depend on best fulfilling my consumer desires? Shouldn't I try to soften this impulse?

</comment><comment><USER24> And this is why I did not give my phone number to facebook and why I use a different email for everything.

It's unfortunate that keeping one's privacy requires a lot of knowledge and work.

<comment><USER25> > It's unfortunate that keeping one's privacy requires a lot of knowledge and > work.

I wonder if the more vexing problem is that the market for privacy solutions seems largely unproven at scale. While people seem to value privacy when polled individually, they seem to vote the other way as an aggregate body.

Smart privacy products could take the knowledge and work out of it, but will the market support them?

</comment></comment><comment><USER26> Amazon product pages already have Facebook tracker embedded, so Facebook knows what you are looking at. No need to provide your phone number.

<comment><USER27> Is that visible via NoScript?

<comment><USER26> I'm using disconnect.me</comment></comment></comment>


An alternative to solid tantalum capacitors - <AUTHOR> http://www.electronicsweekly.com/news/now-alternative-solid-tantalum-capacitors-2017-03/ <comment><USER3> Dad used to be head of QC at Kemet (he retired from there in the early 90s). They were known for high-reliability Tantalums (used in various ICBMs, undersea cable repeaters, and the System 360). These days they make many different styles of capacitors and other components.

They did 100% inspection - _twice_ , to ensure they shipped a good product. Like many electronics production lines, the yield of working product was important to track. And they didn't have the ability to ship a capacitor with part of it disabled, like Intel used to do with the 80486DX and 80486SX (the SX was a DX with a non-functioning floating-point math processor).

Story time: They received Tantalum via truck delivery. And one day the truck driver failed to clear a rail crossing in time and was hit by a train. He was fine, but the expensive metal was scattered along the rail bed. Obviously they couldn't use it after the accident, as it was contaminated. So they paid employees to go out there and pick up the pieces so they could be returned to the smelter and get credit for it.

</comment><comment><USER4> Tantalum died years ago. It was a suicide.

Multiple scarcity events, skyrocketing prices, and then in 2014 you couldn't buy them even if you wanted to.

Purchasing agents were seen chasing design engineers with pitchforks by torchlight.

Ceramic MLCC's have filled their spot. Better, much easier to use and safer.

And the modern poly hybrid electrolytics are amazing, as well.

Tantalum poly caps are probably great, but the fear is still there and too recent - so I doubt they will get very popular except in small specific instances where they are absolutely better than anything else.

<comment><USER5> Ceramic MLCC's aren't without their problems, especially in the smaller packages. Just take a look at a voltage vs. capacitance curve in an 0402 package ceramic cap. When used at the rated voltage, they don't have anywhere near the capacitance they state. Also the temperature vs. capacitance curves are less than appealing.

That said, I think a lot of engineers out there have been burned (sometimes literally) by using tantalum caps in the past and are likely not to design them in in the first place these days. I know we moved away from them completely in my last job because enough exploded to scare people off.

EDIT: See dragontamer's comment below for more. Explained better than I did.

<comment><USER6> Do you have any suggestions for what to use for a regulator eg. lm2940 - <USER2> needs something like 22uF, low ESR on the output pin for stability? MLCCs are expensive and not very available in this capacitance range.

<comment><USER5> Sorry, I can't really recommend anything without more information. There's just too many variables.

I briefly looked at the datasheet for the regulator and it has some constraints for the output cap that should help guide your choices. For example, you need to look at what temperature range you expect the regulator/cap combo to be working at, as certain dielectrics are sensitive to temperature changes [1]. If you need stability over a wide range, you might go with an X7R or better, otherwise X5R might do. You will also have to look at derating the capacitance for the operating temperature - you might find that in a hot environment you actually need a 47uF cap or greater to meet the minimum 22uF output capacitance requirement of the regulator.

The other main thing to consider is operating voltage. The regulator you list is adjustable, so you will need to pick an output cap that has an appropriate capacitance at the voltage you plan to run the regulator at. The curves drop pretty steeply, so it's really important to analyze this.

For ESR you should look at manufacturer websites. They often have a "picker" tool that shows graphs of that (it's dependent on frequency!). You probably won't have trouble finding caps with a low enough ESR value for this application as long as you stay away from electrolytics.

Also, you can consider paralleling some lower value capacitors to achieve the capacitance you need, and reduce the ESR a little. I wouldn't use it as an ESR lowering strategy however [2]

[1]: [https://www.maximintegrated.com/en/app- notes/index.mvp/id/55...](https://www.maximintegrated.com/en/app- notes/index.mvp/id/5527)

[2]: [http://electronics.stackexchange.com/questions/152549/esr- an...](http://electronics.stackexchange.com/questions/152549/esr-and-parallel- capacitors)

</comment></comment></comment></comment><comment><USER7> For those wanting to learn facts (as opposed to lore) the video at Hackaday gave me more insight on capacitors then any other single resource I've come across.

[http://hackaday.com/2016/07/09/capacitors-are-simple- right/](http://hackaday.com/2016/07/09/capacitors-are-simple-right/)

[https://youtu.be/ZAbOHFYRFGg](https://youtu.be/ZAbOHFYRFGg)

<comment><USER8> How ultracapacitors work (and why they fall short)

[https://gigaom.com/2011/07/12/how-ultracapacitors-work- and-w...](https://gigaom.com/2011/07/12/how-ultracapacitors-work-and-why-they- fall-short/)

</comment></comment><comment><USER9> The article focuses heavily on the angle of tantalum ore supply -- but it's worth noting that Niobium capacitors [1][2] have been gaining prominence since the 2002 for the same reason. Niobium-based capacitors have some desirable properties [2] but are roughly comparable to tantalum-based ones; and Niobium ore is much more abundant.

[1] [http://www.avx.com/products/niobium/](http://www.avx.com/products/niobium/) [2] [http://www.imaps.org/adv_micro/2004may_jun/pages/article_nio...](http://www.imaps.org/adv_micro/2004may_jun/pages/article_niobiumoxide.pdf)

</comment><comment><USER10> Tantalising news. The alternative is still tantalum-based if I understood correctly, but uses less tantalum. The article doesn't mention how much less.

<comment><USER11> Well, "solid" doesn't have to mean "not a liquid/gas/plasma", it can also mean "all the way through". For instance a table made of "solid oak" is not trying to say it's not a liquid, it's trying to say it's not veneered particle board.

That's how I interpreted the use of "solid" here, but I'm no electronics engineer of course.

<comment><USER12> "Solid" in electronics means the former (state), not the latter.

<comment><USER13> It means solid as in the phase of matter in this case. The electrolyte in a tantalum capacitor can either be a solid or liquid.

</comment></comment></comment></comment><comment><USER14> The past three companies I've worked for that were doing circuit board design expressly forbid the use of tantalum capacitors because they are surface mounted (SMT) two-terminal parts that have polarity. In other words, tantalum caps have a + and a - terminal and are damaged when reverse voltage is applied. Blanket ban on tantalum use was to avoid mistakes during PCB assembly in manufacturing where caps are oriented incorrectly.

Edit: Maybe I misunderstood the reason for a blanket ban of tantalums. The fact remains, the ban was real.

What are some of the places where tantalum capacitors are required and ceramic capacitors just can't get the job done?

<comment><USER15> As a hobbiest, I usually see them in high stability power supplies.

<comment><USER7> Probably because when designed right (they are far more finicky then ceramic) they typically offer higher energy density.

<comment><USER16> Higher capacity you mean (for a given volume), that and also very low leakage current so if you want to make a very efficient device then tantalum might pay off. Another reason is that electrolytic caps are usually wound aluminum sheets which act as a coil. If you don't want any parasitic inductance tantalum is better in that application (better frequency response).

<comment><USER17> Tantalum caps have much worse leakage current than ceramics.

The debate for most designs is not tantalum vs. electrolytic, it's electrolytic vs. solid vs. ceramic. And ceramic usually wins.

</comment></comment></comment></comment></comment><comment><USER18> Interesting article, it reads like they are trying to rehabilitate the tantalum capacitor market.

Back when NetApp was got a deal to provide filers for IBM to re-label the word came from IBM that all Tantalum capacitors had to be designed out of the system. There was an interesting project in engineering to purge the designs of all tantalum capacitors. IBM's reasoning was that they had been the source of fires as I recall.

As a result I find myself always hesitating to use one (even in silly one- offs) and other engineers I've met have similar habits.

</comment><comment><USER19> Great article. Was not aware there is this much stigma around tantalum caps. There are times when I am forced to avoid ceramic caps for better high frequency handling. It looks like polymer is the way to go - better longevity and no ethical issues.

</comment><comment><USER20> Funny that the alternative also uses tantalum and in its solid state... I know, I know, "solid tantalum" refers to a technology and the alternative is a new technology, or at least an improvement over the older one.</comment>


Why Tim Cook Is Steve Ballmer and Why He Still Has His Job at Apple (2016) - <AUTHOR> https://steveblank.com/2016/10/24/why-tim-cook-is-steve-ballmer-and-why-he-still-has-his-job-at-apple/ <comment><USER2> I thought this was going to be click bait, but it's actually a very well written article.

Are there any other examples of visionary CEOs passing on the torch to execution CEOs? Would be interesting to see if something like this lead to the downfall of companies like Kodak.</comment>


Sheep mustering with a quadcopter - <AUTHOR> http://www.youtube.com/watch?v=OP15Jm57Hmk&list=UU5oSDU1IxwEztDyd975yu8g&index=1&feature=plcp

<comment><USER2> This is brilliant. Next they have to automate it.

<comment><AUTHOR> I agree. I immediately thought of this: [http://techland.time.com/2012/02/01/watch-swarm-of- autonomou...](http://techland.time.com/2012/02/01/watch-swarm-of-autonomous- robots-flies-complicated-formations/)</comment></comment>


A great UI is invisible - <AUTHOR> http://tympanus.net/codrops/2013/03/21/a-great-ui-is-invisible/

<comment><USER2> People who say this dont understand what a UI is. If that was true, then God would not have invented the eye.Flowers wouldnt have color. Trees wouldnt have texture. Jony Ive was great because he kept the window minimalistic.If you kept OS UI elements minimalistic and non skeumorphic, you would end up with Windows 8 Metro. But,Yes I agree there needs to be a trade off. UI is all about tricking a user into virtual reality.</comment>


A New Kind of Light Bulb-Alternative to LED and CFL - <AUTHOR> http://www.mercurynews.com/business/ci_28721553/new-light-bulbs-offer-alternative-leds-and-cfls

<comment><USER2> I read this in the paper and was thinking, gee, a light bulb that uses more energy, costs more, and isn't dimmable than the current champ LED bulbs. Does not sound like a winning strategy.</comment>


Against guilty pleasures: Adorno on the crimes of pop culture - <AUTHOR> https://aeon.co/essays/against-guilty-pleasures-adorno-on-the-crimes-of-pop-culture <comment><USER2> The title should be: "Against guilty pleasures: Adorno on the crimes of pop culture and inequality.

Wouldn't call it clickbait considering the other aspect is covered. Great observations on the effects capitalism on culture, particularly on freedom and work.</comment>


Since March 30, 2020 Six Lawsuits vs. Zoom Filed in U.S. Federal Courts - <AUTHOR> https://www.courtlistener.com/?q=&type=r&order_by=dateFiled%20desc&case_name=Zoom%20Video%20Communications&filed_after=03%2F30%2F2020 <comment><USER2> Sad</comment>


Windows 95 almost had floppy insertion detection but the training cost was prohibitive - <AUTHOR> http://blogs.msdn.com/oldnewthing/archive/2009/04/02/9528175.aspx <comment><USER2> I still don't get why they couldn't just spin the disk up, check if it exists using that message and then check the bit at the same time. Do that once during installation and there's no user intervention.

<comment><USER3> From the article:

"You can't just try to figure out what type of drive the user has by comparing the clever technique against the boring "turn on the floppy drive light and make grinding noises" technique, at least not without displaying a warning to the user that you're about to do this—users tend to freak out when the floppy drive light turns on for no apparent reason."

What they should have done is wait for the disk to be used for some other reason, and then test it, and record the results. Just in case the drive changed, then after every reboot verify that it still makes sense.

<comment><USER2> I saw that, and it was a cop-out excuse in my opinion. During installation, usually unattended too, your computer does all sorts of unexpected things. It reboots, the screen switches off and on, it freezes up for a while. Most old systems had the floppy grind away on boot as well. I fail to see the issue (and it doesn't sound like they even tested it with any users).

</comment></comment></comment><comment><USER4> I don't quite get why it matters. Guess, then when the drive is properly used for the first time, test, change over if required.

After that, quietly stop spinning up and grinding the floppy drive when not required.</comment>


Prince Rupert's cube - <AUTHOR> https://en.wikipedia.org/wiki/Prince_Rupert%27s_cube <comment><USER2> A video is worth a thousand words of theory:

[https://www.youtube.com/watch?v=-2jjgHsxEu4](https://www.youtube.com/watch?v=-2jjgHsxEu4)

<comment><USER3> I wish more of mathematics was visual. That's the mode of thinking I employ the most, and I excel at spatial problems.

I wish higher level mathematics and physics paid more attention to the use of visual schematics and diagrams. So much can be communicated with them. Words often pale in comparison.

<comment><USER4> I would like to recommend the 3b1b's[1] YouTube channel.

His procedurally generated videos really make you think of certain math that looked unintuitive or hard to explain in a truly intuitive, visual way.

His series on linear algebra was very eye opening to me, as well as many of his videos about subjects I was initially failing to understand.

[1] [https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw](https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw)

<comment><USER3> Thanks so much for sharing! This looks fantastic.

</comment></comment></comment></comment><comment><USER5> Another nice puzzle:

A cube looks like a square from three orthogonal directions. A cylinder can look like a square from infinitely many directions, but they are all coplanar. Can you find a convex shape that looks like a square from more than three directions, without all of them being coplanar? In particular, can you find a convex shape that looks like a square from two distinct sets of three orthogonal directions? Can you find all such shapes?

<comment><USER6> Orthographic or perspective projection?

<comment><USER5> I only know the solution for orthographic. But it seems like perspective would be too easy, just make any shape with many square sides, and put the cameras close to the sides.

</comment></comment></comment><comment> shaded-enmity Another interesting thing named after Prince Rupert is the Prince Rupert's drop for anyone interested: [https://www.youtube.com/watch?v=k5MORochIDw](https://www.youtube.com/watch?v=k5MORochIDw)

<comment><USER7> I recommend trying them with capillary tubes, you can melt them with a cigarette lighter

</comment></comment><comment><USER8> I knew of Prince Rupert's drop before[1]. Reading about Prince Rupert's cube sent me down the rabbit-hole of reading up on Prince Rupert himself.

Why do we no longer have Renaissance men/women today, contributing to the sciences, philosophy and the arts? What did we lose?

[1] [https://en.m.wikipedia.org/wiki/Prince_Rupert%27s_Drop](https://en.m.wikipedia.org/wiki/Prince_Rupert%27s_Drop)

<comment><USER9> > Why do we no longer have Renaissance men/women today, contributing to the > sciences, philosophy and the arts? What did we lose?

A lot of the low-hanging fruit has already been claimed, and it's very difficult now for amateurs to make discoveries in mathematics and physics. There are people today doing amazing research, it just takes a career and a team (and in many cases expensive equipment) to do so.

If by "Renaissance men/women" you mean "well-versed/engaged in many topics", well, you just need to open your eyes. There are many folks like this now, likely millions. It was a bit more of a rarity a few hundred years ago, so it was much easier for these individuals to be documented/preserved.

</comment></comment><comment><USER10> Interesting that the optimal solution is not "slide it along the space diagonal" but rather "slide it parallel to a face".

<comment><USER11> I might be wrong about this, but as far as I can see the larger cube slides parallel to an edge and not a face. On top of that, I think the cube passing through would still be sliding parallel to an edge, even if it were to slide along a space diagonal, so those two wouldn't be mutually exclusive. Unless I have failed to visualize it right ok my head.

</comment></comment><comment><USER12> Mathologer on Rupert's cube: [https://www.youtube.com/watch?v=rAHcZGjKVvg](https://www.youtube.com/watch?v=rAHcZGjKVvg)

</comment><comment><USER7> looks like a fun model to 3d-print

</comment><comment><USER13> So, cubes have a margin of 6% play, if you need to pass any other cube through a given cube.

<comment><USER13> Wow, a downvote for paraphrasing a wikipedia article.

      Its side length is approximately 6% larger than
      that of the unit cube through which it passes.

I fail to see any error, based on that verbatim quote.

<comment><USER13> Good job. Keep downvoting.

</comment></comment></comment><comment><USER14> I reckon you could stretch this to a 30 minute whiteboard session to answer why (some) manhole covers are round.

<comment><USER15> And then fall in the Reuleaux triangle rabbit hole.</comment></comment>


The Problem with Friendly C - <AUTHOR> http://blog.regehr.org/archives/1287 <comment><USER3> Since, according to Chandler Carruth, the aim for Clang is to not do optimizations based on undefined behaviour without a corresponding instrument in ubsan[0], I don't see much traction on this well-defined/boring C effort.

You know, in my experience, things would be great if people actually turned on warnings. I write all my new code with -Weverything with a few noise categories turned off. Everybody should build code at this level from day 1.

[0] [http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html](http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html)

<comment><USER4> > Everybody should build code at this level from day 1.

On the project I run, the CI will reject your code in CR if it doesn't compile under two different compilers with all but a handful of warnings turned on as errors, runs and passes tests, and passes various linters, including a check for undocumented types, variables, parameters and return values. IMNSHO, every project should be like this. Once it's setup, it's a breeze and doesn't impede development speed at all.

</comment></comment><comment><USER5> If ((uint32_t)x<<32)==x on one system, and ((uint32_t)x<<32)==0 on another, why is that a problem? The issue isn't that one system behaves differently from another. The issue is that compilers take it upon themselves to decide that because code would behave differently on these different systems - <USER2> is why the standard leaves it undefined - it can be considered to fall into some kind of black hole that allows the compiler to do whatever it likes.

But why can't it just produce something different on each system?

Allow me to call it as I see it: the modern interpretation of undefined behaviour is bullshit. What compilers do today should be the recourse of absolute last resort, and the sort of thing that makes its authors feel bad. But it seems to be treated as a matter of course.

I don't know what to say.

Mandatory reading: [http://robertoconcerto.blogspot.co.uk/2010/10/strict- aliasin...](http://robertoconcerto.blogspot.co.uk/2010/10/strict- aliasing.html) ("Everyone is fired"); [https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWi...](https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWignU/o8GGp2K1DAAJ) ("these people simply don't understand what most C programmers want"); [http://blog.metaobject.com/2014/04/cc- osmartass.html](http://blog.metaobject.com/2014/04/cc-osmartass.html) ("please don't do this, you're not producing value")

<comment><USER6> The, to me, obvious thing to do with code with undefined behaviour is to emit an error and refuse to compile it. Programmers should never rely on undefined behaviour.

Then again, I think languages shouldn't have undefined behaviour and that programmers who use languages with undefined behaviour deserve what they get.

<comment><USER7> The problem, as Regehr (the author of this submission) has pointed out many times before, is more subtle than that. Because certain behavior is considered undefined, compilers are allowed to assume the code it is compiling _is_ well defined, and optimize accordingly. That can cause simple bugs to have mysterious effects. For example:

        a->thing = 42;
        if (a == NULL) {
          return;
        }

Obviously that code is wrong; I should check for NULL before using a. But because I dereferenced a, the compiler can assume a must not be NULL, and just removes the null check as dead code. This scenario has caused problems in the kernel, and made bad bugs even worse.

<comment><USER8> But the compiler could just as well emit a warning "useless NULL comparison" instead of blithely assuming that the programmer intentionally wrote a book expression. That wouldn't handle every case of UB, but would handle many.

<comment><USER9> A warning on removed dead code isn't helpful because dead come is legitimately removed all the time. No one would ever heed it.

<comment><USER10> If you ignored dead code produced by macros and limited the check to function- scope, I think you'd mostly eliminate false positives.

</comment></comment></comment></comment></comment></comment><comment><USER11> I think the most important point of Friendly C is not to define _the_ behaviour for what would otherwise be undefined, but to define _a_ behaviour; from this point of view, it would be unnecessary to argue over the examples he mentions like memcpy() vs memmove() and integer shifting --- it only suffices that every implementation define the behaviour, and what that behaviour precisely is can differ between them. A lot differs already between platforms, and so all this basically means is to document those differences. This agrees with the spirit of the language as a "high level assembler", removes all the undefinedness, and would be entirely unsurprising to most programmers.

 _The situation gets worse when we start talking about a friendly semantics for races and OOB array accesses._

I don't have anything to say about races, but OOB array accesses should simply do what you'd expect the hardware to do: attempt to access memory at the location the array indexing equation gives. It may segfault, or it may access some other contents in memory. That's what any C programmer would probably expect.

<comment><USER12> You have to look deeper for the OOB array access question. For example, imagine I have code like this:

      if (a > 1)
        b++;
      array[b] = 0;
      c = a + 10;

Under your suggested semantics, can the compiler use the value loaded from `a` at the point of the if() statement to calculate `a + 10`? Or does it have to emit a reload of `a` after the array access, in case `array[b]` was an OOB access that overwrote `a`?

<comment><USER13> I'm not seeing the deeper question, whereas what 'userbinator' said still makes sense to me.

The compiler's implementation defined behavior would simply be "if you tell me to write a value to an address, I'll create assembly that tries to write that value to that address". That's all. If this address is outside the allocated range of the array, there is no guarantee that it's safe that write this value, or that it won't break something else.

So in your example, no, the compiler is not required to reload 'a'. The compiler is allowed to presume that the array[x] syntax will have no affect on the value of a local variable, whether that variable is stored in a register or on the stack. The compiler is not guaranteeing safety, just best effort.

<comment><USER12> When you're saying that the compiler should be allowed to optimise under the assumption that OOB array accesses don't clobber other variables, this means that OOB array accesses can make very weird things happen indeed. For example:

      if (a > 1)
          b++;
      array[b] = 0;
      if (a > 1)
          foo(a);

We might see foo() called with argument 0 when that's apparently impossible - the OOB write has apparently "reached forward" (it can also "reach backward").

This is why it ends up just being "undefined behaviour" \- to do better either you have to somehow exhaustively document all the kinds of weird things that can happen ("it writes to the memory" isn't enough, because of the way that can interact with the optimiser) or you have to unreasonably constrain the optimiser.

</comment></comment></comment></comment><comment><USER14> Tone: I do not mean this as sarcasm or merely chasing fashion, I'm quite serious. As both theory and practice are showing, you're never going to be able to get the consensus you want out of C. There's no "saving" C... not because that's somehow mathematically impossible, but simply because the project is too staggeringly large for us to even wrap our heads around. It would literally be easier to get people to start using another language...

... so, why not do that then? We have, for perhaps the first time in 40 years, a candidate for a systems language that can truly replace C, that has truly different semantics (i.e., not C++, which is still profoundly C with a lot of stuff bodged on the side). I'd suggest trying to use Rust, and working with that team to nail down whatever remaining issues may yet be undefined in Rust that may cause trouble in the future. Whatever remaining practical problems there may be (and my impression is that that isn't really a long list), work on resolving them.

Again, I am not being sarcastic or cynical; it is truly my estimate that it would be easier to get people behind that than to fix C at this point. Probably by a good two or more orders of magnitude. Obviously we're not going to rewrite all existing code. Obviously there's a lot of code still to be written that is so deeply embedded in C that there's no practical alternative to adding more C to it, even in a world of FFI support and such. But if the people who care about the idea of BoringC or Friendly C start getting behind Rust, getting their hands dirty with it, and doing what the Mozilla project is doing to find places where they can start slotting subsystems in cleanly to existing code bases, you may just be able to start creeping out of the mess we're in now.

And... who knows. If this becomes acceptable, then generally considered a good idea, then best practice, then perhaps even something you need to do unless you want people to think poorly of you... perhaps real change will prove to be less intractable than we thought. People consistently overestimate change in the short term but underestimate in the long term. It is, perhaps, not too much to hope for that huge swathes of our fundamental systems could be running on Rust in 20 years, instead of C.

So I'll reemphasize once again... yes, I know I'm proposing a staggeringly enormous change. The only thing that it has going for it is that I still think it's easier than the staggeringly-enormous-squared other choice.

 _Something 's_ gonna happen. After all... what's the alternative? That C is still the foundational language of the entire computing world in 2035?

Seriously?

<comment><USER15> I'll take the bet that in 2035 it's still going to be C/C++ (or a C derivative like Boring C). Because rewriting all that code is an economic impossibility. There's a very long way to go before the rate of foundational Rust code written exceeds the rate of foundational C/C++ code written. And even if you manage to have 100% Rust and 0% C/C++ code being written, you still have a huge legacy to write, which literally costs billions of dollars (ALL operating systems, ALL browsers, ALL interpreters (Python/PHP/Perl/...), ALL compilers (GCC, LLVM), ALL web servers, etc.)

Honestly I think your view of technological adoption is fairly naive -- I don't see much content here other than "everyone get behind Rust!".

IMO the more realistic approach is a systems approach: make it so that badly written C code doesn't completely hose your system. I like the application compartmentalization work (Chrome style, DJB style), and capability work like Capsicum. And LangSec work in making safe parsers. The trusted computing base has to be reduced. Not every line of C code should run in a trusted context!!! Principle of least privilege. We know (or should know) all this stuff.

That is many of orders of less magnitude less work / cost, and I think actually feasible. Coherent and secure systems architecture is more achievable than everybody writing perfect C code or everybody switching to another language.

Another thing the Rust community should be working on is easy and efficient IPC with C programs. So you can rewrite a secure core in Rust and communicate with legacy C/C++ running in an untrusted OS context.

And also fixing the mess that is Linux containers, so it isn't so difficult to secure them (i.e. see Docker's security issues)

<comment><USER16> I haven't used it yet, but apparently Rust's FFI with C (in both directions) is quite good:

[https://doc.rust-lang.org/book/ffi.html](https://doc.rust- lang.org/book/ffi.html)

<comment><USER15> That doesn't do IPC though right? When I say IPC, I mean where you have a Rust process and and a C/C++ process running with different privileges. When people say FFI, they mean Rust code and C code running in the _same_ process.

I thought Chromium had a library for this (for multiple C++ processes), but I guess it is sort of ad hoc now?

[https://www.chromium.org/developers/design- documents/inter-p...](https://www.chromium.org/developers/design- documents/inter-process-communication)

[https://www.chromium.org/Home/chromium- security/education/se...](https://www.chromium.org/Home/chromium- security/education/security-tips-for-ipc)

<comment><USER17> [https://github.com/pcwalton/gaol](https://github.com/pcwalton/gaol)

<comment><USER15> This seems like a great start, but it would be far more useful if there was a C/C++ side. I only see Rust examples, which makes me think it is for Rust <-> Rust communication.

Though it's great to see this, because just rewriting in Rust -- while fantastically expensive -- isn't necessarily enough. You need multiple security measures. The grandparent comment was mistaken about this.

</comment></comment></comment></comment></comment></comment><comment><USER18> I think this is a fundamental problem with C. Both of the language itself, but also of the C programming culture of insisting on very low levels of abstractions.

Bugs and undefined behaviour is too easy for programmers to write when the level of abstraction is low. Too much boilerplate to get wrong. But too low a level is also bad for an optimizer. It cant assume it understand the programmers intention with the code.

C++ tries to fix some of this by creating a higher level language and library on top of C. Low level code is considered unsafe, when higher level abstractions can be used as replacements.

Some examples of replacing low level with high level. Raw (owning) pointers and manual memory management are replaced with RAII value semantics and occasionally smart pointers. Raw loops are replaced by container iteration and better yet by STL algorithms. Casts are replaced by templates. Threads and mutexes are replaced by tasks and async, etc.

Eventually the idea is to subset C++ so that we can rip the C out of C++.

[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)

<comment><USER19> I don't think C is bad for optimizers. What language consistently generates faster machine code than C?

<comment><USER20> Fortran, but Fortran is also quite low-level. It can do some optimizations that C can't because it disallows pointer aliasing.

<comment><USER21> restrict?

</comment></comment></comment></comment><comment><USER22> You have to choose whether or not you want the compiler to generate code that spends time doing things that the programmer didn't ask for.

If you write a library with a function which accepts variables x and y and computes x[y] (or x<<y), there's no way for the compiler to know in advance whether the user will pass in well-behaved values for x and y. If you insist on the behavior being defined in pathological cases, then the compiler _must_ add some kind of branching logic in there to check what's passed in at runtime. In other words, spend time doing things the programmer didn't ask for.

Maybe when we make more progress with formal proof-generating languages, we can create a "friendly" C where the compiler refuses to compile the code until it's accompanied by formal proofs of UB-avoidance.

<comment><USER23> _" Maybe when we make more progress with formal proof-generating languages, we can create a "friendly" C where the compiler refuses to compile the code until it's accompanied by formal proofs of UB-avoidance."_

That's entirely feasible. I headed a team which did that for a dialect of Pascal over three decades ago.[1] It's since been done for Modula III, Java, Spec#, and Microsoft Windows drivers.

One reasonable thing to do is to have the compiler generate run-time assertions for every statement which has a precondition for defined behavior. All pointer dereferences get "assert(p != 0)". The shift problem in the original article gets "assert(n > 0); assert(n <= 32);" Now everything has run-time checks.

Then you try to optimize out the run-time checks, or at least hoist them out of loops. A simple prover can remove about 90% of the checks without much effort.

[1] [http://www.animats.com/papers/verifier/verifiermanual.pdf](http://www.animats.com/papers/verifier/verifiermanual.pdf)

</comment></comment><comment><USER24> Fun fact about large shifts being undefined.

With a 32 bit x, the expression x << b | x >> (32 - b) can be translated to a single "roll x b bits to the left" instruction. But it is only possible if >32 shifts are treated as undefined.

<comment><USER25> Not true. In fact, modern x86 backends recognize the safe rotation idiom and also translate it to a single ROL instruction: [http://goo.gl/NCMEVu](http://goo.gl/NCMEVu) [http://goo.gl/9Ytsz2](http://goo.gl/9Ytsz2) [http://goo.gl/vbzHNW](http://goo.gl/vbzHNW)

</comment></comment><comment><USER26> I must be missing something here, but can't you simply not invoke undefined behavior in your program? That way, you don't have to worry about what your compiler will do when it encounters undefined behavior.

<comment><USER27> That's possible.

It requires extreme care (assuring no memeory leaks is comparably a walk in the park), and will make your code much less performant. But it's possible.

</comment></comment><comment><USER28> It's easier to expand than contract. When the same decision is faced multiple times, it will be made multiple ways, and it's very difficult to remove one of those options once it's in use. On the other hand, if you remove the decision by standardizing on one of the options, you can always allow the other option later.

Working in Perl, I run into this a lot. When 'there is more than one way to do it' is a driving principle, it's easy to be inconsistent in usage and design. There's a tradeoff here -- it's easier to write code, because you can pretty much write your solution however it pops into your head. However, it's harder to read and maintain, because you have to recognize many many different patterns of usage. When code has been around for awhile, it starts to get an eclectic mix of patterns blended together, which can be frustrating to run into when you're trying to fix that code.

How do other people deal with this? Part of it is language choice, I'm sure. Large companies tend to use languages with less stylistic freedom, which helps teams write code more consistently. But within a given language, how do you balance freedom and consistency, so that people can understand each others' code effectively without being overly burdened by restrictions about how they can write code?

<comment><USER8> Working in say Java doesn't really force consistency, it just pushes the inconsistency up a level. Programmers still get painfully "clever" and idiosyncratic.

</comment></comment><comment><USER29> Being an ignorant fool with an uninformed opinion, I would like to see a C compiler that is evaluated and critiqued not only based on the warnings and errors it generates but, more importantly, on the assembly it generates.

Namely, how compact and readable is the generated asm? When we read the asm, can we easily follow what the compiler has done and _why_?

As an ignorant fool, in my mind C is still a shorthand for writing assembly, to save old programmers from continuing to be or new programmers from becoming "assembly language programmers". Obviously many years have passed and "C" has become an institution and means much more to so many people. Aopologies to those people. I am just a fool.

I see the _theoretical_ "C compiler" as nothing more than a code generator, spitting out assembly. Obviously the _practical_ C compiler is very different. Base on the way it's used, it seems inextricably linked with a "preprocessor" (glorified sed).

It is said that asm has a "one to one" relationship with machine code. Theoretically, we can look at asm and determine its machine code equivalent without any "clever" algorithms.

My humble, ignorant fool's opinion is that it would be better if C had a closer relationship to the asm the "C compiler" generates.

Maybe not "one to one" but at least "predictable, boring".

Forgive me for having opinions about overly complex things few people can comprehend (e.g., a "modern C compiler"). I am just an ignorant fool who likes code generators. Especially ones that output assembly.

<comment><USER30> I agree it would be an interesting exercise to write a compiler optimized for assembly readability. But I don't think there is enough demand for such a thing so that it will get written.

It also would be interesting if those who think there is enough demand start a crowdfunding campaign to prove that there is enough demand.

<comment><USER31> > But I don't think there is enough demand for such a thing so that it will > get written.

Isn't that basically what we have academia for?

<comment><USER30> I don't think there is enough academic prestige for a compiler optimized for assembly readability either.

</comment></comment></comment></comment><comment><USER32> I applaud the author for reaching the daunting part of this project and reacting with humility appropriate to the difficulty. I hope they continue in this effort, because they sound like the right person for the job.

There are going to be a lot of trade offs in any friendly C spec. Appreciation for both sides of a trade off is valuable in making good decisions.

</comment><comment><USER33> How exactly would performance degrade by defining a virtual machine for C programs to run in where assurances are given that all of the standard behavior is fully defined -this operation either fails, or gives THIS result-? It sounds like it could be massively useful, at least for non-realtime applications.

<comment><USER34> pcwalton claims a factor of 3x to 5x elsewhere in the thread.

Honestly I think the biggest problem here is social. Every programmer thinks they're smarter than others. If you give them a button marked "remove all safety checks, increase performance by 1%", they'll press it. Those who wouldn't press it have probably already moved on from C.

</comment></comment><comment><USER35> The Android team idea didn't make any sense to me.

<comment><USER36> I didn't get that either. They're shipping a totally broken locale.h and should be the last persons ever to get involved in C-language design.

</comment></comment><comment><USER37> I wonder what Ritchie would be thinking of that.

Also, if friendly C is a problem, does that mean that friendly C++ is in the realm of the impossible?

</comment><comment><USER38> Target a virtual architecture (LLVM IR). Run the original code in an emulator for the target system (QEMU); give warnings where the two differ, with a switch for the virtual architecture to mimic the behavior of whatever architecture you need.

You get friendly C, a new way to think about warnings, and your old code can still be compatible with the new virtual architecture.

Next up, world hunger.

<comment> def- You can't simply run code for all possible inputs.

<comment><USER38> No, but you can certainly exercise it well. It might be a degree of confidence measure. Combined with property verification (so, formal verification), you'd get a damn good idea they'd be close.</comment></comment></comment>


Samsung CEO says all its products will be connected by 2020 - <AUTHOR> http://www.technologyreview.com/news/533941/ces-2015-the-internet-of-just-about-everything/

<comment><USER2> Isn't this just hype? I still don't understand why it's going to be helpful to have something like my refrigerator connected. I've heard rumors of having the refrigerator tell you when you're out of certain products, but this is useless for people like me who rarely buy the exact same products! The internet of things is a cool idea for some products, but kind of gives me the feeling of being a gimmick overall.

</comment><comment><USER3> I would've been impressed if he said 2016.</comment>


Pentagon to deploy huge blimps over Washington, DC for 360-degree surveillance - <AUTHOR> http://rt.com/usa/army-raytheon-jlens-blimps-594/

<comment><AUTHOR> I was wondering how the government started making a profit on its costs:

" _using the JLENS instead of traditional, fixed-wing surveillance aircraft, could bring the cost of operation down by as much as 700 percent._ "

Alas, this appears to be the Russians making a muck of things. From the Raytheon fact sheet:

" _Depending on the kind of aircraft used, a fixed-wing surveillance aircraft is 500–700 percent more expensive to operate than a JLENS_ " [1].

[1] [http://www.raytheon.com/newsroom/rtnwcm/groups/public/docume...](http://www.raytheon.com/newsroom/rtnwcm/groups/public/documents/content/rms13_idex_jlens_article.pdf)

</comment><comment><USER2> The fact that it will make identifying anyone who goes to protest there very easy, is just a (happy) coincidence.</comment>