On the Symmetry between Microsoft and Apple - <AUTHOR> http://krugman.blogs.nytimes.com/2013/08/24/on-the-symmetry-between-microsoft-and-apple/?_r=0 <comment><USER3> Stopped reading at: "[Apple is] selling products that are little if any better than competitors, at premium prices. How can it do that?"

This is such a ridiculous statement. Apple's notebook line is dominating, not because it's "little if any better" than the competitors, but because it's head and shoulders above the competition. They've systematically and iteratively refined, both in software and hardware, all the most important bits of portable computing. Battery life. Display quality. Weight. Size. Noise. Keyboard. Trackpad. Durability.

<comment><USER4> I'd say the design, keyboard and trackpad are rather subjective if you think they're "systematically better". The Retina display currently is better than other offerings, but even the Nexus 10 offers similar DPI. Give me a ThinkPad with a N10 display over a MacBook anyday.

Also, there's no real reason Lenovo, Dell, etc. can't start shipping higher quality displays, keyboards, etc. While Apple's products are apparently solidly engineered, most of it is perception and design.

<comment><USER5> > Also, there's no real reason Lenovo, Dell, etc. can't start shipping higher > quality displays, keyboards, etc. While Apple's products are apparently > solidly engineered, most of it is perception and design.

I disagree with this statement entirely, for one big reason: you're leaving out Apple's mastery of the supply chain.

There are certainly component makers out there that will build stuff and slap it together for you, but Apple is the champ of running the whole stack with a relentless eye towards quality control. Think about the design and manufacturing of an iPhone, iPad or MacBook Pro. These are not things that you can compete with easily.

There is a massive amount of effort involved in order to build a machine of comparable quality to an Apple device, and that remains one of their key advantages in the market. This is also an advantage they are dead-set on keeping. Most competitors don't have anywhere near the supply chain controls that Apple commands, and often don't even design their own devices (Dell).

Finally, quality is a very important component of design. The prettiest laptop in the world is bad design if it falls apart or feels flimsy. Think less about design being the way something looks - instead, add how it feels, sounds, _smells_ even, and every other part of the way you interact with it. That is design.

<comment><USER4> Dunno about your experience, but mine and everyone I've talked to seem to think IBM ThinkPads had top notch build quality (minus the gripe about the screens). The keyboards, even on the 12" X-series are as good as any full-size kb save the Ergo 4000. Trackpad with 3 buttons is amazingly useful. Then again, ThinkPads are in another realm, and aren't cheap for good configurations. So Lenovo certainly _could_ pull it off if they don't screw it up.

</comment></comment></comment></comment><comment><USER6> "By 2005 or so, it will become clear that the Internet's impact on the economy has been no greater than the fax machine's." \- Paul Krugman, 1998

[http://web.archive.org/web/19980610100009/www.redherring.com...](http://web.archive.org/web/19980610100009/www.redherring.com/mag/issue55/economics.html)

<comment><USER7> Thus proving the title "Why most economists' predictions are wrong".

<comment><USER8> Of course, that's just a corollary to "the future is hard to predict." Honestly, what group of people gets it 'right' with any kind respectable frequency?

</comment></comment></comment><comment><USER9> He's a little out of his element in this space, and a lot of his article feels like off-the-cuff ramble without much support.

But he does raise one really strong point: namely, that Microsoft's lead was largely secured on the back of enterprise sales -- a tougher moat to build, but a very protective and lucrative one once built. Apple's lead was secured on the consumer side, and consumers tend to be two things in the long run: price-conscious and fickle. Consumers picked cheaper and more ubiquitous Wintel machines over the more beautiful and expensive Apple machines in the 90s. Now they're picking cheaper and more ubiquitous Android devices in sufficient numbers to threaten Apple pretty seriously.

It's way too early to write Apple's epitaph in the mobile war, but things aren't as rosy as they once were.

</comment><comment><USER10> This is ludicrously, hilariously, almost unbelievably ironic, coming from Krugman:

>> _" In general, the thing about Apple is that it reflects the spirit of Steve Jobs, who knew what was good for you — and left you no way to do things differently. And if you are an atypical user, you end up putting a lot of effort into fighting iOS in order to do simple things."_<<

It should baffle me that this problem is so obvious to Krugman and others in the field of electronics, but simply beyond mention when it comes to governance. It doesn't baffle me because it's clear that Krugman and others stopped being scholarly thinkers as soon as they gained a national audience to preach to.

</comment><comment><USER11> The headline here is, well, bizarre. The headline on Krugman's article is "On The Symmetry Between Microsoft And Apple", and the conclusion is that Apple's dominance now on mobile is less secure than Microsoft's on the desktop at the peak of Microsoft's desktop dominance.

Which is, for one thing, quite a bit different than the characterization in the current HN headline (he doesn't say anything like "Apple Is Doomed") and, for another, quite obvious (I mean, just compare Apple's current marketshare in any relevant market to Microsoft's at the peak of its desktop dominance, or compare the trends.) Apple is well past its peak dominance in, say, mobile -- and at its peak it was less dominant there than Microsoft was on the desktop at its (much longer) peak. Heck, less so than Microsoft is on the desktop _now_.

In fact, Apple's trajectory in mobile is a _lot_ like Apple's trajectory in the "personal computing" space in the 1980s -- lead initially, establish a firm loyal base willing to pay premium prices, and then starting losing the rest of the market (which has lower margins) to other players. Really, except to exploit attention directed at Microsoft because of the current CEO drama, there's not a lot of reason to look to Microsoft's history for a comparison, when Apple provides a better one in its own history.

<comment><USER12> The headline is genius. It's meant to appeal to the frenzied foamy intersection of pro-Apple and anti-Krugman maniacs.

</comment></comment><comment><USER13> Krugman says so many wrong things - about bitcoin for example, but not just about that.

So, who cares ?

Also, he seems to miss how many people complained about Microsoft in the 90s while most people seem very happy with their Apple products.

<comment><USER14> Right, it's a little disappointing that the blog of a fairly well-known economist just uses some basic anecdotal evidence. I'd hope he'd provide some kind of deeper insight, but I guess that's what passes for quality on the Times these days.

</comment></comment><comment><USER15> > the wonderful people in the Wilson School IT department, who have saved my > life multiple times, aren't set up to deal with Apple products.

I would argue that not only do you have full access to the Apple Store geniuses but if you happen to not have a Apple Store near you there will be Apple certified repair people you can use. Also I would guess that you would not have to get your mac repaired anywhere near as often as you do your windows machine.

</comment><comment><USER16> "I've had an iPhone — which, sad to say, did not survive dunking in water — and now have a Samsung, and the differences don't seem huge"

everyone new to contemplating the mobile scene always seems to miss out on the longer term advantage of apple phones due to upgradability. it's an absolute hell with andriod. im not saying this will create a swing back in apples direction for marketshare, not at all. I'm just saying that difference is indeed huge to anyone that looks at it.

(disclaimer, I've had iphones and andriod phones and i think they all suck equally. i role on motorola c155 with 3 text line display)

<comment><USER17> OS updates are not something non-techies think about, in my experience. For the vast majority of users, they mostly care that their favorite apps continue to work, and this is something that Android provides good tools for.

<comment><USER18> The problem is when your favorite app stops supporting your Android Frosted Cup Cake on a phone that was abandoned by its maker.

<comment><USER17> That's an issue with the maker of your favorite app, as it is their choice to abandon older versions of the platform.

<comment><USER16> and hence we come full circle to the argument that the fragmented update makeup in andriod adversely effects apps and users than ios. (again, i have neither and dont care... but one clearly has a problem)

</comment></comment></comment></comment></comment><comment><USER19> This article is pathetic on so many levels. He starts off saying he basically has no clue about technology or the industry, and then concludes with Apple is doomed because it's hard to organize his youtube downloads in iTunes. Really?

There is no reason this should be on the front page, and the only reason it is there is because the headline has been editorialized.

Edit: also, this from the guy who said the internet's impact on the economy would be no bigger than the fax machine - [https://news.ycombinator.com/item?id=6342272](https://news.ycombinator.com/item?id=6342272)

</comment><comment><USER20> Apple may or may not be doomed, but one thing I've learned over time is not to trust economists straying too far from their turf. Krugman blaming a dead CEO on his inability to use an iPhone does not equate to calling up the corporate coffin maker.

When I saw the title, I was hoping for a more economic reason about trade, network effects or competitive advantage.

</comment><comment><USER21> I have to back him up on iTunes. I hate it. I've always hated it. I'm not sure it dooms Apple, but I've seen lots of products die as a result of infuriating design choices. It takes a while, but it does happen.

</comment><comment><USER22> This article, along with most of the stuff Krugman wrote about bitcoin, is utter bs. Apple is doomed cause iOS doesn't let Krugman organize his Youtube downloads.

<comment><USER23> Completely agree. The parallel he is drawing between MS in the 80's and Apple now is some kind of uninformed fantasy. He even says "I am not a tech industry maven, so I am busy coming up to speed"... Then he side-steps and says his real complaint is:

>So, my problem with Apple. In general, the thing about Apple is that it reflects the spirit of Steve Jobs, who knew what was good for you — and left you no way to do things differently.

His example is that iTunes doesn't do what he wants it to do.

Well it doesn't always do what I want it to do either, but as a product it is an enormous success and it earns _Billions_ of dollars. So that's nonsense.

The best part of this article is that Paul Krugman listens to Arcade Fire!

</comment></comment><comment><USER8> Weird post - he's definitely a smart guy, but clearly not an expert in this area. In fact, he sounds a lot like my dad.

Why do we care what he thinks here?

I am a big android fan, but I definitely see differences in quality between Apple products and others. I don't care as much about the polish, though - <USER2> like the freedom that android can afford.

But comparing Apple now to Microsoft in their hay day is not original, compelling or even that accurate. I mean, they're still selling computers, true, but the whole space seems pretty different than how it was when Microsoft was dominating... isn't that why Microsoft's in trouble in the first place?

I guess his point is more general - that Microsoft gained market dominance not through making a superior product, but simply by gaining traction and having the largest consumer base - that may be true, but Microsoft allowed a lot of freedom and control over your devices while Apple does not. Furthermore, Android has dominated the market in terms of numbers for a while now and yet Apple is still in the game - presumably due to the quality of their products, not the fact that lots of people use them.

Anyways, I'm probably rambling. My point is simply that Krugman should probably sick to his area of expertise.

</comment><comment><USER24> Eh. He is right about Apple forcing you to work their way, and only their way. Try to select all on iPhone email, or try to access the file system. For the computer literate, the lack of these options on a stock iPhone is beyond annoying. they are just a sample of frustration encountered when using Apple products, no mater how good their quality is.

</comment><comment><USER25> Krugman orders a pizza. Guy asks if he wants it cut into 6 or 8 slices. Krugman says, '8 please. I'm very hungry today.

-GSelevator

</comment><comment><USER26> > "My casual impression is that Apple's lock isn't nearly as secure, in part > because it's relying on the loyalty of individual customers — in contrast to > Microsoft, which was largely relying on the loyalty of corporate IT > managers, who are inherently more conservative."

The important thing is right in this quote. Apple cares about making product we want to buy, not product we are forced to use.

To stay relevant, Apple needs to keep going. And because they rose so high, they pushed other players to offer amazing product to compete. That's almost like capitalism at its best.

Of course they could fail, and they will not be saved by IT Managers inertia. Well too bad, I will have fond memories like I have fond memories of my C64 and Amiga500.

I certainly prefer that to the bland pc market.

</comment><comment><USER27> Krugman's a smart guy about a lot of things, but he didn't get computers and the internet, didn't believe that measured productivity gains from using them were real (to his credit, he did publish a mea culpa or two years later) and I think he's just as ignorant about what differentiates Apple's products from Microsoft's. It's interesting that he doesn't understand the difference between their value propositions (Microsoft is competing, in a sense, with Google -- which sucks because Google gives away its products -- while Apple is competing with Amazon and Samsung).

<comment><USER11> > It's interesting that he doesn't understand the difference between their > value propositions (Microsoft is competing, in a sense, with Google -- which > sucks because Google gives away its products -- while Apple is competing > with Amazon and Samsung).

In what space is Apple competing with Amazon or Samsung where it is not also competing with Google?

</comment></comment><comment><USER28> He doesn't get that iTunes is not a media player, but a music and video shop sneakily embedded in your computer. Media player functionality is only added there to lure you in so you would buy content from Apple.

Obviously, Apple doesn't care for your youtube videos. But I wouldn't expect a Keynesist to understand the nuances of how modern products are structured and real product often concealed behind a freebie.

If you want a media player, just download one. My favourite is AVPlayer for iPhone (and AVPlayer HD for iPad). Plays all formats I tried.

<comment><USER29> Shame they don't offer an easy way to get files into the iPhone.

But that would get in the way of lock in.

</comment></comment><comment> jack-r-abbit Huh.. if he says that then it isn't in this article. The word "doomed" does not appear anywhere in the article... not even the title.

</comment><comment><USER30> Not sure if I agree. Apple consistently provides better experience because they control both hardware and software. Google is now realizing that or else they wouldn't have built nexus.

</comment><comment><USER18> I feel like its just one of those days where you have to turn something in but procrastinated and said "Fuck it, I'll just compare Apple and Microsoft". Slow day...

</comment><comment><USER31> Just hit a paywall, so it would be nice to read at least a summary of the article.

</comment><comment><USER32> The Mantle of John C. Dvorak has been passed to Paul Krugman.

</comment><comment><USER33> it's an important lesson: someone i respected wrote something he has little knowledge about destroyed the respect.

</comment><comment><USER34> Isn't he the same Economist who went bankrupt himself ?

<comment><USER35> No, that was satire that breitbart and the boston globe fell for: [http://www.mediaite.com/online/paul-krugman-bankrupt- boston-...](http://www.mediaite.com/online/paul-krugman-bankrupt-boston-globe- breitbart-com-fall-for-satirical-daily-currant-story/)</comment></comment>


Intel CPUs afflicted with simple data-spewing spec-exec vulnerability - <AUTHOR> https://www.theregister.co.uk/2019/03/05/spoiler_intel_flaw/ <comment><USER2> _will make existing Rowhammer and cache attacks easier_

I've said it before and I'll say it again: Rowhammer is a functional correctness problem that the memory industry has been trying to hide ever since it was discovered. Authors of memory testing tools have been convinced to ignore it, with the rationalisation that "almost all memory would test as defective." AFAIK it's only after ~2009 that RH became a problem; anything older is not affected due to its lower density.

On the bright side, since the first Spectre timing in JS has been so reduced in resolution that the last time I read about it, the rate at which you can read memory (keep in mind that where you read is random, and how large the whole address space is) was extremely low --- something like a few bytes per hour; and that was after the researchers had already done a ton of preparatory work to set up everything just right. (Otherwise, because like with anything timing/cache-based, simply running something else may already change the timing and possibly invalidate some of those bytes being "read". Then comes the question of where in memory you're actually reading --- a 64-bit address space is _huge_ \--- and what significance those bytes have. It could be a private key, it could be random bits; the point I'm trying to make is, being able to read memory is just one of the requirements to an actual attack, and there are many more hurdles an attacker has to overcome.)

IMHO it's something to worry about if you have JS on by default _and_ are being subject to a _very_ targeted attack. If you have JS off by default and aren't someone of particularly high interest, there is much less to worry about.

<comment><USER3> > _I 've said it before and I'll say it again: Rowhammer is a functional > correctness problem that the memory industry has been trying to hide ever > since it was discovered._

How do you measure correctness? By reliability?

What trade-off would you make to improve density, throughput, or latency?

Why do you think that trade-off wasn't made?

<comment><USER2> If memory is operating correctly, then the value last written to any location should _always_ be the one which is read back. Any deviation from that means there is something _wrong_ , in the same way that a calculator which intermittently produces 1+1=3 would be considered _broken_.

The fact that the correctness of software since the beginning of computing depends on the correctness of the hardware means that it's not a "trade-off", memory that doesn't behave like memory should is simply defective. The $$$-chasing manufacturers would like you to think otherwise, however, and IMHO there's been a huge cover-up --- which the manufacturers certainly are trying hard at; just imagine recalling every single DRAM produced in the last 10 years.

Security is only one important piece of the whole story. Imagine computations being subtly incorrect (that includes things like "IsUserRoot()" being occasionally wrong, but it affects correctness in general.) That undermines everything about what computers are supposed to do. I only wish there was far more outrage about Rowhammer than Spectre/Meltdown (I remember some people suggesting recalling all CPUs made in the last 2 decades...), because while timing side-channels are "only" a security concern that simply did not receive much attention until recently, Rowhammer and similar corruptions affect _all_ computation. You don't have to be attacked, all that needs to occur is some computation happens to have a "fragile" access pattern that flips bits somewhere, and weird undefined behaviour appears. I mentioned this in a comment I made 4 years ago about the same thing: [https://news.ycombinator.com/item?id=9175734](https://news.ycombinator.com/item?id=9175734)

<comment><USER4> We all know cosmic rays and other stuff can flip bits. So your reads are only correct 99.99..9% of the time. Deciding how many nines you want is a trade off. Welcome to the real world.

<comment><USER2> Confusing a random natural event which is literally orders of magnitude lower with specific access patterns that can rapidly cause errors is pure disinformation.

</comment></comment></comment></comment></comment><comment><USER5> I've been using AMD CPUs exclusively on the desktop for the last 3-4 builds I've done and it sure feels nice all of a sudden. I recognize it's luck rather than skill of course, but I'll take what I can get because this one is a doozie!

"An attacker therefore requires some kind of foothold in your machine in order to pull this off."

Right, but these days browsers are handing over footholds to anyone with a webserver! It used to be that you worried about pop-ups because they were annoying. Now it seems you need to worry about the modern-day equivalent because they could at least theoretically ruin your digital and perhaps real life.

<comment><USER6> _> these days browsers are handing over footholds to anyone with a webserver_

It is bad for providers using non-dedicated cloud infrastructure too: some of these flaws allow breaking out of the hypervisor's protections so an attacker can in theory read from other VMs on the same infrastructure not just other processes on your (virtual)server.

 _> I've been using AMD CPUs exclusively on the desktop_

That doesn't protect you all that much. While this particular flaw seems from current reports to be Intel specific, some of the past ones affected AMD and Arm designs also, and maybe there are some AMD/Arm/other specific attacks waiting to be found too.

<comment><USER7> > That doesn't protect you all that much. While this particular flaw seems > from current reports to be Intel specific, some of the past ones affected > AMD and Arm designs also, and maybe there are some AMD/Arm/other specific > attacks waiting to be found too.

I think this is called "security through minority" which is a special case of "security through obscurity" :)

<comment><USER8> Dont forget about meltdown.

<comment><USER9> Only AMD has avoided Meltdown, both ARM in some CPUs, and IBM, both POWER and mainframe, have Meltdown bugs.

</comment></comment></comment></comment></comment><comment><USER10> Spectre attacks have so far only been observed at the nation-state level in the wild. If you're truly paranoid about being in the first wave of victims, disable Javascript and other active content on non-white listed pages. At some point processors are going to have to drop into a non-speculative security mode when dealing with vulnerable data like passwords and handshakes, and pop back out of it when they're done.

<comment><USER8> That's not enough. You have to disable speculative execution on untrusted code, not on sensitive data. There is no solution on shared infrastructure because the untrusted code is another VMs trusted code.

<comment><USER11> He was talking about desktop computing. For server side, of course you need dedicated machines in your own locations. You basically have no security against targeted attacks in shared hosting because you don't even have access to cameras or the ability to vet the personal with access to your hardware.

</comment></comment></comment><comment><USER12> > This security shortcoming can be potentially exploited by malicious > JavaScript within a web browser tab,

Well, that's lovely. Turning off JS just got more important.

<comment><USER13> I have basically zero sympathy for people who enable JS in their browsers and then complain about their privacy being violated. I mean, how can someone expect privacy when doing the exact opposite of best practices?

<comment><USER14> Some people need most of the internet to work correctly. Like it or not, JS has become a core requirement for modern web functionality and that is unlikely to change any time soon.

<comment><USER2> I have been browsing with JS off by default for over a decade and a half now. The list of domains for which I allow JS on has accumulated less than 100 entries. I do not use "appsites" much, and the rest of the document-centric Web is perfectly usable without any scripting.

The more who turn it off and complain about useless appification, the more likely the trend can change. There are already plenty of reasons besides security to turn it off.

<comment><USER15> The only device on which it is truly impractical to disable JS is my company- owned iPhone. It does not allow me to install apps from the App Store, so while I can flip the switch to disable it in Settings>Safari>Advanced>JavaScript, doing so is inconvenient since I cannot whitelist the few domains that I'm okay running JS on.

That's a pretty special case, however. On any other device, uMatrix + NoScript works great.

</comment></comment></comment></comment></comment><comment><USER16> The title and opening paragraph are misleading; this only leaks physical page mapping information, not data. So this can allow ASLR to be bypassed, but isn't a vulnerability in the same class as Spectre.

</comment><comment><USER17> How big of a fuckup do we need to see to realize that running megabytes of arbitrary code from a dozen different domain for every website we visit is a bad idea?

What needs happen for engineers to realize that process isolation is something that needs to be taken serious at the lowest possible level (hardware + OS), rather than through some magic abstraction layer (VMs, hypervisors, containers, etc).

</comment><comment><USER18> So, with surf, it's easy to browse without JS (set the default to False in config.h). It's way better than the default 'on'. If something does not work, I either hit ctrl-shift-s to enable JS for that WebKit process, or (more often) just axe the window.

[http://surf.suckless.org/](http://surf.suckless.org/)

<comment><USER17> Browsing without JS is a major pain if you're enabling it for only certain domains. If you don't do that, you don't add much security anyway.

<comment><USER18> It's per-process. Under most circumstances, each surf window/tab is it's own WebKit process. So for example, I might decide to enable it for a banking session (although it's a perfect example of somewhere JS should not be necessary).

</comment></comment></comment><comment><USER19> I'm beginning to think crypto operations should no longer be implemented in code on general purpose cpus.

<comment><USER20> I'm not an expert in this but considering the purpose of these exploits is to gain knowledge of memory layout to then execute exploits against DRAM, simply securing your CPU isn't going to be enough.

<comment><USER19> Exactly. So dont keep the extremely valuable stuff in RAM and reduce the attack surface.

</comment></comment></comment><comment><USER21> "..it's not something you can patch easily with a microcode without losing tremendous performance"..

Spectre also caused performance drops, could Intel have made these flaws intentionally - just to boost performance?

<comment><USER22> Speculative execution in general is a sizable performance boost that brings in the risk of all sorts of attacks like this. You could of course try to implement it all in a safe way - and of course not every form of speculative execution in existing processors is unsafe - but in practice lots of vendors messed it up and Intel seems to have just produced the least-safe speculative execution implementation. I'd argue that speculative execution's risks were not particularly scary when it became a common technique (a very long time ago!) because things like shared hosting on anonymous machines with hypervisors or multiprocess browser sandboxes storing important data were nearly impossible to predict.

AFAIK Intel, ARM and AMD all have shipped chips that are vulnerable to a handful of speculative execution attacks. Microcode can work around these issues by doing things like changing the micro-ops that instructions decode to or disabling processor subsystems - though what they can or can't disable is something I suspect only the vendor knows, it's common for vendors to include many of what are referred to as 'chicken bits' that are essentially panic switches to disable a feature or subsystem if it turns out to be broken.

<comment><USER9> > AFAIK Intel, ARM and AMD all have shipped chips that are vulnerable to a > handful of speculative execution attacks.

Some ARM CPUs, and IBM, both POWER and mainframe CPUs, have Meltdown bugs. All 4 of these vendors of high performance out-of-order speculative execution CPUs including AMD have Spectre bugs.</comment></comment></comment>


Ask HN: Is it worth paying $200 to get 16gb RAM on mid-range Mac mini? - <AUTHOR>

<comment><USER2> If you are buying a 2014 model, given that it seems to be non-upgradeable, I suppose the answer is "yes if you want that much memory." Whether you want that much memory depends strongly on your application needs.

If you already have a 2012 mini or earlier, I would look at crucial.com. It looks like the 2012 models are pretty easy to upgrade. Older models, I know from personal experience, are quite fiddly and difficult to take apart, so I wouldn't recommend it unless you have experience taking apart laptops and tools available such as spudgers and spatulas and extra kapton tape.

</comment><comment><USER3> FWIW, i used a mid-2011 2.3Ghz i5 with 8 GB of RAM for about 4 years as a lightly used dev machine (read: basically ruby/rails, pg, and sublime text with some crud stripped out and running on OS X [not server]) that also hosted about 25-30 (low bandwidth) rails apps for internal use that did a lot of text processing and never really had too many complaints. flash forward 2 years of sitting idling without any activity and it's a bit sluggish now (granted that's because i've done literally nothing on the machine other than let it run)

</comment><comment><USER4> What is it being used for?

<comment><AUTHOR> Mostly for development purposes, running an IDE (Eclipse or IntelliJ), Android emulator and a local Apache server. Besides development, I might have light usage of Photoshop but no video editing or gaming.</comment></comment>


Show HN: YCPages.info (Info about YC funded companies) - <AUTHOR>

Please give me some feedback on my weekend/evening project http://ycpages.info
YCPages is a CrunchBase sort of service just for YC funded companies. Company/founder details are pulled from CrunchBase using their API.
I have checked founders info by looking their LinkedIn pages/Twitter etc. So i am confident 95% information available on YCPages are accurate.
Next Steps,
== Adding the Tech Stack info == Rankings from Alexa, Compete, Quantcast, etc
If I can get the founders answer few of my question about their experience I will add them as well.
Any feedback would be highly appreciated.
http://ycpages.info
P.S. YCPages is not affiliated with or endorsed by the YCombinator. Everything on YCPages are generated from freely available content on the Internet. If any of the founders doesn't want their info on YCPages please send an email to ycpages at gmail dot com and I will delete them. <comment><USER2> Absolutely beautiful. Slick, and informative. I was not expecting the good visualization of data directly on the home page, not to mention the other tabs.

I previously used the Google Spreadsheet posted a while ago, but this has just replaced it. Very, very nice.

EDIT: Funding is still missing for all companies, but you should be able to get that info from CrunchBase, etc. "Greater than" information is sufficient. Also, I noticed that there is a duplicate BackType entry, but with 0 founders.

<comment><AUTHOR> Thanks Daniel.

I have deleted the BackType duplicate entry. Adding the funding details is the next step.

</comment></comment><comment><USER3> Most surprising statistic on the site: _only 2.7% of the YC funded companies have women as founders._

Compare that with the ~37% of entrepreneurs in the US that are women. [1]

I don't mean to be presumptuous or to imply anything, but this definitely jumped out at me. Any explanations?

[1] - [http://www.businessinsider.com/women-in- business-2010-11#16-...](http://www.businessinsider.com/women-in- business-2010-11#16-united-states-5)

<comment><USER4> Anyone who starts a business is an entrepreneur, but only a small percentage of businesses are startups.

Also, the actual number is more than 2x that.

</comment></comment><comment><USER5> The obvious YCW 2011 is really underrepresented. Google can help you with that: [http://www.google.com/search?hl=en&biw=1280&bih=788&...](http://www.google.com/search?hl=en&biw=1280&bih=788&q=site%3Ahttp%3A%2F%2Fnews.ycombinator.com%2F+%22yc+w11%22&aq=f&aqi=&aql=&oq=)

<comment><AUTHOR> Number of companies in YC W11 batch is 12 now. I will add them as soon as I get the details.

</comment></comment><comment><USER6> Thanks for putting the info together! I scraped your pages and created a Twitter list of all the YC founders: <http://twitter.com/#!/boctor/ycombinator>

I already have a couple of Twitter name updates: @kovasboguta doesn't exist @dariusmonsef is now @bubs

<comment><AUTHOR> Thanks boctor. I have updated the accounts now. @kovasboguta is @kovasb now.

</comment></comment><comment><USER7> Some of the companies with "unknown" status are definitely no longer running. From the first batch:

\- Half of MemAmp was merged into reddit and half went back to gradschool.

\- Simmery shut down after the summer

\- Firecrawl shut down after the summer (though went immediately into another startup after)

<comment><AUTHOR> Thanks Emmett. I have updated the status of those three companies now.

</comment></comment><comment><USER8> Great work!

Even a quick look at the site is enough to tell that you've put in a good bit of effort on this. Excellent content, presentation, design/UI.

Thanks for developing, publishing and sharing this.

</comment><comment><USER9> The site is great, like the way the companies are broken down by batch, love the profile pages. Would be great to be able to filter companies by status, like acquired, active, etc (unless I missed that?)

<comment><AUTHOR> Thanks. Its in the works. Will be available soon.

</comment></comment><comment><USER10> 'Companies by Batch' ... Label Y axis or title 'Number of Companies by Batch' Still poking around it. Looks nice.

<comment><USER10> Wow. Super slick. Nice work.

</comment></comment><comment><USER8> Clickable:

<http://ycpages.info>

</comment><comment><USER11> I'm curious -- why .info? YCPages.com is available, unregistered.

<comment><AUTHOR> .info was a lot cheaper to register at that time. Now I have registered ycpages.com and point to ycpages.info. Thanks for the reminder.

<comment><USER11> No worries -- if you'd had contact information in your profile, I'd have emailed you. I hesitantly posted it here, but then immediately worried that somebody else might register it.

Glad it worked out!</comment></comment></comment>


You are Not a Software Engineer - <AUTHOR> http://www.chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer

<comment><USER2> The article likens the building of a skyscraper to the _design_ of software. I think that the analogy here may be wrong (having made the same incorrect analogy myself).

Perhaps the correct analogy is that the building of a skyscraper is akin to copying software (i.e., building a new replica of a design). In this regard software is the ultimate engineering. Once you have the blueprint (the final source code), stamping out copies is perfectly reproducible. The program applies to many more environments than a skyscraper design.

On the other hand, designing a skyscraper is alot like writing software. The designer doesn't know what the building will look like. There is an iterative process where ideas are thrown around, design errors identified and fixed, etc.

In terms of quality measurements, the same measurements don't apply to software since each copy is a perfect replica. There is little need to measure how closely a copy reproduces the design, it is often perfect. The design may have flaws, but so may a building design.

Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"

<comment><USER3>
        Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"

That's a good question. Off-hand, I would say that part of the reason has to do with experience. Humans have been constructing bridges and buildings for thousands of years. As such, engineering of this sort is generally well understood. Occasionally, when working with new materials or grander scales, past experience fails, e.g. Tacoma Narrows Bridge.

There is another important way that designing software differs from designing structures. Whether a building stands or collapses is governed by the laws of physics. On the other hand, software design takes place in an entirely abstract world, where the laws that govern it are sometimes subject to change. That combined with the sheer scale of much software makes it difficulty to thoroughly reason about it.

</comment></comment><comment><USER4> I'm done with these analogies. I find it a lot easier to make good decisions by asking direct questions about the situation I'm in and the outcomes I want.

edit: snark removal

</comment><comment><USER5> See also [http://www.codinghorror.com/blog/2008/11/tending-your- softwa...](http://www.codinghorror.com/blog/2008/11/tending-your-software- garden.html)

The last line is a little presumptive for my taste. How do you know I didn't write the firmware for your pacemaker? There's gardened software and there's engineered software and both have their place.

</comment><comment><USER6> Software is a lot more unreliable than bridges and buildings because it can be. People pay a lot of money to have reliable physical constructions. Some also pay for reliable virtual constructions (think 30-year-old space probes). There's no sensible business need for Facebook, say, to have three 9's reliability.

</comment><comment><USER7> <http://en.wikipedia.org/wiki/Reframing> It's not that clever.

</comment><comment><USER8> The problem with calling ourselves "software gardeners" is that gardeners do not earn as much money as engineers.</comment>


A Tour of Soviet Supercomputing (1996) - <AUTHOR> http://www.inc.com/magazine/19960615/1967.html

<comment><USER2> No pictures? :-(

<comment><USER3> <http://www.mailcom.com/besm6/>

</comment></comment><comment><USER4> I don't get the comment feeling sorry for the technicians at this machine's shortcomings. It's good that Intel etc didn't help this power hungry superpower to take over the world as they wanted to.

<comment><AUTHOR> So, the _other_ power-hungry superpower took over the world.

Ask the Afghanis, Iraqis, etc. how they like it. And eventually ask yourself - after the consumerism bubble pops / the petrocollapse takes place.</comment></comment>


Ask HN: Any good newsletter related to photography? - <AUTHOR>

Anyone can help me discover some good newsletter related to photography? or online magazines with good quality content? <comment><USER2> This is a good one (often about the business of photography): [http://www.aphotoeditor.com/](http://www.aphotoeditor.com/)

</comment><comment><USER3> I subscribe to 2 entirely FREE photography magazines on my iPad:

Light & Landscape Magazine

Extraordinary Vision

</comment><comment><USER4> I subscribe to Unsplash: unsplash.com</comment>


Sex in space - <AUTHOR> http://en.wikipedia.org/wiki/Sex_in_space

<comment><USER2> More important than what it appears to be on the surface.</comment>


Show HN: spur.py: A simplified interface for SSH and subprocess in Python - <AUTHOR> http://mike.zwobble.org/2013/02/spur-py-a-simplified-interface-for-ssh-and-subprocess-in-python/

<comment><USER2> Nice job! Is this on PyPi?</comment>


"C is how the computer works" is a dangerous mindset for C programmers - <AUTHOR> https://words.steveklabnik.com/c-is-how-the-computer-works-is-a-dangerous-mindset-for-c-programmers <comment><USER2> My favorite take on the severity of the UB problem, [https://blog.regehr.org/archives/1520](https://blog.regehr.org/archives/1520) :

> Tools like [Valgrind] are exceptionally useful and they have helped us > progress from a world where almost every nontrivial C and C++ program > executed a continuous stream of UB to a world where quite a few important > programs seem to be largely UB-free in their most common configurations and > use cases...Be knowledgeable about what's actually in the C and C++ > standards since these are what compiler writers are going by. Avoid > repeating tired maxims like "C is a portable assembly language" and "trust > the programmer." Unfortunately, C and C++ are mostly taught the old way, as > if programming in them isn't like walking in a minefield.

<comment><USER3> > Be knowledgeable about what's actually in the C and C++ standards

... turns out to be an extremely tall order; the 2017-11-17 working draft of the C++ standard is 1,448 pages in PDF format.

At some point, I wonder when programmers who are required to care about correctness throw up their hands and say "This language isn't reasonably human-sized for a user to know they're using it correctly." At which point the immediate next question should be "Why don't you use something else?"

(In my experience, the only sane counter-answer to that last question is "I'm programming on an architecture where the {C/C++} compiler is the only one with any real expressive power that anyone has ported to this physical system." This is an answer I understand; most other answers will raise an eyebrow from me).

<comment><USER4> > most other answers will raise an eyebrow from me

Portability. A C library can be trivially linked with any other language. But one will be hard pressed using a python library form Ruby, for example.

<comment><USER5> This is literally the reason I most recently wrote some C, but - do you really need _linking_? You can pretty easily use a Python library from Ruby by writing a little loop in Python that accepts JSON input and produces JSON output, and calling that as a Ruby subprocess.

It's fairly rare that you actually need to be in the same process. (The thing I wrote was a wrapper for unshare(), so it did strictly need to be in-process, but that's an unusual use case.) Even if you want to share large amounts of data between your process and the library, you can often use things like memory-mapped files.

And there are some benefits from splitting up the languages, including the ability to let each language's runtime handle parallelism (finding out that the C library you want to use isn't actually thread-safe is no fun!), letting each language do exception-handling on its own, increased testability, etc.

<comment> evil-olive > You can pretty easily use a Python library from Ruby by writing a little > loop in Python that accepts JSON input and produces JSON output, and calling > that as a Ruby subprocess.

If you're a Ruby application, sure, you can use a Python library by forking off a subprocess.

Just make sure to document the installation requirements - in addition to having Ruby and the correct gems installed, you also need Python (which version?) and the correct pip libraries installed.

If you're a Ruby _library_ , instead of an application, forking off a Python process is a nonstarter, unless you want to propagate those requirements out to every single application using your library.

<comment><USER5> Sure, but there's an equivalent problem in the C world - go back in time a couple years before we figured out how to do precompiled binary-compatible C extensions in Python and try running 'pip install numpy'.

I'm mostly thinking that if you already have a Python library you really like, chances are you already have a Python environment capable of running it. (The environment doesn't have to be related to your Ruby environment at all! If you want to get Ruby through your OS and Python through a Docker container, or whatever, that should work fine.)

</comment></comment></comment></comment></comment></comment><comment><USER6> One of the blog posts I keep meaning to write is in the vein of "Why C is not portable assembly." Ironically, most of my points about C failures aren't related to UB at all, but rather the fact that C's internal model doesn't comport well to important details about machines:

* There's no distinction between registers and memory in C. A function parameter that is "register volatile _Atomic int" is completely legal and also makes absolutely no sense if you want C to be a "thin" abstraction over assembly.

* There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot).

* No support for multiple return values (in registers). There's structs, but that means returning via memory because, well, see point 1.

* Missing machine state in the form of vector support (which is where the lack of the bitcast becomes particularly annoying). The floating-point environment is also commonly poorly supported.

* Missing operations such as popcount, cttz, simultaneous div/rem, or rotates.

* Traps are UB instead of having more predictable semantics.

* No support for various kinds of coroutines. setjmp/longjmp is the limit. You can't write zero-cost exception handling in C code, for example. Even computed-goto (a source-level equivalent of jump to a location held in a register) has no C representation, though it is present in some compiler extensions.

<comment><USER7> "There's no "bitcast" operator that changes the type of a value without affecting the value."

Technically, you are supposed to use unions for that, though it's a pain. The PostgreSQL codebase is compile with -fno-strict-aliasing so that a simple cast will get the job done, but obviously that's technically out of spec.

<comment><USER6> Actually, the guideline I've heard is that memcpy should be used, since memcpy has the magic property of copying the bytes without affecting the destination type. Unions are only legal in C99 and newer (although C99 erroneously includes this in its list of undefined behavior--this was fixed in C11); C89 and any version of C++ don't permit this behavior.

<comment><USER8> I keep hearing this rumor, but C99 did not erroneously include unions-as-type- punning in a list of undefined behavior. The normative language is unclear, but clarifications were added1][2].

1: [http://www.open- std.org/jtc1/sc22/wg14/www/docs/dr_257.htm](http://www.open- std.org/jtc1/sc22/wg14/www/docs/dr_257.htm)

2: [http://www.open- std.org/jtc1/sc22/wg14/www/docs/dr_283.htm](http://www.open- std.org/jtc1/sc22/wg14/www/docs/dr_283.htm)

<comment><USER9> The parent comment seems to be saying that C99 _does_ allow type punning with a union, with an explicit clarification as you say. In C89 it was ambiguous and in C++ it is explicitly disallowed (you are supposed to use memcpy).

<comment><USER9> Sorry, I misread the parent comment. Now it's too late to delete mine, please ignore.

</comment></comment></comment></comment></comment></comment><comment><USER10> To be fair, even assembly language isn't how the computer works (gets translated into micro code). Not to mention other integral components like the GPU that are coded in an entirely different model.

I think what's fair to say is: the "abstract C machine" tends to have a minimal amount of concepts on top of the machines instruction set, compared to other languages, and generally provides the least friction if you need to poke a memory address or layout a structure in a very specific way. It's just easier to say it's closer to the metal because that's a mouthful.

<comment><USER11> Not really, assembly language is extremely close to microcode, much much closer than it is to C. C has a whole bunch of baggage like pointer provenance, inability to read uninitialized memory, doesn't understand cache aliasing, etc that don't fit hardware well.

<comment><USER12> > pointer provenance, inability to read uninitialized memory

what do you mean by these two? not sure about the former. as for the latter, of course you can read uninitialized memory, unless you mean something else?

<comment><USER13> Can you write a well-defined C program that reads uninitialised memory?

<comment><USER14> Reads? I think so; I believe the bad part is when you try to use it.

<comment><USER13> No, it is undefined behaviour. Check the spec.

<comment><USER14> I couldn't find the verbiage for that. The standard seems to have this under undefined behavior:

> The value of an object with automatic storage duration is used while it is > indeterminate.

But reading the value without using it seems fine?

<comment><USER13> The 'object' in this context is the storage location, not the value you read from it. You're 'using' the 'object' when you read from it.

<comment><USER14> Oh, not that kind of read. I meant "read" in the context of "without actually using its value in a way that affects your program execution"–not, in what I believe the C++ term is–an ODR use. As in here: [https://news.ycombinator.com/item?id=22740582](https://news.ycombinator.com/item?id=22740582)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Wait until they learn that machine code is not exactly how the computer works either. The hardware is doing things to your code you might not expect.

<comment><USER16> Agreed, The example the author uses in his previous post on the topic talks about cache-unaware code but it's perfectly possible to write cache-unaware code in machine language as well.

I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."

<comment><USER17> I feel your statement is actually much closer to the danger. C is pretty close to the hardware indeed and that misleads people into thinking that C is actually _exactly_ how the hardware works. It's a very easy trap to fall into and I've seen many colleagues do just that.

<comment><USER18> M............................................C

M..............................................Java

Look. C is much closer to how the machine (M) works.

<comment><USER19> Give that Java is written in C++ which is in turn an extended version of C, I'm not sure that chart is entirely to scale.

<comment><USER20> That is no argument in this discussion, IMHO - what does it change? The discussion is about the language (and in case of Java, the runtime) and it's machine abstraction, which is nearly the same for Java and C, even if JVM was written in Lisp.

</comment></comment></comment></comment></comment></comment><comment><USER21> I think the biggest point where C is more "how the computer works" vs. a lot of languages is when you write an allocator.

I've noticed in, say, an interview context, that people without a lot of C experience have a lot of trouble reasoning about how an allocator might work, or where memory comes from, or even that some constructs in their preferred language result in memory allocation. With C you can't hide these details.

Yes there are abstractions beneath you, both in software (your OS has set up the MMU) and hardware (cache, out of order execution) and also in the C standard itself (assumptions about pointer types, the precise meaning of the stack). This doesn't take away from the point that reasoning about allocations is more of a thing.

</comment><comment><USER22> "Real hardware" is also an abstract machine. Until you get to the level of each individual transistor, it's hardware abstractions all the way down. Caches, reorder buffers, load and store buffers, instruction decoding are all abstract concepts sitting at a much higher level than the individual transistor.

Those abstractions are there mostly for the purpose of speeding up code execution, but also for enabling hardware designers to think about the machine in terms of real-world concepts and not just as an incomprehensible mind- blowing collection of a few billion transistors.

<comment><USER23> And I bet you physicists argue that transistors are just abstractions of semiconductors

<comment><USER24> Which is, in turn, merely an abstraction over the actual quantum physics that governs what's really happening on the silicon. And quantum physics might itself one day may be found to be a higher level abstraction of what's _really_ really going on, as happened with Newtonian physics before it.

It's abstractions all the way down. I don't know why they're so maligned by programmers, they're the only way any work gets done.

<comment><USER25> heh and it's even worse than _that_ , because near the quantum level, we're mainly finding reflections of our own psychology, psyche and societal norms.

This is why saying sth is "not how the machine works" is a fallacy of black and white thinking and not useful unless one is ready to be very specific abt how it resembles the machine and doesn't.

wrt C, the smartest thing to do is use it wisely and avoid dragons, the same way we e.g. use chemistry to make useful products without performing operations in unstable environments. And surround it with an appropriate layer of cultural expectations - keeping humans in the loop. You don't just do what the computer tells you, you use it to help you make judgments, but ultimately take responsibility yourself.

One can see this in Rust's efforts to not only develop a language, but a conscious culture around it. This will be successful until, like a 51% attack, it is outmaneuvered.

Anyway...

</comment></comment></comment></comment><comment><USER26> Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting away, exactly but not only because of Rust itself, we need a C that is more C than what it became in recent years. After all we don't really need to change the language, but just the new specifications and the compilers implementations of UB.

<comment><USER27> > allow new C standards to change the way undefined behaviors are conceived,

Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all.

To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods.

The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems.

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

<comment><USER28> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous.

C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.

<comment><USER27> > This is like saying there's nothing dangerous about guns, because it takes a > human to make them dangerous.

If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve.

And then complain about the consequences.

<comment><USER29> > If you want to go with that analogy, UB is a kin of you intentionally > pointing your gun to your foot, taking your time to aim it precisely on your > foot, and in spite of all the possible warnings and error messages that are > shouted at you…

Yeaaaah not really:

        #include <stdio.h>
        #include <stdlib.h>
        #include <string.h>

        static char a[128];
        static char b[128];

        int main(int argc, char *argv[]) {
          (void)argc;
          strcpy(a + atoi(argv[1]), "owned.");
          printf("%s\n", b);
          return 0;
        }

compiles with no warning using clang (8), even with -Weverything

And that's a super easy case, it's not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn't check its input pointer which only became occasionally null years later.

<comment><USER14> And many (myself included) think that the compiler _should not_ warn about this code, even if it can potentially exhibit undefined behavior, because it would make it impossible to write code at all without warnings. (A good static analyzer or code reviewer should call it out, though.)

<comment><USER29> That's completely fair. I'm not criticising the compiler not complaining about this code, I'm providing a counter-point to rumanator's assertion that:

> UB is a kin of you intentionally pointing your gun to your foot, taking your > time to aim it precisely on your foot, and in spite of all the possible > warnings and error messages that are shouted at you…

Because they could hardly be more wrong, the average UB is completely invisible to static analysers because it's a dynamic condition which the type system is not smart enough to move to static. That's why it's an UB and not, say, a compile error.

</comment></comment></comment></comment></comment></comment></comment><comment><USER30> I've been coding since C was a new language, and surfed multiple computer revolutions in all and sundry phases, and for personal interests have recently returned to the 80's era for a broader attack at the 8-bit platforms of the time.

This has required a fair bit of assembly language for old machines with a much more minimal profit motive - in fact, non-existent - just so that I can keep my machines alive - which is the reason I'm digging into things as a bit of a challenge to myself.

There is so much great code to read, when you can disassemble. And, even when you can't.

I have a veritable fleet of old systems, many of which are still getting new titles released at astonishing levels of proficiency, yearly now .. CPC6128, ZX (Next!), C64, Atmos, BBC, etc., all have new tools being written for them, including C compilers.

One thing I note is that the tools are everything, because all tools get 'degraded' by new hardware releases. Hardware isn't driven by the compiler designer - the compiler designer is nothing until the hardware guy prints something.

Returning to older computers has meant understanding their architecture, and surprisingly enough after 30 years of mainstream programming, going back to this world is rewarding. There is a lot of joy in writing in C for the 6502, or even Z80, in real mode.

But, always disassemble.

And, in each case, its quite easy to disassemble - get an understanding of registers and memory usage and code inefficiencies, and so on.

</comment><comment><USER31> Is the world ready for _lower-level languages_? e.g. cache-aware. (assembly isn't)

In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware).

Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM).

Some java subsets for very limited hardware might be instances.

<comment><USER32> GPU languages have some cache aware constraints, especially if you're working with the graphics pipeline vs compute where you have more constrained inputs and outputs. Shared memory is also often used as a user managed cache.

Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.

<comment><USER33> > Cell SPUs had explicit user managed cache and host DMA

just a nitpick, but explicitly user managed caches aren't. They are really better known as scratchpads. A cache is supposed to be mostly transparent except for the performance implications.

</comment></comment></comment><comment><USER34> People simply have to come to terms that modern computers are nothing like their beloved PDP-11.

</comment><comment><USER35> There was an ACM article with a similar sentiment recently: "C Is Not a Low- level Language - Your computer is not a fast PDP-11."

[https://queue.acm.org/detail.cfm?id=3212479](https://queue.acm.org/detail.cfm?id=3212479)

HN discussion:

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

</comment><comment><USER23> I don't think anyone suggests using C as an alternative for microarchitecture classes. C still remains one of the best ways to access hardware _relative_ to other software languages. No language is "how computers work" unless you're writing Verilog, but C is the closest to the metal relative to other software paradigms while still being more convenient than assembly.

</comment><comment><USER36> A good way to think of it is that C is how computers worked 40 years ago.

A lot has changed since then, but computers put up a lot of effort to pretend that they still work similarly, and most other programming languages have put up a lot of effort to figure out how to make things work for a "C computer".

<comment><USER37> 40 years ago was the home computer revolution. A _lot_ of computers did _not_ work like that. They had things like segmentation, zero pages, workspace register files, shadow registers, BCD arithmetic, and software interrupts. A few years later they had things like heterogeneous multiple processors, PAD, and trap/interrupt gates.

The big iron of the time (and a few years later) had some things that did not work like C, too, such as single-level storage addressing, tagged architectures, and capability-based addressing.

Thinking that the C language is a representative model for computer history, or indeed for computer architecture, is a _bad_ way of thinking of this. During the 1980s and 1990s there was a _lot_ of shoehorning all of that architectural stuff into C compilers, with extra keywords and the like. (e.g. __interrupt, _Far, _Huge, __based, _Decimal, _Packed, digitsof, precisionof, and so forth)

<comment><USER36> Well, the original C was pretty much exactly how a PDP-11 worked. And the PDP-11 was a source of design inspiration for the original Intel x86 and Motorola 68000 chips.

So there were computer chips sold in the 1970s that worked a lot like C thinks. You are right that there were also ones that didn't.

Going forward from close to 1980 you added more and more features to all architectures that diverge.

</comment></comment></comment><comment><USER38> Do C programmers really think this? I hear it a lot, but only from non-C programmers who hold C in awe. I think they may have heard it from a different cohort of C programmers, though.

</comment><comment><USER39> Some time ago, I saw an article that described a very crazy hypothetical architecture that still fits the C standard and uses the undefined behaviors in various insane ways. It was named like "Computer platform from hell" or so. Unfortunately, I was not able to find it again. Does anyone know about something like that?

I think that the hegemony of C for low-level programming is harming us significantly because it puts the other models to obscurity. Try to write in C for something like F21 chip or J–Machine...

<comment><USER40> The Death Station 9000, designed by the Top Men from highly rated government contractors, built to meet and _exceed_ all mandated specification documents.

Undefined behavior or use of anything not strictly included in POSIX.1c may result in the launch of nuclear weapons.

</comment></comment><comment><USER41> A test for this is to code some relatively but not too simple of a program in both C and Rust using idiomatic code (don't knowingly pick some corner case for either language), compile with -O0 -g0 and be able to _understand_ the resulting output with regards to the program written. I'm not championing the use of either Rust or C and in my opinion languages should be for people not for computers.

</comment><comment><USER42> Interesting this is less of blog post and more of an announcement that a blog post will not be written.

<comment><USER43> Yes, I did not expect this to get posted here, for this reason. The first post got a ton of attention, the second one not so much.

The self-quote for the thesis for this article comes from a conversation with tptacek in the HN thread from the first post.

<comment><USER44> I consider myself a Steve Klabnik fan and even I was surprised to see this at the top of HN haha. Just goes to show you can never really predict how these things will go.

<comment><USER43> Hehe :)

I mean, I guess you could argue that it's produced an interesting discussion. There's actually a pretty interesting question here: is the purpose of a site like this to distribute interesting news, or foster interesting discussion? I personally feel like it's more the former, but maybe the latter matters too.

</comment></comment></comment></comment><comment><USER45> Is someone thinking so? Really? THIS is how computer works: [https://software.intel.com/en-us/articles/intel- sdm](https://software.intel.com/en-us/articles/intel-sdm)

I remember we started our University course of low-level programming from writing in machine codes. No jokes, took binary representation of assembly instructions from that manual and wrote in HEX editor. Then we disassembled simple C applications, understanding unfolding our high-level instructions into x86 assembly. Passing parameters through registres, through stack, two models of stack restoration (yeah, cdecl and stdcall, that moment I realized what does it mean), and other stuff you won't be ever bothered to think about writing in C/C++. And only after that started writing in actual Assembly. THIS is knowledge how computer works. If you know only C, you know nothing.

</comment><comment><USER46> "C is JQuery for the computer."

\-- Micha Niskin

</comment><comment><USER47> Which is why God(bolt) gave us Compiler Explorer.

</comment><comment><USER48> I know this article has been up a few times already on HN. What I think Steve is missing is that all modern computer hardware is designed around _how C works_! 40 years ago you might have had hardware in which there was a real mismatch between how it worked and C worked.

Not so much these days. How C works and how x86-64 assembly works is very similar. Of course, that is not the whole story and you could argue that how x86-64 assembly works is not how the "computer" works because it is a high- level abstraction of the CPU... But then what does it mean to talk about how the computer works?

</comment><comment><USER49> Which language, other than assembly, most accurately represents how modern computers work?

What high language could I use that gives me most performance because it accurately matches the underlying platform?

</comment><comment><USER50> C _is_ a high level language.

C _is_ close to how a computer works.

Assembly is the next step down, and is not nearly as hard as the internet would lead you to believe.

Step down from that; read a book like "Computer Architecture: A Quantitative Approach", and learn about cpu-s and memory (also Agner Fog's site, official amd and intel doc, many other).

Down from that is electronics (logic gates, 8bit adder, etc., down to transistors and capacitors).

And beyond is physics.

Everything else is either computing theory or buzzwordy bullshit.

To repeat: C is a high level language, no matter what anyone says.

</comment><comment><USER51> Assembly is how the computer works. Wait no - Binary is how the computer works. Wait no, NAND gates and ALUs are how the computer works. Every level of abstraction is just that. A layer of abstraction. You can pick any layer, then go down and say "learn that".

</comment><comment><USER52> While the presence of UB is annoying, but necessary, the real issue is that compiler writers use it as a means of performing optimisations instead of warnings. So you end up with a really efficient, but broken, program.

</comment><comment><USER53> Reposting this classic, "C Is Not a Low Level Language"

[https://queue.acm.org/detail.cfm?id=3212479](https://queue.acm.org/detail.cfm?id=3212479)

</comment><comment><USER54> C has never been "how the computer works", its abstract model is way too… well, abstract.

But there is an interesting catch to it: because C is so important, and programmers at large know so little "real C", vendors do their damndest to make it work for them.

A well-known microcontroller forum in Germany is constantly pushing that you need to make your code safe in the case of concurrent access to a variable by a main loop and an interrupt. By making it volatile.

Strictly speaking that's plain wrong. You need some kind of mutex.

Practically speaking, no embedded C compiler vendor would dare use an "optimizing opportunity" and surprise his customers there.

<comment><USER19> "Concurrent access" isn't actually an accurate description of what's going on. Microcontrollers are generally single-core, single-threaded devices. The most common pipeline goes

main thread -> interrupt processing -> resume main thread.

If you're modifying a variable in the interrupt you should declare it volatile so as to avoid the compiler optimizing it and introducing unexpected behavior. Adding a mutex would just be worthless overhead.

<comment><USER54> The C language until very recently didn't know about threads or other kinds of concurrency. So the compiler was technically free to assume that the interrupt is never called. It's nowhere in the call tree that originates at main().

Of course, it didn't do that. Because vendors imparted their compilers with additional knowledge about common programming patterns and uses _that aren 't standard C_.

<comment><USER19> So there are vendors out there that alter the behavior of volatile to act like a mutex in multi-threaded environments but don't tell anyone? Ugh.

Well, TI doesn't do that thankfully. At least not for the MSP430.

<comment><USER33> for a while Microsoft gave volatile acquire/release semantics, which implied a barrier on non-x86 cpus. They recognized it was a mistake backtracked on that around the time they started their effort to run Windows on ARM.

</comment></comment></comment></comment></comment><comment><USER55> Someone told me back in high school that "C is just shorthand for assembly", which I think about a lot. Does anyone else feel that way?

<comment><USER16> > " _Someone told me back in high school that 'C is just shorthand for > assembly'_"

That was true for the PDP-11 that the article series mentions and it was true for the early home computers of the '70s and '80s but it became increasingly less true as processors became more and more complicated under the hood. That's kind of the point of the article series but it's not as big a deal as the author makes it out to be because it was already people writing in C were aware of.

<comment><USER56> As other people have pointed out, rather than C being more unlike assembly, processors are more unlike assembly. As such, the abstractions of C map pretty well to a theoretical assembly, even if optimization changes that precise mapping. A possible exception to this is the multicore semantics that are apart of each architecture aren't particularly well represented.

</comment></comment></comment><comment><USER57> Does it mean that Rust is more situable for the study of low-level programming?

</comment><comment><USER58> It's always dangerous to mistake the abstraction for the underlying Reality.

</comment><comment><USER59> UB = Undefined Behaviour

</comment><comment><USER60> Should I learn Verilog to understand "how the computer works"?

<comment><USER61> In short, no. Verilog is very nearly a general purpose programming language, with some syntactic sugar for doing userspace/green/lightweight threads (that it confusingly calls processes). It is used to model digital hardware, but the language itself doesn't really give you any insight into how to construct those models. Creating the model is still up to you.

</comment></comment><comment><USER62> Equally dangerous as swimming with piranhas. Programming is so exciting if not self indulgent.

Edit: Oh I get it--your manager, who doesn't believe in leaky abstraction or UB, will beat you if the program fails.

</comment><comment><USER63> UB is bullshit so this is all wrong.

</comment><comment><USER64> What is the output of Klabnik? Has he written anything substantial or does he just evangelize?

<comment><USER65> [https://eleroth.files.wordpress.com/2012/01/hadvar.png](https://eleroth.files.wordpress.com/2012/01/hadvar.png)

</comment></comment><comment><USER66> There's the computer, and then there's the computer, and then there's the computer and then there's the computer:

The computer is the thing that has the web browser running on it.

The computer is the thing that has the code editor running on it.

The computer is the thing that has the compiler running on it.

The computer is the thing that provides a virtual hardware interface for running programs.

The computer is the thing that the virtual hardware interface interacts with.

The computer is the thing inside the hard drive/graphics card/other component that the computer talks to.

The computer is the thing inside the processor that pre-processes, jits, or otherwise transforms commands from the computer for the computer so the computer ... ... ...

[https://xkcd.com/722/](https://xkcd.com/722/)

<comment><USER67> There's the c1(physical computer), and then there's the c2(os runtime), and then there's the c3(silicon) and then there's the c4(turing machine):

The c1 is the thing that has the web browser running on it.

The c1 is the thing that has the code editor running on it.

The c1 is the thing that has the compiler running on it.

The c2 is the thing that provides a virtual hardware interface for running programs.

The c3 is the thing that the virtual hardware interface interacts with.

The c3 is the thing inside the hard drive/graphics card/other component that the c2 talks to.

The c4 is the thing inside the processor that pre-processes, jits, or otherwise transforms commands from the c2 for the c3 so the c1 ... ... ...

Is this correct?

<comment><USER66> Sure, but you can also run non-trivial code in the web browser.

I wasn't being super-precise with my comment, and my point is that there is no one thing that "is the computer". There are many computers in your computer, and many definitions of what a computer is.

I've never had to go below the HAL, or inside the JIT, but to some people that's where "the" computer really is. If that's where the computer really is, then I'm not a computer programmer (HINT: I'm not, but I do write code sometimes and get paid for it).

So if I write code, but it doesn't tell the computer what to do, what am I even doing?

Well, I write code that gets consumed by pre-processors and lexers and parsers and compilers and linkers and build agents and I don't know how the soup works, and you probably don't either, you may know more or less of the of the alpha-bits in the soup, but it's still soup. The soup is turned into jello and fed to a virtual machine, which is a fake computer, but it works well enough.

\---

If I were to be more precise, I would say that there's a von Neumann machine C0 that is represented by some hardware abstraction layer C1 by a operating system kernel. There may be a virtual machine C2 running in the C1 context.

But, inside that C0 von Neumann machine there are a bunch of microprocessors that may be called computers that may have Turing complete instruction sets.

\---

Or you could say, anything that can be Turing complete is a computer, in which case your web browser is a computer (among many others).

<comment><USER3> The trick is to expand the definition of "tell the computer what to do."

You can tell the computer what to do by writing a program that passes through six levels of abstraction before the fate of any electrons is affected by what you wrote.

You can also tell the computer what to do by pushing a lot of keys on a keyboard. We're lucky; our keyboards have like a hundred keys on them. Some of our predecessors had eight switches and a ninth key or switch to "ACCEPT" the current switch-bank state.

You can also tell the computer what to do by causing patterns to be stored on magnetic or optical media and read back later.

You can also tell the computer what to do by plugging a wire into the back of it and varying voltages on that wire using another machine a hundred miles away.

Part of the art of programming is knowing that there are no bright, solid lines between these ways to tell a computer what to do (but for a given task, some are clearly more applicable than others ;) ).

</comment></comment></comment></comment><comment><USER52> Rust this, Rust that. Tiresome.

<comment><USER68> What do you mean? The post doesn't contain anything about rust.

</comment></comment><comment><USER69> This may be a little off topic but it is something that until now I've never questioned in my entire career: Is the c in C supposed to stand for "computer"?

If not, what is it?

<comment><USER70> According to Wikipedia, C is named C because it resulted from work done by Dennis Ritchie to improve the language B, and C comes after B. B came from Ken Thompson making a cut down version of the language BCPL, so he just kept the first letter.

[https://en.wikipedia.org/wiki/C_(programming_language)](https://en.wikipedia.org/wiki/C_\(programming_language\))

<comment><USER71> It almost implies that at the time, they realized a plethora of languages would emerge but were hoping everyone would stick with their alphabetic convention. Instead, someone skipped straight to S, someone else stepped back to R, and then everyone said screw it and started making up their own funny names & acronyms.

I've read some intriguing things about D, though (which came along more recently, interestingly enough). Apparently it's in production at several large companies.

<comment><USER37> That creation myth rather falters on the fact that a fair number of languages had already emerged. This was the 1970s, not the 1950s. No-one expected language namers to follow some universal alphabetic convention beginning with BCPL.

</comment></comment></comment></comment><comment><USER72> It's far past time to put C to bed. D, Go, Java, Zig, etc. are all languages that one can use to do approximately C-like things without as much danger. I am tired of seeing a literal Twitter feed of memory unsafety security bugs [0]. We can do better.

[0] [https://twitter.com/LazyFishBarrel](https://twitter.com/LazyFishBarrel)

<comment><USER73> Good luck rewriting all the programs that are written in C without introducing new security problems.

<comment><USER72> Feel free to peruse the Twitter feed that I linked; if most bugs are due to memory corruption, then literally rewriting in place may still be a net negative in terms of total bug count! This is the main argument of Zig [0]; they offer technologies to incrementally rewrite C projects in Zig without losing compatibility. Their compiler can compile C code [1] just like GCC or Clang can.

[0] [https://ziglang.org/](https://ziglang.org/)

[1] [https://andrewkelley.me/post/zig-cc-powerful-drop-in- replace...](https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement- gcc-clang.html)

</comment></comment></comment><comment><USER74> C is like water. Atomically it is the DNA of all other programming languages. There's a reason why C is generally the fastest language with smaller binaries, and there's a reason why language like Python fallback to C for doing anything processor intensive. C will still be here when the latest fad languages of today are long forgotten.

<comment><USER65> Not a word of what you just wrote is true.

<comment><USER74> I think you know better.

<comment><USER65> than to write something like "Atomically [C] is the DNA of all other programming languages"? I do, yes

</comment></comment></comment></comment><comment><USER75> The problem with the "C is an abstract machine" nonsense is that it's just not how it works. I get that it's what the spec says. But C compilers are super careful to compile structured assembly style code without breaking it, even though they don't formally promise to do so. That's because lots of large C code based assume structured assembly semantics and probably always will.

<comment><USER6> > But C compilers are super careful to compile structured assembly style code > without breaking it, even though they don't formally promise to do so.

You have never worked on a C compiler, I take it. All production compilers will at some point turn even straight-line code into a DAG and relinearize it without care to the original structure of code. Any semantics beyond that which is given in the C specification (which are purely dynamic, mind you) are not considered for preservation. In particular, static intuitions about relative positions (or even the number!) of call statements to if statements or other control flow are completely and totally wrong and unreliable.

This is the main reason why people keep harping on the "C is an abstract machine." When people think of machine code, there is an assumption about the set of semantics that are relevant to the machine code, and that set is often much, much broader than the set of semantics actually preserved by the C specification.

<comment><USER75> I work on compilers for a living.

Structured assembly semantics are what C users in a lot of domains expect and production compilers like clang at -O3 will obey the programmer in all of the cases that are necessary to make that code work:

\- Aliasing rules even under strict aliasing give a must-alias escape hatch to allow arbitrary pointer casts.

\- Pointer math is treated as integer math. Llvm internally considers typed pointer math to be equivalent to casting to int and doing math that way.

\- Effects are treated with super high levels of conservatism. A C compiler is way more conservative about the possible outcomes of a function call or a memory store than a JS JIT for example.

\- Lots of other stuff.

It doesn't matter that the compiler turns the program into a DAG or any other representation. Structured assembly semantics are obeyed because of the combination of conservative constraints that the compiler places on itself.

But bottom line: lots of C code expects structured assembly and gets it. WebKit's JavaScript engine, any malloc implementation, and probably most (if not all) kernels are examples. That code isn't wrong. It works in optimizing C compilers. The only thing wrong is the spec.

<comment><USER14> > I work on compilers for a living.

…as I take it, for languages without undefined behavior.

> Structured assembly semantics are what C users in a lot of domains expect > and production compilers like clang at -O3 will obey the programmer in all > of the cases that are necessary to make that code work

No, they will not, and the people working on Clang will tell you that they won't.

> Llvm internally considers typed pointer math to be equivalent to casting to > int and doing math that way.

 _LLVM IR is not C_ , but I am fairly sure that it is still illegal to access memory that is outside of the bounds of an object even in IR.

> A C compiler is way more conservative about the possible outcomes of a > function call or a memory store than a JS JIT for example.

Well, yes, because JavaScript JITs own the entire ABI and have full insight into both sides of the function call.

> That code isn't wrong. It works in optimizing C compilers. The only thing > wrong is the spec.

The code is wrong, and that it works today doesn't mean it won't work tomorrow. If think that all numbers ending in "3" are prime because you've only looked at "3", "13" and "23", would you say that "math is wrong" because it tells you that this isn't true in general?

<comment><USER75> There is a broad pattern of software that uses undefined behavior that gets compiled exactly as the authors of that software want. That kind of code isn't going anywhere.

You're kind of glossing over the fact that for the compiler to perform an optimization that is correct under C semantics but not under structured assembly semantics is rare because under both laws you have to assume that memory accessed have profound effects (stores have super weak may alias rules) and calls clobber everything. Put those things together and it's unusual that a programmer expecting proper structured assembly behavior from their illegally (according to spec) computed pointer would get anything other than correct structured assembly behavior. Like, except for obvious cases, the C compiler has no clue what a pointer points at. That's great news for professional programmers who don't have time for bullshit about abstract machines and just need to write structured assembly. You can do it because either way C has semantics that are not very amenable to analysis of the state of the heap.

Partly it's also because of the optimizations went further, they would break too much code. So it's just not going to happen.

<comment><USER14> You say that this doesn't happen, and yet we have patches like this in JavaScriptCore: [https://trac.webkit.org/changeset/195906/webkit](https://trac.webkit.org/changeset/195906/webkit). Pointers are hard to reason about, but 1. undefined behavior extends to a lot of things that aren't pointers and 2. compilers keep getting better at this. For example, it used to be that you could "hide" code inside a function and the compiler would have no idea what you were doing, but today's compilers inline aggressively and are better at finding this sort of thing. And it isn't just WebKit: other large projects have struggled with this as well. The compiler discarded a NULL pointer check in the Linux kernel (which I can't find a good link to, so I'll let Chris Lattner paraphrase the issue for me): [http://blog.llvm.org/2011/05/what-every-c-programmer- should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should- know_14.html) ; here's one where it crippled sanitization of return addresses in NaCl: [https://bugs.chromium.org/p/nativeclient/issues/detail?id=24...](https://bugs.chromium.org/p/nativeclient/issues/detail?id=245)</comment></comment></comment></comment></comment></comment>


Be Skeptical of Both Piketty And His Skeptics - <AUTHOR> http://fivethirtyeight.com/features/be-skeptical-of-both-piketty-and-his-skeptics/ <comment><USER2> The critics always give the following argument for capital: "Capital accumulations raised the standards of living like no other".

I prefer to counter with the following.

Capital accumulation may in fact be a reason for increased living standards. For example, one of the largest capital accumulation events in history, the formation of the Soviet Union did in fact raise millions out of poverty. What isn't stated is that capital accumulation is synonymous with reduction of democratic freedoms. What happens if we value a rise in living standards over a rise in democratic freedoms? It appears the result is wholesale destruction of the planet's ecosystem without the political power to stop it.

<comment><USER3> It's possible to raise the standard of living of the working class while increasing the rate at which they are exploited, as explained in the lecture video below:

[https://www.youtube.com/watch?v=TqEKLuPCgZ0#t=11m47s](https://www.youtube.com/watch?v=TqEKLuPCgZ0#t=11m47s)

<comment><USER4> And that probably ties a great deal into wealth disparity in the first place, wealth being highly correlated with power as it is. Is it worth it, if everyone is affluent with plenty of leisure time and in good health, if a small fraction of a percent of the population control over half the wealth and means of production? Would such a society be stable?

</comment></comment></comment><comment><USER5> He used spreadsheets for that data? Let's hope it wasn't Excel:

[http://arstechnica.com/tech-policy/2013/04/microsoft- excel-t...](http://arstechnica.com/tech-policy/2013/04/microsoft-excel-the- ruiner-of-global-economies/)</comment>


No 4G signal? Then what should I do with this Samsung Galaxy Nexus? - <AUTHOR> http://news.cnet.com/8301-30686_3-57351748-266/no-4g-signal-then-what-should-i-do-with-this-samsung-galaxy-nexus/?tag=mncol <comment><USER2> Many phones use different algorithms to translate the actual signal strength into visual signal bars. Just because two different phones might say 3/5 bars they could actually have very different underlying signal strength and simply have varying levels of optimism in their interpretation.

You can get a dB reading for your Galaxy Nexus by going to Settings -> About Phone -> Status. The Signal Strength field should give it to you in both dB and ASU.</comment>