Who ordered memory fences on an x86? (2008) - <AUTHOR> https://bartoszmilewski.com/2008/11/05/who-ordered-memory-fences-on-an-x86/ <comment><USER2> I worked on a CPU with very relaxed ordering once. It was a MIPS variant, designed by the people who had previously worked on DEC Alpha. Unfortunately, there hadn't been an architecture _since_ Alpha that had such a relaxed model, so there was code in various parts of the Linux kernel that had gotten sloppy about memory barriers. I remember at least one in NBD, at least one in NFS, multiple in Lustre. Each one was a major PITA to debug, because (a) there was no evidence in memory of what went wrong and (b) the code would literally only fail once in a billion times. So there you are, looking at register values in a crash dump and trying to guess exactly which memory locations had to be read in which incorrect order to get to the state you're seeing. Ugh.

I have mixed feelings about all of this. On one hand, requiring every CPU to implement strong memory-order guarantees is one of the things holding back frequencies and concurrency levels. On the other hand, weaker models make bugs so likely and those bugs are so difficult that people add _excessive_ memory barriers and performance ends up being even worse. I don't know what the answer is, but it's a complex set of tradeoffs that I wish more people knew about.

<comment><USER3> > requiring every CPU to implement strong memory-order guarantees is one of > the things holding back frequencies

How does it hold back the _frequency_? I would have thought it would mean you can do less in each clock cycle, but not limit the frequency.

<comment><USER4> Because electrical signals, required for coordination, can only travel so far in one cycle.

<comment><USER3> Right, so you need more cycles to complete each operation, don't you? Why can't you run the same number of cycles though?

<comment><USER2> Memory ordering isn't the kind of thing that can be neatly separated from your instruction scheduler, register file, etc. Some of the communication and checking that's necessary to maintain strong ordering has to be handled within each unit each cycle. I'm probably doing a poor job explaining it, though. Maybe someone even closer to these issues can do better.

</comment></comment></comment></comment></comment><comment><USER5> The CPU core gives, and the compiler takes away.

While the x86 bus architecture is very forgiving, its guarantees only extend up to the level of assembly language. Compilers are happy to re-order operations that the machine has so carefully sequenced.

At the source-code level, therefore, you need to use "atomic" data types and operations (and carefully) just to retain the deterministic semantics the underlying machine implements.

That's the bad news. The good news is twofold: using atomics on x86 doesn't cost any extra (i.e., you pay for fully ordered operations whether you rely on them or not), and doing it right makes your code portable to machines with "relaxed" ordering, where you only pay for ordering if you ask for it.

Intel and AMD manage to make a strongly ordered bus system almost as fast as a relaxed one by throwing enormous numbers of transistors at the problem. It costs more power, and is the very devil to get right, but it makes wrong programs more likely to get the right answer anyway.

<comment><USER5> Something that has changed since 2008 is that Standardized languages actually have atomic types.

</comment></comment><comment><USER6> 2014: [https://news.ycombinator.com/item?id=8572160](https://news.ycombinator.com/item?id=8572160)

</comment><comment><USER7> Nowadays you also need an mfence for memset_s, not to leave secrets in the cache, as those caches can be read via sidechannel attacks (Spectre).

<comment><USER8> mfence clears the cache?

<comment><USER9> It does not.

Edit: it prevents store forwarding though, which is probably the attack rurban has in mind.

Edit2: or more precisely it prevents any attack on the store load aliasing predictor

<comment><USER7> Thanks for clarification. It only adds two fences, one into the load and one into the store ordering buffer. (not IO). But this has an as dramatic of an performance impact as a "clear cache", that's why I usually describe it that way. it just sets something like two dirty flags.</comment></comment></comment></comment>


6 months with MeteorJS - <AUTHOR> https://medium.com/@startwithoutanything/6-months-with-meteorjs-44dcea22e875#.ocu6g4pkq <comment><USER2> On the money, Meteor is in a bad place at the moment for new people.

Meteor 1.3 is right around the corner, and if you are just jumping into Meteor you might as well wait for 1.3 since it's drastic change. NPM, ES6, Modules, etc.

The problem is 1.3 does not have a go-live date. So you're stuck between a rock and a hard place.</comment>


The Chinese typewriter - <AUTHOR> http://www.latimes.com/world/asia/la-fg-chinese-typewriter-snap-story.html <comment><USER2> The video doesn't play, here's one found on youtube: [https://www.youtube.com/watch?v=M77DxXRI014](https://www.youtube.com/watch?v=M77DxXRI014)

This one is a more advance "semi-automatic" version: [https://www.youtube.com/watch?v=DRKAUDHk_MM](https://www.youtube.com/watch?v=DRKAUDHk_MM)

<comment><USER3> I got tired of playing NoScript roulette. I don't know what goes through the heads of web "designers" these days when they can't control the impulse to pull in scripts from a dozen or more sites.

<comment><USER4> If there is subresource integrity, then is there a problem with that per se?

</comment></comment></comment><comment><USER5> TL;DR: The typewriter has 2,500 distinct characters, and in order to increase typing speed, characters that are related meaning-wise are placed together.

As an aside, typewriters are very interesting piece of tech, if you look under the hood. I have one that I use regularly, and it's quite pleasing to use (I've an Olympia Traveller de Luxe).

</comment><comment><USER6> I suppose having only 2.5k characters available at a time on the tray means it would be used like a cache --- presumably the rarer ones would be kept somewhere else and swapped in as needed.

</comment><comment><USER7> Not knowing a thing about Chinese writing, it seems bit odd that no sort of character compositing system was utilized. Wikipedia has a mention of a "Ming Kwai Nao Can typewriter" which apparently had some novel character compositing, but apparently it didn't gain popularity, at least in China.

<comment><USER8> There's so few characters for which this would work reliably that it's basically pointless, plus it would require two or three actions to create a single character, further slowing down your typing.

Some typewriters do have accents as characters you can overtype, but these are simple to add by comparison, they land in consistent places. Chinese characters are anything but consistent.

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

<comment><USER7> The introduction section of Ming Kwai typewriter patent is interesting reading (in addition to the classic beautiful drawings): [https://www.google.com/patents/US2613795](https://www.google.com/patents/US2613795)

The concept looks like it should be applicable to computer keyboards, and especially virtual touchscreen ones. Heck, I'm half-curious to prototype such myself just to see how it works.

<comment><USER8> That thing looks impressively if not fiendishly complicated.

That seems like it's not an overtyping system, but one of selecting a single character based on a series of keystrokes.

</comment></comment></comment></comment><comment><USER9> From the video, using a typewriter seems to be sufficiently quick to be more efficient than handwriting, and of course more reliable. I find it a bit of a pity that a more phonetic writing system did not end up taking off. The most interesting bit to me is the shot of the code pages; these code pages remind the contemporary person of computer code pages.

</comment><comment><USER10> I'm amazed that the layout is based on character common bigrams, rather than some logical systems. Imagine the hunting down a character you don't remember where is, or that you've forgotten was replaced with a different key.

Typist must have been extremely familiar with their own device and I would imagine they didn't like to share.

</comment><comment><USER11> I can understand why the government would heavily restrict printing presses, but why typewriters? They're only modestly more efficient than handwriting.

<comment><USER12> The article mentions an anonymous letter sent to Mao's wife chastising her former love life. The letter was written on a typewriter.

I think the idea was that there should be no means of communication that cannot be traced. Whoever pens an idea should be aware that he/she can be traced back to.</comment></comment>


How Uber's Autonomous Cars Will Reshape the Economy by 2025 - <AUTHOR> http://zackkanter.com/2015/01/23/how-ubers-autonomous-cars-will-destroy-10-million-jobs-by-2025 <comment><USER3> I feel that autonomous cars are extremely oversold and cannot operate in many real world conditions like snowy roads and places with obscured road signs.

Maybe it can drive around some of the roads in the US after it has been fed with detailed 3D maps of the whole area along with road signs. But how about in other places ? Could it ever drive in a place like India ? I don't think so.

Autonomous vehicles could completely take over in closed areas like Open cast mines , vast factories and on farms where companies could profit by cutting the driver out of the loop. From there we would see the technology slowly improve to start getting traction in the real world. Even then the vehicle wouldn't be fully automated , it would be a more advanced form of the cruise control we have today with it falling back to the manual driver especially in crazy places like India.

Also we'd need laws forbidding people from jumping in front of self driving cars etc just to f@#$ with them.

This is also a trend with automation stories in general , with several publications already predicting doom and gloom and claiming that most people would end up unemployed because of automation of their jobs. The fact is we don't even have an AI good enough to impersonate a tele marketer yet and it's decades away at best.

I'm not denying that thesis in the extremely long term but AI and machine learning are in a very primitive state for any of this to materialize any time in the next two or three decades.

<comment><USER4> > real world conditions like snowy roads and places with obscured road signs.

Snowy roads are actually much better in many ways for cars (theoretically) than humans, because cars have much shorter reaction time. As for obscured road signs, if self-driving cars become the norm, road signs will likely disappear, because (A) they will use wireless communication to transmit information to cars, rather than visual scanning, and (B) a lot of information contained on road signs would simply be irrelevant or redundant for self- driving cars.

Remember that modern cars are _already_ very autonomous, even though they "feel" manual. Recently, I drove a car[0] that will actually automatically steer the car back into a lane if it senses that the driver is veering on the highway (ie, if he/she falls asleep or is drunk).

We don't think of this as "self-driving" because the improvements are incremental and the driver is still present and feels like he/she is in control, but drivers have been slowly giving up control over cars for several decades now. Self-driving cars are actually much less of a leap from the status quo than people realize; it's simply[1] the final step in a long series of incremental automation of automobiles[2].

[0] Subaru, I believe.

[1] Not that it isn't still an impressive feat, of course.

[2] Let's not forget the prefix or etymology of the world _auto_ mobile - it's not accidental!

<comment><USER5> A measured response/judgement is far more important than reaction time in snowy/icy conditions IMO.

<comment><USER6> yes for sure -- but software can measure & respond 1000s of times more than a human within a given time frame.

This is what control systems get very good at and apparently the traction control firmware in many cars that controls anti-lock brakes can include code that detects incorrect steering in icy scenarios and compensate for it. (sorry no reference - I heard this on NPR a while back)

</comment></comment></comment></comment><comment><USER7> "It is exciting to be alive, isn't it?"

It is for those of us who don't rely on the service industry for a living. 10 million jobs lost.

A self driving car is an amazing feat of Human engineering. What would be an even more amazing feat would be what to do with humans thrown under the bus of progress. Capitalism is great for anyone with enough mental agility to stay in the technology power curve, but it's really terrible for everyone else who simply want to live their lives, raise their family and be happy.

What are we going to do with all those humans displace by automation?

<comment><USER8> Driving won't be the first job to be displaced by technology, other jobs will appear - possibly one's we can't even imagine now.

<comment><USER9> This is a cop-out - the entire "people will find other things to do" argument is a total cop-out.

Yes, in aggregate, over long timespans (read: multiple generations), people will figure out other things to do. But as we've seen from the automation of manufacturing jobs in the US, a huge number of people _haven 't_ retrained, nor have magical jobs "we couldn't even imagine" erupted en masse to absorb a chronically un- or under-employed work force.

I submit that the oversimplified notion that people who lose their jobs to technology will be fine and find something else to do is mainly a device to make people like _us_ feel better - it isn't a notion that actually helps the displaced.

<comment><USER8> I don't believe it is, history has this repeated this playbook over and over, from horse power, steam power, electric power - labour intensive repetitive works have been slowly replaced by automation for hundreds of years now - driving is just the next in a long list.

My personal long-term view (beyond just automated cars) is that we _will_ automate away millions of jobs - but that's fantastic as it probably doesn't make sense for everyone to work anyway, a basic income guarantee can allow people to live lives with much more time for leisure, creativity and enjoyment.

<comment><USER9> > _" history has this repeated this playbook over and over, from horse power, > steam power, electric power - labour intensive repetitive works have been > slowly replaced by automation for hundreds of years now"_

Yes, and we've never suitably addressed the problem of displaced labor.

You're mistaking aggregate, macro-scale changes in the economy for micro-scale effects on people.

Bob the factory worker loses his job because of automation, the economy at the same time creates new jobs in other categories. From an aggregate scale the economy is still humming along - a contraction of labor demand on one side is offset by an expansion in labor demand on another side.

But what about Bob? Is Bob qualified to take one of these newly created jobs? How will he gain the qualifications to work this new job? Are these new jobs in Bob's geographic area, or does Bob have the financial means to move to new job centers to pursue work?

This is the problem - you've mistaken "there are new jobs" for "there are new jobs for the displaced workers". The assumption that there is even much of an intersection between these two things is pure supposition - supposition that gets trotted around a lot because we don't like to think about the notion that maybe Bob - who has 30-40 years left on his lifespan - may simply be chronically unemployed or underemployed for the entire rest of it.

In reality there are going to be millions - if not tens of millions - <USER2> Bob, who have lost their jobs and are unable to retrain into a field that the economy has created. _Others_ will take those new jobs, but Bob and his cohort are just plain fucked. The invention of new job categories does not remove the reality that Bob, and millions of others like him, are permanently out of work.

</comment></comment></comment></comment></comment><comment><USER10> _" PricewaterhouseCoopers predicts that the number of vehicles on the road will be reduced by 99%, estimating that the fleet will fall from 245 million to just 2.4 million vehicles."_

This isn't remotely close to possible. While it is technically true that cars spend most of their time sitting idle, the demand for transportation is lumpy. A huge percentage of the population works, sleeps, shops, and eats at approximately the same time. That means that with only 2.4 million cars available for use at any one time, the US economy would almost completely shut down. If the majority of those were Uber cars, surge pricing would be in effect most nomral hours....literally only the reviled "1%" could afford to go to work or do anything else from sunrise to sunset.

<comment><USER11> You are thinking of one person per car per commute. And also cars only. As a simple example lets say you commute 30 miles to work and it costs $10. Shortly after your journey starts the car can say: "Would you accept a 3 minute longer journey in return for a discount of $3?" Instant on-demand car pooling as it picks up someone else.

Similarly the car can take you to some point 3 miles away, you switch to a larger car ("bus"), get within a few miles of your destination where another car takes you to you final destination. The wait times can be very small, and again you'll have a financial incentive (discount) or can pay full whack for a completely private experience. The time and places where there are the highest demands on transport are the ones where self driving vehicles and financial incentives will be most effective.

Deliveries will become way cheaper too. Instead of each place managing their own delivery as currently happens, a delivery company can pick up things from multiple unrelated places. Suddenly there is no need for businesses like fast food to all be in high traffic areas.

<comment><USER10> Unless financially constrained, most people will not ride the bus to wherever they are going, today or in the future. Autonomous cars are real. The idea that humans will change their attitudes or behaviors because of them is not. Individuals will still own cars, they will just be autonomous. Car ownership may go down somewhat, but not by 99% or anywhere close to it.

<comment><USER12> I'm not sure about that. Humans adjust pretty well and relatively quickly to changes when the incentives are right. Where I live I see people from many walks of life use buses or other forms or public transport without trepidation. Sure, it's possible that people will never travel in a 'normal' car with complete strangers, but if that's the case I'm sure we'll find ways to make 'cars' more amenable to co-traveling so that the _significant_ advantages will be worth the slight inconvenience of traveling in one vehicle with strangers.

</comment></comment></comment></comment><comment><USER13> I think it's unlikely that an autonomous car will be $25,000. It is far more likely early autonomous vehicles will be $150,000.

However, this just slants the playing field in favor of an Uber-ish business model even more. When the utilization of the car nears 100%, you can justify that capital expense. It doesn't make sense for the average person to own a very expensive autonomous car, because they probably only use it two hours a day at most. When it is running 24/7 except for maintenance, that is a totally different story.

</comment><comment><USER14> _" PricewaterhouseCoopers predicts that the number of vehicles on the road will be reduced by 99%, estimating that the fleet will fall from 245 million to just 2.4 million vehicles."_

I do not believe that. For freight, more efficient use of freight vehicles will decrease the number of vehicles needed, but I guess that will be compensated for by more demand for freight transport because it will get cheaper.

As to personal transport: [http://traveltrends.transportation.org/Documents/CA10-4.pdf](http://traveltrends.transportation.org/Documents/CA10-4.pdf), page 5 shows that about 120 million people travel to work by car each day in the USA. To get them there in those 2.4 million vehicles, each vehicle would have to drive 50 people to work each morning and back each evening.

Picking a optimistic average car sharing load of 2 persons (the PDF puts carpooling at about 10%), that would be 25 trips. At a moderate 5 minutes a trip, it would take those cars 250 minutes to do that. That's about 4 hours, so the first people would arrive at work at 07:00 and the last ones at 11:00.

With realistic figures, those number will easily blow up to over 8 hours. So, it will require huge other changes (job los, working from home or highly increased car sharing) to get down to that 2.4 million number.

I also think those who can afford a car now will want to own a driverless car, too. Reason? If you do not need to drive, your car can become more of a living room: you will want to keep your favourite books and games in it. That in itself will slow down a decrease in the number of vehicles, but there is a second factor: once your car is your living room, chances are people will be less bothered about long commute trips.

</comment><comment><USER15> This is really bullish. I wonder what skin he has in game? As author states, uber can do best where owner drives fewer than 10k miles per year.

What about all the rural locations, or people who like to go on long trips?

And I think 50 cents per mile is extremely generous I think uber will charge more than that. Isn't IRS reimbursement rates something like 55 cents per mile? That's basically to cover costs not make any profit.

<comment><USER16> Just strip out the word Uber. I wouldn't assume it will be "Uber" that wins either. Once the self-driving space heats up it's going to be piled into by a ton of entities and there's no guaranteeing the outcome.

For that matter I won't promise you 2025. But I will say that if self-driving cars truly do become practical it will rewrite the economy in a lot of ways, and that if you stop and think and analyze, a lot of them aren't that difficult to guess, IMHO. For instance, that the nature of the capital expenditures will heavily favor "renting" over "owning" once we can easily rent on-demand is just obvious. A lot of this other stuff is too, really.

Of course, painting a full picture or correctly guessing timelines is essentially impossible. But some of the broad sketch isn't that hard.

</comment></comment><comment><USER17> Some of the numbers in this article don't make sense to me.

Today "cars are driven just 4% of the time". If you assume for a moment that people's transportation usage time stays the same, and "the number of vehicles on the road will be reduced by 99%", then the average car must be used 400% of the time. That would be possible if every self-driving car is carrying 4 passengers 100% of the time, 24 hours a day 7 days a week, which seems very unlikely. What am I missing?

I also don't see the justification for saying "90% reduction of vehicles in operation would reduce our overall emissions by" 90% of their greenhouse gas emissions. There might be 90% fewer vehicles, and you certainly save on environmental impact of vehicle production, but they will be used more per vehicle.

In fact, per-person transportation usage time may _increase_. If catching a ride is easy, fast, and cheap and allows us to work, sleep or play while riding, then many people will ride more often, or might buy a house that means a longer commute.

<comment><USER18> We're going to see an increased average number of passengers per vehicle. Current average in a city like San Francisco is 1.3 passengers/vehicle. An average of 4 is conceivable (67% decrease in number of vehicles on the road).

Autonomous vehicles will likely be electric - this is the other component that will reduce our need for fossil fuels.

<comment><USER17> Autonomous cars probably make transit optimization easier, but there's a tradeoff here that doesn't have very much to do with autonomy: The more people in the car, the less convenient for each rider, both because of comfort and delaying the trip with stops. It's basically the difference between a cab and a shared ride van today. It's certainly _conceivable_ that cabs mostly disappear and are replaced by shared ride vans, but lots of things are conceivable...

Autonomous vehicles will be electric but so will some (perhaps a smaller fraction of) non-autonomous vehicles. Anyway, that doesn't save the calculation. It's clear all these benefits are there but maybe not to the degree you claim, at least not in such a simple way.

</comment></comment></comment><comment><USER19> Yes, an interesting prognostication: a future with 'Total Recall' Johnny Cabs, a transportation circulatory system for cities. The gradual adoption would make most sense through the growth of closed systems where there are almost zero human drivers. Will the cars be like small public transit or are they single ride and not picking up random passengers along the way for the sake of efficiency (for the companies providing the rides surely electric cars and more single rides will yield greater monetary gains)? The social impact would be interesting - I've had good experiences meeting and talking with Uber drivers. That human element would certainly be removed, and now I am alone and robotically chauffeured around town staring at other people through the window. I'm intrigued at how it would feel to use such a system.

</comment><comment><USER20> I agree that self driving cars will be a huge savings in terms of resources spent on cars and the ecosystem surrouding them, but it won't be a huge benefit to disposable income. With cars taking up a huge chunk of the expenditure of humans, and with Inflation metrics being primarily driven by past concerns as opposed to future concerns (it took complete extinction of VHS for VCRs to be removed from the CPI), and with the general pervasiveness of monetarism (which, for some odd reason associates 0.0000001% deflation with the apocalypse) in central banking institutions, there is little doubt that any improvement in the average person's finances will be promptly inflated away.

</comment><comment><USER21> Everyone talks about passenger vehicles as the killer market for self driving cars, but it isn't. One of my friends is a Paramedic and he told me the overwhelming majority of traffic fatalities he sees are a result of big rig truck drivers falling asleep. It would suck to put a whole industry of workers out of a job, but if you could reliably and cheaply transport large amounts of cargo with a self driving vehicle which never slept, that is pretty amazing. It would certainly up the profit of the distributors moving tons upon tons of cargo around the world every day.

<comment><USER12> You're probably right. If I understand correctly, they recently passed laws that make it easier to test self-driving vehicles in Holland, and one of the first experiments will be 'convoys' of self-driving trucks.

<comment><USER14> [http://www.channelnewsasia.com/news/technology/dutch- approve...](http://www.channelnewsasia.com/news/technology/dutch-approve- large-scale/1611880.html)

The law hasn't passed yet, but apparently, Scania will start testing trucks in February. I am not sure that will be fully autonomous vehicles, though. It may be trucks that can follow a lead truck driven by humans.

</comment></comment></comment><comment><USER22> Do you trust software with your life?

Obviously 2025 software will be better than 2015 software but this question will still have to be answered strongly for mainstream adoption.

<comment><USER23> Do you trust people with your life?

I do understand your point, but I think a lot of people would trust software over a completely unknown person behind the wheel.

<comment><USER24> I think a lot of people would trust people over a completely disembodied piece of software with no skin in the game.

Drivers are careful because of others, but also because they too will suffer in an accident.

As one of my teachers used to joke: 'If you want to see an enormous improvement in the accident rate put a very sharp stainless steel spike on the steering wheel and remove the seatbelt from the drivers seat'.

</comment></comment></comment><comment><USER6> I might be driving around in autonomous cars by 2025 - but they won't be uber autonomous cars (assuming it still exists as a business). My impression of Uber and how it conducts business is not good - and that connection with a company and it's brand will be important when people start putting their lives in the hands of its software and hardware.

Tesla -- now thats another story (for me).

</comment><comment><USER25> It's not just Uber that will kill jobs. This video - [http://www.youtube.com/watch?v=7Pq-S557XQU](http://www.youtube.com/watch?v=7Pq-S557XQU) \- explains how many others jobs will be eliminated.

Re this article, I think the numbers are a bit drastic, but using less drastic numbers does not weaken the central point of the argument.

</comment><comment><USER22> Do you remember toll takers at the golden gate bridge?

Replacing them was slow because of the government.

The private sector will have no problem replacing taxi drivers when the technology is available from Google and every car manufacturer.

</comment><comment><USER7> The 6D exponential growth pattern is appearing everywhere.

Once a market becomes "Digitizable" or under computer control, it appears to grow slowly then it hits the elbow of the exponential growth curve and becomes Distuption. From there, old analog business artifacts are digitized (Dematerialization) and monetarily re-adjusted to compensate for the much cheaper costs of production (Demonitization). Then it's a simple matter to connect the service to everyone through the web and social media (Democratization).

Goodbye cars. Heloooo profit opportunity.

</comment><comment><USER26> This is certainly plausible. Nevertheless, the resulting changes in economy would drive more inequality and reward people with capital and/or technology

<comment><USER27> I think that's kind of the point of the article - there's going to be a massive shift in the structure of the economy when 10 million jobs disappear.

That being said, I think pretty much all of silicon valley is built on the principle that the future will "reward people with access to capital and/or technology."</comment></comment>


Chemistry of Cast Iron Seasoning: A Science-Based How-To (2010) - <AUTHOR> http://sherylcanter.com/wordpress/2010/01/a-science-based-technique-for-seasoning-cast-iron/ <comment><USER2> The mistake almost everyone makes is wiping the oil off. Start with a warm pan, apply the flax oil and try your best to wipe it all off. Use paper towels and just go to it. Bake at highest oven temp for 2 hours then leave in oven until cool. Repeat 3 times. The key is trying to wipe off all the oil you can each time.

I've been doing this for 30 years and it works if you do your best to wipe off all the oil you applied with a paper towel.

</comment><comment><USER3> I have a lazy-man's way of doing this. I put some oil in the pan and spread it all around, then wipe it up with a paper towel until there is just a very thin layer. Then I put on a lid and turn on the flame as high as it can go. After a minute or two it starts to smoke. I turn down the heat a bit and let it smoke for a minute, then turn off the heat and let it cool.

I know, this is not as good as doing it right, but it is a whole lot better than nothing, and the surface works well for my cooking.

</comment><comment><USER4> I've tried flaxseed several times. It always flaked off. I've never had the problem with more common, neutral oils like vegetable.</comment>


Asciidoctor PDF: A native PDF converter for AsciiDoc based on Asciidoctor - <AUTHOR> https://github.com/asciidoctor/asciidoctor-pdf <comment><USER2> We had very good results with Asciidoctor and Asciidoctor PDF for reports and especially for manuals.

In Asciidoctor PDF, we occationally ran into minor issues, but most of the time we pleasantly found out these vanished in the latest version, because other already found and fixed those.

There are some limitations, though, such as missing support for footnotes, nevertheless that's a topic that is worked on.

In general, we are very satisfied with the AsciiDoc format and the Asciidoctor tools, the syntax is much clearner and evolved in a much saner way than the alternatives (e.g. Markdown).

<comment><USER3> We like the improved table syntax in asciidoc over the alternative markdown formats...

</comment></comment><comment><USER4> Anybody aware of a good tool that does the reverse (PDF to some nicely editable format)? I don't care to maintain the page based layout.

I've tried some tools many years ago and the results weren't so good. I realize that due to how PDFs can be structured you can't ever expect such a tool to always be able to give perfect results.

<comment><USER5> `pdftotext` extracts the text from pdfs. At least it worked fine with me.

</comment></comment><comment><USER6> Marginally related: [https://news.ycombinator.com/item?id=12837454](https://news.ycombinator.com/item?id=12837454)

In-browser, zero-config, JS-based Asciidoc renderer.

</comment><comment><USER7> This is such a nice tool (as is Asciidoc/asciidoctor itself), I wish more people would use it and contribute to it's code to iron out the remaining bugs. Before I found out about it I used Markdown, but it's syntactic inconsistencies and lack of standards were always making me cringe. I just wish there were other easy to use GUIs besides AsciidocFX.

</comment><comment><USER8> It had the issue with inline images not working, and the author hasn't been fixing it for a year or two. Plus, there is no support for hyphenation. Otherwise a great tool.

<comment><USER9> Do you recommend a better Asciidoc to PDF tool chain without those limitations?</comment></comment>


Tiny Scala high-performance, async web framework, inspired by Sinatra - <AUTHOR> https://github.com/scalatra/scalatra

<comment><USER2> As a Rubyist who has had a hard time understanding the draw of Scala, I don't understand why I would use this library/framework. The Ruby and Java/Scala/etc communities seem to have vastly differing definitions of "tiny". Compare this to the source code of Sinatra[1]. Sinatra is very easy to navigate, and it's implemented completely in just 5 files (could technically be more, base.rb is a little over 2k lines). While Scalatra here is a seeming explosion of libraries, tools, and the usual multi-nested Java directory structure.

From the little I do know about Scala, it seems to me like you should be able to make a full Sinatra clone in Scala in as many lines and files as Sinatra, or less.

I guess what I'm trying to ask is this: If Scalatra is supposed to be "Tiny" why is it so big and complicated?

[1] [https://github.com/sinatra/sinatra](https://github.com/sinatra/sinatra)</comment>


Things I Learned Designing at Disqus - <AUTHOR> http://joshuasortino.com/journal/14-things-learned-designing-at-disqus <comment><USER2> If you are writing for a design audience, you are going to get a lot of frowns for the 700KB paper background image you have on your blog (and the paper barely even shows).

<comment><USER3> much worse (dark pattern?): on my mobile it puts a Twitter share link exactly where my thumb is touching the screen for scrolling.

</comment></comment><comment><USER4> "Engineers should teach engineers GIT, designers should teach designers GIT."

is git part of modern design workflow ? how are designers using git ?

<comment><USER5> At any scale, git is probably not going to be your best bet. svn might actually be a better option as it allows you to checkout just the parts of the repository that you need.

More crucially, it doesn't keep the entire history locally (just working copy and a the latest(ish) version in the repository). This really starts to matter when you have 200mb PSDs.

There are probably even better options out there (though previous searches didn't reveal anything I particularly got on with) - there are certainly better options than git.

Ideally something based around the dropbox model (doing block level deduplication) would be wonderful. Maybe such a product exists?

<comment><USER6> git does allow you to check out only a selection of version history

<comment><USER5> Oh ok, but that's not how it would operate, right? So, say it was just me working on a project using a psd. If I committed it a couple of times a day, I'd end up with all the old copies in the local object store. Maybe it's possible to clear those out, somehow? Either way, you'll find that you have to jump through hoops to get reasonable behaviour with git in this use case.

I see I've been downvoted for my previous comment. I'd appreciate a justification from the downvoter as this is actually an area in which I have some experience.

</comment></comment></comment></comment><comment><USER7> I agree with pretty much everything, except designers using Git. Sadly, Git doesn't work for PSD files properly. Some of the PSD files I've worked with before (900mb+) for larger websites and applications would definitely not be a good fit for Git. Although I think the blame lies mostly on Photoshop's end not being the right tool for web design, but being used by designers anyway. I think whatever tool ends up replacing Photoshop as the de-facto standard (if it happens) should ideally have a visual re-visioning system built in a la Adobe Creative Cloud.

We aren't quite at that point where designers are saving out all of the assets for you, then that would be different. You can source control individual assets, but not a large PSD file properly. I've begun to train the designers at my work to save out assets for pretty much everything leaving me to solve the engineering problems like how everything is going to work and less time cutting out images from a PSD file, but we aren't quite there yet where this is a universal thing that designers just know and willing do.

Some people might disagree with point #6, but I wholeheartedly agree as someone who works for a company where designers design and developers develop. I think to be truly great at design, you need to devote at least 90% of your time (minimum) to bettering your design skills. If you're a developer, the opposite rings true. I think it is important for design/dev to have a mutual understanding of one another, but I don't think you can truly be a great designer and great developer in one. Having an understanding of the other perspective is important. You'll never meet a surgeon who specialises in brain and heart surgery, why should design and development be any different?

Fortunately, the employer I work for doesn't compartmentalise the teams from one another. There is nothing more horrible than working in a place where design and development teams are on separate sides of the office or even different floors with the only communicative layer being a project manager or team leaders. Designers and developers sit down and tackle problems together and educate one another in the process. This is something that happens through the whole process from wire-framing to prototyping to final build. I think designers and developers should work together at every step. I have met talented design/developers, but great ones of both fields are extremely rare.

PS. Joshua, if you're reading this comment, you might want to reconsider the 670kb background image on your site. I loaded your blog on my slow ADSL connection and it was painful.

<comment><USER8> I'm not a designer, so please enlighten me. What kind of data can be held in a single image for a PSD to be 900 megabytes? Is it a single PSD for hundreds of web pages or?

<comment><USER9> Tons and tons of layers, I mean literally hundreds.

<comment><USER10> To elaborate, for anyone who hasn't used Photoshop (in several years): you can have layer groups which act as folders containing several related layers, so when you're browsing layers, it isn't just a mess of 500 some-odd rows.

<comment><USER9> Yeah, I should have mentioned that. You can also stuff a lot of component images into a psd that wouldn't necessarily make it into a final web design.

<comment><USER11> Sounds like what's needed is a way to extract a PSD into a component file structure, and combine that structure back into a PSD. Without knowing anything about PSDs, I assume it would contain lists of layers with links to resources such as images or whatever is required to approximate the desired view. Something like that as a plugin or hooked to run before and after commits would be really useful in this case.

Depending on how hard the PSD format is to grok (purposefully or otherwise), this may be nigh impossible, but it also seems like it would be a great exchange format (which may be a another reason Adobe wouldn't want it). Then again, maybe there's already something like this...?

</comment></comment></comment></comment></comment></comment><comment><USER12> > Designers are generally right brained and engineers are usually left brained

Is that true? Even if it's a myth of left vs right side of the brain are designers and engineers really that different in the brain?

<comment><USER13> It's pseudoscience. His point isn't, though: some people are more deductive/math oriented, some people are more associative/aesthetically oriented, and some people are neither. It's good for them to mix.

<comment><AUTHOR> Yup.

I know the whole left/right brain thing isn't real science. I was using it as a common metaphor. Designers and engineers typically approach things differently. Learn from someone else's approach.

</comment></comment></comment><comment><USER14> Would you say #6 and #7 are true generally, or Joshua's opinion?

To avoid inefficiency I find having people 'jigsaw-puzzle-piece' shaped helps - it means they're not always waiting on Bob on the desk over there to do the task that's blocking them (even if that task is only "Export an item from a PSD").

<comment><USER8> #6 is just semantics. Multi-purpose people are great. Rare and exceptional people are great. Designers who can code are great. What does it matter what you call them?

</comment></comment><comment><USER15> Isn't there something to be said about engineers teaching designers git, and the other way around? I understand that what you're saying is easier and more efficient, but learning to communicate should be a pretty big deal, and teaching others helps a lot.

</comment><comment><USER16> Does anyone have any thoughts on Disqus, particularly reviewing the usability and/or design aspects?

I see the service itself as meeting a need for those with static sites or who otherwise don't want to deal with managing their own commenting system. Disqus has also made some business decisions to increase revenue that have upset a few HN'ers¹. I haven't heard any complaints about usability or other design issues, though.

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

<comment><AUTHOR> Even if you haven't heard them, we still get complaints about the usability of the product! It's what we did with the feedback that matters.

As for the business decisions, those were decided by VPs and the business development team.

</comment></comment><comment><USER17> The thing that stood out for me is that over a billion unique people use the service. Does it really underpin that much of the modern Internet?

<comment><USER18> How many of those are voluntary, active users, though?

I see them more as "victims" of it, who are subjected to it without giving much consent at all. Somebody loads a blog article or some other web page that uses Disqus for accepting and showing comments, and without necessarily wanting to use it the page's visitors have become "users" of Disqus.

<comment><USER19> sheesh. That's a bit much.

The site owner chooses a commenting system. People who want to comment, comment using it. Victims?!

<comment><USER5> Victims is a pretty loaded term, but it's not an unreasonable accusation. The number of unique monthly users of disqus shouldn't be based on those who unwittingly use it.

Reading your comment again, I wonder what the true definition is. Is the number based on page views? Or is it the number of people who actively interact with the widget (say, posting a comment) after it has loaded? Sounds like you're assuming the later metric while the 'victims' comment is assuming the former.

Edit: thinking about it, 1 billion unique people, that sounds like the victim class to me.</comment></comment></comment></comment>


Show HN: A new simple GitOps deployment method - <AUTHOR> https://github.com/deliverybot/example-gitops <comment><USER2> I think the README could use some work. It covers too much of the "what" and not enough of the "why". For something as important as my push/deploy pipeline, I would be very hesitant to use something with this sparse of documentation.

</comment><comment><USER3> I've created a similar project a while back: [https://github.com/autoapply/autoapply](https://github.com/autoapply/autoapply)</comment>


The internet is an useful tool when used properly - <AUTHOR> https://www.independent.co.uk <comment><USER2> This is so true</comment>


Perhaps it is simpler to say that Intel was disrupted - <AUTHOR> https://medium.learningbyshipping.com/intel-disruption-594f806cfc21 <comment><USER2> One angle that is missing to this story: Nokia. Nokia bet big on Intel by partnering with them at the worst possible moment. In a nutshell, Intel was looking to get in on the mobile action and Nokia was willing to partner. This was ten years ago.

When platforms failed to come together because Intel was not delivering the goods, Nokia had to scramble to get new phones ramped up around alternative platforms. Nokia lost a lot of valuable time this way right when Apple and Android started kicking its ass. I wouldn't point at it as the root cause for Nokia's rapid collapse but it certainly was a contributing factor. E.g. Meego was years late to the market partly because of this and ultimately killed off in favor of the deal with Microsoft (another ill fated bet). And yes, Intel Atom was a big part of that failing as well.

Bottom line is that Intel tried and failed to get into the mobile market repeatedly and failed while being way too comfortable milking desktops and servers. Now that that market finally seems to be drying up, they have a problem and still no viable strategy to deal with it. Atom flopped. Itanium flopped. AMD is back looking stronger than ever. MS is has retired the wintel brand years ago and is seemingly open to running on ARM and getting quite cozy with Linux. Apple is widely rumored to also consider switching to their quite credible in house ARM based processors.

<comment><USER3> > _Apple is widely rumored to also consider switching to their quite credible > in house ARM based processors._

Does the Mac App Store require submission as source code?

If not, consider the implications.

<comment><USER4> They require (I think -- maybe just strongly encourage) submissions to the iOS App Store to include LLVM bitcode. It's easy to imagine them doing the same for the Mac. That would be a pretty clear signal that they plan to switch architectures.

<comment><USER5> Though it's not required they could easily make it fashionable / desirable (anyone remember fat binaries i.e. the ones including both PPC and Intel executables in one .app container?).

Or they could slowly make it required.

<comment><USER6> > Does the Mac App Store require submission as source code?

No. You do not submit source code.

> They require (I think -- maybe just strongly encourage) submissions to the > iOS App Store to include LLVM bitcode.

Apple does not currently require LLVM bitcode for iOS. It does require it for Apple TV and Apple Watch.

Additionally, LLVM bitcode is not architecture agnostic. It would not solve the problem of going from x86 to ARM.

> (anyone remember fat binaries i.e. the ones including both PPC and Intel > executables in one .app container?)

This was also used in Apple's transition from 32-bit to 64-bit on Mac. And later again on iOS.

So yes, if Apple were to transition CPU architectures again, fat binaries would be the likely approach.

</comment></comment></comment></comment></comment><comment><USER7> "In 2006 AMD (struggling) bought ATI for $5.4B. Intel just didn't even notice. It was super weird."

I think this is the best line in the whole thing. Intel _didn 't_ notice, and it _was_ super weird, and it was the best thing they ever did.

Fun fact: the first thing the engineers did with their new toy was bolt then- new R700 pipes to a hypertransport bus, so it used hypertransport to fulfill memory requests instead of a native Radeon GDDR controller.

The purchase of AMD and the Christmas morning giddiness of unwrapping that gift and turning it into what eventually became the prototype of the APU was the most brilliant thing ever.

To put it in perspective, lets count all x86 sales: all the desktops, all the laptops, all the servers, all the weird little things like x86 chinese tablets, all of it.

Combined Xbox One and PS4 sales (both massive APUs, essentially) dwarf all of the sales _both_ Intel and non-console AMD do; it dwarfs it in per chip and per thread. Intel only claims more sales in dollars than AMD (incl. MS and Sony deals) because of Intel tax, no legitimate reason.

Similarly, lets do the same with Radeon sales vs Nvidia GPUs... take all of the Nvidia GPUs (desktop, laptop, ARM SoCs like the Shield and the Nintendo Switch, server compute, etc), and all the AMD GPUs that aren't XBOne and PS4... console sales dwarf everything else that both companies make.

AMD won both races and no one even paid attention: AMD makes more x86 CPUs (both per chip and per thread), and more GPUs. Optimizing performance software (ie, games) has far more focus on both of AMD's platforms than anything else.

Intel and Nvidia are now the underdogs in their own races. This happened silently, and the cheer-leading for Team Blue and Team Green drowned out reality for a bit.

<comment><USER8> > Intel and Nvidia are now the underdogs in their own races

For Nvidia specifically I think that's only true of the gaming market (maybe crypto as well?), but my understanding is their massive increase in value over the last half-decade or so is predominantly from the deep learning market, where they continue to dominate by no small margin due to CUDA being a hard dependency of the major DL frameworks.

I don't have any hard numbers on it, but I wouldn't be surprised if the CUDA- tax is more than the Intel-tax ever was.

<comment><USER9> The CUDA tax is serious, however in this case it is mostly the fault of competing vendors that there is no CUDA or almost-CUDA implementation, since it is fairly high-level, unlike an ISA and the accompanying treadmill of patented features which move the expiry date of the "platform" 20 years into the future every couple years.

<comment><USER8> > it is mostly the fault of competing vendors that there is no CUDA or almost- > CUDA implementation

I very much agree, but I also don't have the skills or knowledge to say what kind of effort it takes to build such a language/toolchain. It seems like such an obvious opportunity for AMD, and has for so long, could it be less incompetence and more engineering difficulty and/or adoption struggles?

I know I've seen talk of CUDA-killers around these parts before, would love to hear more details from people more familiar with this stuff.

<comment><USER9> > _I know I 've seen talk of CUDA-killers around these parts before, would > love to hear more details from people more familiar with this stuff._

From the market perspective, it seems to me that a "CUDA killer" would not actually help. I think we need a free CUDA toolchain.

<comment><USER8> I think that's roughly what I meant; I'd like to see AMD dump resources into making a fully open, compatible-with-all-modern-GPUs toolchain to directly compete with and replace the CUDA one. For all I know, they already are?

Heck even a non-open, AMD-specific toolchain would probably be great for consumers, but an open, cross-compatible toolchain would be even better for us, and might be better for AMD as well by allowing non-AMD-employed experts to contribute.

<comment><USER10> > I think that's roughly what I meant; I'd like to see AMD dump resources into > making a fully open, compatible-with-all-modern-GPUs toolchain to directly > compete with and replace the CUDA one. For all I know, they already are?

There's OpenCL. Except OpenCL performance is worse than CUDA performance on NVidia, so anyone using NVidia's hardware (essentially, everyone) pretty much wants to use CUDA instead.

<comment><USER11> OpenCL made the mistake of being C only in the beginning while CUDA embraced C, C++ and Fortran, plus any language that would bother to write a PTX backend.

SPIR was too little, too late.

<comment><USER9> Maybe we could have a PTX frontend for SPIR-V. ;- )

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> old-gregg Any gamers or graphics experts here? I keep hearing that Intel's integrated graphics is terrible, yet being a typical desktop user/non-gamer, I've always avoided dedicated GPUs in favor of Intel on purpose. Intel GMAs always offered better battery life, better Linux compatibility, better operating temperatures (and zero additional fan noise) yet they did everything a non-gamer can ask for: hardware-accelerated video playback, desktop effects like the ones Steven writes about, etc.

Recently I looked into AMD's 2400G APU with much superior graphics but I don't understand what is it for. Sure it can sort of run some games at mediocre frame rates on last-century 1080p monitors, but not higher. But everything else Intel will do just as well... Looks like all these integrated GPUs are starved of memory bandwidth anyway. So what's the point of these APUs then? Where's the AMD graphics advantage? And what's problem then with Intel's integrated graphics?

<comment><USER12> You have to remember the GPU described in the article were in 2010 - 2012 era. And it was iGPU in Atoms. They key to GPU performance were drivers, and Intel in those days won't very active in GPU drivers development. At the time updating GPU drivers for notebook were problematic. Lot of issues left unresolved, and Mozilla blacklist lot of Intel drivers from GPU acceleration. And they (purposely?) make a mess of dGPU graphics switching.

It wasn't until Broadwell, and later Iris Graphics era, which I think is 2012 / 2013 before things starting to pick up. Intel actively optimising their drivers for stability, OpenGL, and Performance.

AMD's Graphics Advantage is that their drivers are better tested. Over the near three decades of history has taught us, the GPU hardware is absolutely nothing with out top notch drivers support. Intel I740, Matrox, 3Dfx, S3 Verge, 3Dlabs, PowerVR......

<comment><USER13> Actually the early Intel GPU efforts were hillariously bad partly because they licensed someone else's GPU...

[https://en.wikipedia.org/wiki/System_Controller_Hub#Poulsbo](https://en.wikipedia.org/wiki/System_Controller_Hub#Poulsbo)

There /still/ isn't support for this closed platform on Linux/etc based systems due to a combination of (now) outdated hardware, very few systems in developer hands (even lower interest), and the lack of performance even with proper drivers* (I don't have a good citation for that).

[https://en.wikipedia.org/wiki/Bonnell_(microarchitecture)](https://en.wikipedia.org/wiki/Bonnell_\(microarchitecture\))

It didn't help that the power requirements fell very solidly in to the uncanny valley between 'crappy, but very low power so we can forgive it' and 'good, but uses lots of power'.

</comment></comment></comment><comment><USER14> This article is missing many critical details. Most notably it doesn't touch on the core identity crisis Intel has been having since the i386. When Intel cut off third party "fabs" from producing its chips, it became reliant on high margin chips that were completely vertically integrated. In a sense this incentivized the company to ignore lower margin fields like embedded and mobile. Obviously the iPhone changed the game in mobile, and showed that there is a space for high-margin mobile parts. Intel was equipped for this transition because they spent years optimizing their CPU->Factory connection. Their factories were optimized to bump out CPUs, not mixed silicon, to the point where Intel's own wireless group would produce wireless Chips at TSMC. Intel faced dwindeling consumer demand, which led to factories not being full, which led to less investment in chip fabrication. Keep in mind in the last several years, Intel's main chip performance advantage was due to the superior manufacturing abilities of it's factories. Better factories mean more transistors per inch, more transistors means more cores and IPC (assuming competent designers). Intel's inability to produce general silicon hurts them to this day, as Intel's effort to open its fabs to the general public have largely failed (Intel Custom Foundry). A further issue that plagued Intel was it's inability to produce integrated mobile SoCs in a timely manner. Intel Acquired infineon when they realized they needed a quick pathway to building an integrated 4G modem. Ultimately the product was not built in time, but at least now this investment is kind of paying off as Intel has won the modem spot in modern iPhones. However Intel was not able to put together a product competitive enough with Qualcomm due to the time it takes to mobilize enough resources to build a high end SoC.

<comment><USER15> > Intel's inability to produce general silicon hurts them to this day, as > Intel's effort to open its fabs to the general public have largely failed > (Intel Custom Foundry).

Their refusal to fab ARM chips hurts them more than the design-rule complexity of their process.

</comment></comment><comment><USER16> Intel was disrupted, for sure. Basically, I'm left wondering if there was some key brain-drain that occurred to Intel. Back in grad school in the mid 90's, most of the profs thought that Intel would collapse under the weight of the x86 ISA, but one prof knew people in Intel and told me about their roadmap going out to 2010, with plans for kicking butt. All of that played out! This shows amazing foresight. However, in recent years, Intel seems to have gotten itself painted into a corner with regards to die sizes, while AMD has strategically shifted to combining chips with smaller die sizes to increase yields and increase margins with more competitive pricing.

"Interposers, Chiplets and...ButterDonuts?" \-- [https://www.youtube.com/watch?v=G3kGSbWFig4](https://www.youtube.com/watch?v=G3kGSbWFig4)

Something has happened with Intel, which has lost its vaunted intelligent "paranoia."

<comment><USER17> When I worked for Intel in 2005-2007, a lot of the workforce joined near the beginning, and planned to make their career at Intel. Most of those people probably retired in the last few years.

After two years, I was still "the new guy."

They also totally goofed mobile, as the article explains. Everyone knew mobile would be a big deal; it was "obvious." Even Moore's law predicted mobile. (Every 18 months the number of transistors you can fit in a given area doubles = every 18 months you can make the same chip use half the space.)

Why did they goof mobile? I think the article explains the symptoms well, but even I have trouble explaining "why" given that everyone could see mobile coming.

<comment><USER18> In 2003, Intel was able to reinvent its CPU design center in response to the previous iteration of PC miniaturization (the laptop market was ready to explode, while desktops were slowing down). They did this by running a skunkworks design project in Intel's Israel division ([https://en.wikipedia.org/wiki/Pentium_M](https://en.wikipedia.org/wiki/Pentium_M)). After the Israeli engineers were able to show how their design fixed Pentium 4's architectural issues, it became the basis for all successful Intel processors for the next decade.

Intel did great in process technology and the ecosystem around their chips. They were extremely well positioned to grab the smartphone market. Contrary to popular belief, x86 is entirely capable of the TDPs required by mobile phones. The Core m3 has a configurable TDP under 4W while making none of the compromises of Atom. It might have taken another skunkworks project to cut some modules and bring it down to the milliwatt range, but it could have been done. Intel simply allowed itself to be outmaneuvered out of the smartphone market, by complacency and unwillingness to lower the "tax". That worked fine for a decade, but now they're seeing the side effects of the resulting brain drain.

<comment><USER19> >The Core m3 has a configurable TDP under 4W

No. This is best to say a safety measure: going over 4w over 5 seconds? turning on deep throtlinng.

Real engineering datasheets you get as a client tell very clearly that TDP of Y line chips is 17w.

Intel chips at such wattages are just a lot of dark silicon.

Your analysis is wrong.

</comment></comment></comment></comment><comment><USER12> This is a much better piece then the @stratechery one. And my thought on @stratechery were the same as S.Sinofsky, it wasn't the integration that is the problem. It was a go to market. I think the word "go to market" is better than what I described as "vision and execution".

Had its execution been perfect, its Roadmap of better IPC, more Core, and 10nm / 7nm node, it would still have lots of room to adjust. Although I think a better execution is only just delaying the problem. Like the article have said, it really is a multiple things.

Had Intel set out to make the best SoC for Netbook.

Had Intel set out to make the best Graphics within those die space.

This is the classic case, where Steve Jobs describe companies with a monopoly are ran by sales and marketing people.[1] And Product people ( Pat Gelsinger ) are driven out of management decision process.

I still remember in one of the video interview, Pat Gelsinger; I cant remember if it was EMC or VMware era, clearly describe how x86 would rule Sever space as long as it continue to improve and innovate. And trying create a half hearted SoC with x86 into Mobile wouldn't work. And it was all too late. ( I can no longer find that video )

And some people might think S.Sinofsky view on Intel graphics a little strange, remember Intel graphics didn't became good until Apple forces them to be better. And S.Sinofsky left M$ in 2012, the design of those Surface devices must have happened during 2010 era, and to make matter worst the graphics on Atom were generation behind what Intel had on the desktop.

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

</comment><comment><USER20> Intel is resilient, if anything.

They have had a ton of flops and misdirections. The 186. iAPX. i740. Xscale. Itanium. The FDIV bug. Pentium 4.

AMD has had Intel up against the ropes more times than they can count. Faster and cheaper 386 and 486 clones threatened them. The K6 came around and beat the Pentium II. AMD leap-frogged them with their 64-bit chips. Intel has always came back and stomped them right back into oblivion. They'd probably be close to turning the lights off if it weren't for Ryzen.

<comment><USER21> Sorry to nitpick but Pentium 4 was a temporary flop until the HT version came along for which AMD had no answer. And I don't think the K6 beat Pentium II. Having bought a $2000 K6-2 computer in 1998 with maxed out RAM and graphics, I instantly regretted that decision as all my friend's mediocre Pentium II's ran applications and games better than my K6-2.

<comment><USER22> The original HT implementation was so incredibly bad that people would turn it off to improve performance on multithreaded loads.

<comment><USER23> So true! It only worked on example code, it was very difficult to get an improvement in a real world app.

</comment></comment></comment></comment><comment><USER24> While it may be simpler, it may also be inaccurate. The fact that Intel's dominance isn't as pervasive as before does not mean it's no longer #1. AMD has a long way to go.

One a related note, to my knowledge AMD is still essentially absent from the Autonomous Driving market, with NVIDIA and Intel fighting to be top dogs through different approaches¹. With some estimates for the size of that market (including non-chip portions) going as high as trillions of dollars², I hope for AMD's sake it has a plan to catch up sooner rather than later.

__________

1\. [https://www.benzinga.com/top-stories/18/02/11148965/which- ch...](https://www.benzinga.com/top-stories/18/02/11148965/which-chipmaker- leads-the-autonomous-driving-space)

2\. [http://fortune.com/2017/06/03/autonomous-vehicles- market/](http://fortune.com/2017/06/03/autonomous-vehicles-market/)

<comment><USER25> What Autonomous Driving market? From what I have heard, right now autonomous driving even by leaders like Waymo is incredibly small-potatoes and the rigs running in these cars are mostly prototypes built with commodity hardware.

It's just way too early to start picking winners and losers in the hardware space for autonomous given that nothing is being mass-produced. And there is no price-competition in the space because the major players are willing to pay whatever it takes as part of their R&D efforts to win the race.

<comment><USER24> This autonomous market:

[https://www.reuters.com/article/us-israel-tech-intel- mobiley...](https://www.reuters.com/article/us-israel-tech-intel-mobileye- exclusive/exclusive-intels-mobileye-gets-self-driving-tech-deal-for-8-million- cars-idUSKCN1II0K7)

[https://www.nvidia.com/en-us/self-driving-cars/drive- platfor...](https://www.nvidia.com/en-us/self-driving-cars/drive-platform/)

</comment></comment></comment><comment><USER23> I remember getting money from Intel to put MMX instructions into a game and later getting money to use hyper-threading. In both cases, at the time, the improvement was at the margins and not worth the work it hadn't been subsidized. It seemed like the best thing you could say about it was that it didn't work on an AMD chip.

<comment><USER26> Nowadays, MMX (and newer SIMD instruction sets) are a crucial part of many optimizations. Hyperthreading is provided in all modern processors. Basically, those technologies proved themselves.

<comment><USER23> At the time the SIMD instruction set did not exist and the MMX instruction set was difficult to apply in a way that got us an advantage in our application. When you say all modern processors have Hyperthreading, are you sure you don't mean multithreading? I am not sure every processor has hyperthreading. I am not knowledgeable enough to argue about the overall value of MMX and Hyperthreading but I think the point of the article at the top of this page is that it in the end -- although maybe not at first -- it was counter- productive.

</comment></comment></comment><comment><USER27> As someone who left Intel last year for one of its customers in the Valley, I have to say I'm sad that the future looks pretty dark for them. In the exit interview, I said I might come back if the CEO and my department head left (they both did), but I didn't know the company was such a mess.

That said, Intel is viewed from the outside as sort of an old monopolistic monolith, but a lot of that profit gets plowed into a bunch of truly innovative semiconductor R&D going on that I do not believe is being replicated by competitors. 3D XPoint is probably the most visible example. AMD, TSMC, Samsung, etc. I doubt will pick up the torch.

<comment><USER28> So where do you feel their competitive advantage lies right now, by the way?

You make it sound both like they do struggle lately but they have stuff lined up that cannot be competed with. Slightly confusing for me, could you elaborate?

<comment><USER27> Well the two are not mutually exclusive. I worked there for close to 5 years on a few different silicon-related projects that I characterize as unique in the market and not a single one has even made it into an announced product. These were not small endeavors, so either the development times for silicon are extremely long or Intel cannot execute on its ideas. Regarding the former possibility, I heard from people who were around since the beginning that 3D XPoint was in development for a decade before it was announced in 2015.

<comment><USER28> Oh, I agree, but what you describe seem to be latent / possible-in-the-future breakthroughs. Until they see the light of day they are irrelevant IMO.

</comment></comment></comment></comment><comment><USER29> From the article it sounds more like Intel kept building up a moat that everyone got sick of crossing.

<comment><USER30> Ya.. I go back and forth in my head a LOT about the importance of moats. Constantly second guess myself. You sacrifice SO MUCH velocity building a moat, and you cut off any possibility of other companies helping "rise all ships".

But at the same time, aren't there competent cloners lurking behind every corner ready to jump on your product market fit and outpace you?

This article pushed me a little further into the "don't worry about moats; make your partners successful" camp. But I waver.

</comment></comment><comment><USER31> Reading this makes it very clear why Apple would be moving towards using its own chips in laptops.

<comment><AUTHOR> Besides everything else going on, they left 68k because it was falling behind and couldn't compete or speed up enough. They left the G3/G4 line when once again they were stuck and Intel was running away.

So they went to Intel. They're now on the same treadmill as everyone else. Can't do better, can't be totally stuck. But Intel isn't progressing very fast, and they don't seem to be focusing on the things Apple wants like ultra- low power.

But Apple's chip division is kicking ass. The 10.5" iPad Pro is a monster, and could easily power a MacBook faster than an Intel chip. The real question is what to do on the MBP and iMac Pro.

Apple has never been keen on AMD for some reason, not sure if they have a chance on the high end. My impression is they don't compete on low end/low power but I don't know how accurate that is.

<comment><USER32> Pretty sure an ARM tablet chip is not going to beat Intel, even on the low end. Otherwise we would have moved on already. Also, apple does like AMD and uses their gpus because they have bad blood with nvidia. Apple primarily makes laptops and AMD has not been competitive until they developed Ryzen.

<comment><USER33> [https://9to5mac.com/2017/09/22/iphone-8-geekbench-test- score...](https://9to5mac.com/2017/09/22/iphone-8-geekbench-test-scores/)

The iPhone 8 CPU is competitive with a Core i5

<comment><USER34> That claim would be highly suspect in general, given that a desktop CPU has at least 10 times more headroom in power consumption.

For such a claim to be true, you would have to expect that the phone CPU is somehow 10 times more efficient per Watt, while having the same kind of architecture (general CPU, not GPU/TPU/...).

<comment> Const-me I think he might be correct.

Apple A11 has 297 GFlops CPU performance. (1)

That "7th gen i5" is apparently i5-7360U. 32 FLOPs/cycle/core (2) * 2 cores * 3.50 GHz (=max turbo) = 224 GFlops.

> the phone CPU is somehow 10 times more efficient per Watt

Not 10 times. The i5's TDP is just 15W. I don't know about A11 but high-end Qualcomm chips can be up to 5-6W, just 3 times difference.

> while having the same kind of architecture (general CPU, not GPU/TPU).

That's a continuum. They both CPUs, they both have SIMD that's how they achieve that high flop/cycle, but the architecture can be quite different. A11 has 6 cores. Intel spends many transistors, and therefore energy, doing very complicated things: branch prediction, indirect branch prediction, cache synchronization between cores, speculative execution… Apple has full control over OS and software, they can probably get away with not doing some of these. Intel and AMD have to maintain compatibility with all software (including single threaded), built by all compilers and languages, that's why they have fewer tradeoffs available to them.

(1) [https://forum.beyond3d.com/posts/2021926/](https://forum.beyond3d.com/posts/2021926/)

(2) [https://stackoverflow.com/a/15657772/126995](https://stackoverflow.com/a/15657772/126995)

</comment></comment></comment></comment></comment></comment><comment><USER35> _Everyone is ultimately proprietary even in the Open Source world. Once you invest heavily in any sort of architecture or platform, you're not moving anywhere with your current investment._

I've argued this point repeatedly in real life and on HN. The people who don't want to use any of AWSs proprietary infrastructure or developers who want to use the repository pattern for the sole purpose of "not locking themselves" into one vendor.

I've never in 20+ years seen a major organization switch from a well known vendor to save a few dollars. Even if you theoretically can change your infrastructure, the risks and the amount of regression testing you have to do hardly ever makes it worthwhile to switch infrastructure.

As far as open source coming to the rescue, if someone else doesn't takeover an open source project, more than likely, your company won't either.

<comment><USER28> I am largely in agreement with you, however there are many well-documented cases, right here in HN, about companies bleeding a lot of money due to their usage of AWS and a few others. Such services are really good when you are starting off -- they eliminate a huge upfront time cost, and for most startups time to market is the difference between life and death. And as you start, they are pretty cheap as well.

However, once the startup takes off and becomes cash-positive and has to scale, then AWS in particular becomes a huge point in your balance sheet. It's a very well executed vendor lock-in, I will give them that.

Many companies are using European VPS hosting and once they have mid-level business contract that guarantees 99.9999% uptime because the provider can replicate to 3 separate physical data centers, they are happy both with the service and the cost. Granted they need their own Ops teams but long-term this scales much better and is sustainable.

Managed cloud infrastructure is mostly overrated and the complexity of it is by design. AWS in particular is borderline crazy lately, they have dozens and dozens of inter-connected services and "AWS consultant" is now a commonplace title in CVs.

<comment><USER35> Amazon doesn't "lock you in" with VPS hosting. If that's what is costing you, you can access all of AWSs other services over the internet. You can setup a VPN from your colo center to AWS and still access all of thier managed services.

How is it less complex to host your own database servers, load balancers, queuing system, redundant storage, CI/CD servers, ELk stack, redundant memcache or Redis servers, distributed job scheduler (I've used Hashicorps Nomad in the past), configuration servers, etc. These are just the services that you don't have to manage the underlying servers and you get redundancy.

I'm first and foremost a developer. But the money the company I work for saves by not having to hire dedicated people to manage and babysit servers more than makes up for the cost of AWS.

It just so happens that I know AWS well enough and have experience as an "architect" (and have the certifications to give them a warm and fuzzy) to be competent at the netops and devops side of things.

<comment><USER28> > _How is it less complex to host your own..._

It is not less complex. It is definitely more complex and is harder. My point was that financially it is more sustainable long-term. And once your org is bigger, dedicated Ops team gives much more peace of mind. Whoever is on shift flips 3 switches and things are back to normal in 2 minutes, 99% of the time. That is not always the case even with a huge provider like Amazon and Google.

> _But the money the company I work for saves by not having to hire dedicated > people to manage and babysit servers more than makes up for the cost of > AWS._

Disagreed. Periodically, there pop up articles here in HN that prove with numbers and historical timelines that AWS only saves you time and white hair while you are smaller. Once you start to scale up and/or use more of their services, bills start to pile up quicker than before (people have mostly analyzed the exponential growth of their billing). Apologies that I don't keep the links but I remember that I've read at least 5 such articles in the last year, right here in HN.

> _It just so happens that I know AWS well enough and have experience as an > "architect" (and have the certifications to give them a warm and fuzzy) to > be competent at the netops and devops side of things._

Good for you, many of us don't however. I honestly have no intention to either. It's a very specific vendor cloud system with a huge amount of proprietary tech baked in, and I have no desire to entangle my career prospects with its success. Career preferences. ;)

<comment><USER35> _It is not less complex. It is definitely more complex and is harder. My point was that financially it is more sustainable long-term._

Can you set up a duplicate infrastructure that's close to your international facilities worldwide cheaper? Even support would be cheaper because you can have one central team manage your worldwide infrastructure. Netflix moved their entire infrastructure to AWS. You're not taking into account the cost of enploying people to babysit and do the "undifferentiated heavy lifting", the cost of over provisioning just in case, the cost of the red tape to provision backup hardware for failover, etc.

* And once your org is bigger, dedicated Ops team gives much more peace of mind.*

You can easily outsource netops to a dozen companies that can be cheaper because they can manage multiple accounts and they can outsource the grunt work to cheaper labor. I know, I've worked in two companies that outsource day today management of netops.

 _Whoever is on shift flips 3 switches and things are back to normal in 2 minutes, 99% of the time. That is not always the case even with a huge provider like Amazon and Google._

You've never had to deal with a colo center. Have you ever dealt with AWS support as a representative of a large company?

 _Disagreed. Periodically, there pop up articles here in HN that prove with numbers and historical timelines that AWS only saves you time and white hair while you are smaller. Once you start to scale up and /or use more of their services, bills start to pile up quicker than before (people have mostly analyzed the exponential growth of their billing). _

If the fixed cost of your infrastructure is growing faster than your revenue...you're doing it wrong. Even if you can get simple VPS elsewhere (and yes you can). Thsts not where you get the win from AWS. You can host VPS anywhere and still take advantage of all of AWSs services.

 _Good for you, many of us don 't however. I honestly have no intention to either. It's a very specific vendor cloud system with a huge amount of proprietary tech baked in, and I have no desire to entangle my career prospects with its success. Career preferences. ;)_

That's just what the original article said. You always tie yourself to a specific technology and risk that technology becoming out of favor. The trick is to stay nimble and to keep learning. Right now, there is a lot more money and opportunity in being a "Cloud Architect" than knowing how to set the same things up on prem.

</comment></comment></comment></comment></comment><comment><USER36> I can't comment on the veracity of the article, but I'd like to just add that the article was a compelling read.

I am a fan of AMD because I like competition, especially from a spunky competitor. I'd say the same about Nintendo, which keeps finding ways to win by focusing on fun over specs.

</comment><comment><USER9> > _...key assumptions...:_

> _..._

> _Discrete graphics_

I get the impression that Steven is willing to make up the history to match the conclusion.

<comment><AUTHOR> How so?

<comment><USER9> Intel were the first to mass market with reasonable "integrated" (even if it was just part of the northbridge, it would be in _every_ platform) accelerated graphics.

<comment> sjm-lbm He also totally ignores the i740 - not a major part of the story of Intel and perhaps a misstep, sure, but to act as if they hadn't tried to take a discrete graphics chip to market well before AMD bought ATi is crazy.

Also, he seems to act as if Itanium was developed in response to AMD64:

>Brilliant brilliant choice by NT team was the bet on the AMD 64 bit instructions. Seeing AMD64 all over the code drove them "nuts".

>That led to Itanium…more proprietary distraction.

It was pretty close to the opposite. IA64 was Intel's plan for the future for more than half of the 90s, and the spec for AMD64 wasn't even published until 2000/2001 or thereabouts. Actual AMD64 processors came out about two years after Itanium. His quote to support the above assertion even mentions this, which confuses me more.

</comment></comment></comment></comment><comment><USER37> Another angle: BK's 2016 lay offs were done in such a bad style that experienced engineers began leaving company in large numbers. I guess that drained the company with a lot of talent.

</comment><comment><USER38> Thinking about it, I wonder if some of the reasons for the unethical tactics Intel did in the mid-2000s was fear that the revenue would decline quickly if the market share goes to say 10%.

</comment><comment><USER39> Am I missing something here? Intel's operating income is higher than it's ever been. They aren't being disrupted by any meaningful measure of disruption.

</comment><comment><USER40> Was this post written on a phone? The amount of abbreviations ("Ppl", "gfx") and emojis is bothersome.

<comment><USER41> If that bothers you, maybe the internet is not for you... :P

Anyways, seeing people communicate and expressing themselves in different ways is pretty cool to me.

<comment><USER42> Colloquial expressions and shorthand generally make a written work harder to comprehend for a broad audience. Broad comprehension and dissemination is generally what you want in written work.

</comment></comment></comment><comment><USER43> What's the deal with all of the random italics disrupting the flow of the article?

<comment><AUTHOR> I believe they're quotes from Ben Thompson's article, but it took me until about halfway through to figure that out.</comment></comment>


Wikipedians test whether it's possible for new editors to still create articles - <AUTHOR> http://en.wikipedia.org/wiki/Wikipedia:Newbie_treatment_at_CSD <comment><USER2> That fails right on the first line:

Create a new wikipedia account (remembering of course to inform Arbcom per WP:Multiple Accounts by emailing (arbcom-l-at-lists.wikimedia.org)

If this test is to be meaningful they should do it from a computer and IP that has not been used for WP work in the past.

<comment><USER3> If you read past the first line, you'll see that having an IP that has been used for WP work in the past doesn't seem to be helping them any-- the vast majority of articles are marked for deletion within minutes, sometimes within seconds.

<comment><USER2> So, then the bit about having duplicate accounts can be dropped.</comment></comment></comment>


Mozilla Global Sprint 2018 - <AUTHOR> https://github.com/mozilla/global-sprint/milestone/1 <comment><USER2> Given that this is all driven by volunteer work, wouldn't it have made more sense to schedule the "sprint" on a weekend?

<comment><USER3> Can "sprints" be reconciled with volunteering? The joy of open source is that you can work on what you want, when you want. The moment that somebody tells you what to do and when to do it, it begins to look at bit like a job.

<comment><USER4> It's not like you get punished for not participating. It's just a motivation to actually do something and get some sense of community

</comment></comment></comment><comment><USER5> Mozilla needs to cut down on the noise on the sprint's issue board, take a look: [https://github.com/search?p=1&q=label%3Amozsprint&state=open...](https://github.com/search?p=1&q=label%3Amozsprint&state=open&type=Issues)

There's so much baloney like this:

\- How can we solve X problem? Where X is a global problem that potentially has thousands of stakeholders and use cases, requiring millions of dollars in time and effort.

\- Can you fill out this survey?

\- What flavour of ice cream do you like?

\- Start your own hackathon/organize your own event!

\- When is someone considered a senior Ruby developer?

\- What have you done with your skills?

\- Write us instructions on how to use X tool. Where X is an industry standard tool that has thousands of hits on google about how to use it.

When did the open source community get this watered down?

<comment><USER6> Actually, they have. If you follow the link on OP, you'll see 93 selected issues, not the 941 noisy ones you linked.

They're actually putting some effort into this as well. Not just creating a place for a ton of random junk, pat on the back, "good luck, go figure".

EDIT: Your filter is just "label:mozsprint" across all of GitHub. That's pretty likely to include noise that Mozilla cannot do anything about.

</comment></comment><comment><USER7> Wow, that's actually a pretty cool initiative. An extra push to start giving back to the community. I'll find myself a project and start contributing!

</comment><comment><USER8> what exactly is Mozilla doing except having created a github issue tracker?

<comment><AUTHOR> Here's background on the larger mission: [https://blog.mozilla.org/blog/2018/05/07/mozillas-48-hour- ha...](https://blog.mozilla.org/blog/2018/05/07/mozillas-48-hour-hackathon- for-a-better-internet/)

<comment><USER9> Unless I'm missing something, the answer from the link is ~nothing and/or taking credit?

<comment><USER10> \- Curated a list of bugs/features/issues that are accessible to noobs as well as veterans

\- Coordinated with project owners that wanted to be involved

\- Setup a structure for mentoring and leadership on projects

\- Broadcast the initiative

\- Focused the project list on things that would build a "more healthy internet"

</comment></comment></comment></comment><comment><USER11> Finally, an opportunity to engage in uncompensated labour!

<comment><USER12> Well, that's the most hostile possible interpretation.

<comment><USER13> Maybe it's tongue-in-cheek?

</comment></comment></comment><comment><USER14> An accompanying explanation would've been nice. For future visitors [0]:

> Mozilla's Global Sprint, a distributed work/collaboration sprint on open > projects from around the world!

> Every issue in this repository represents a project seeking contribution.

[0] [https://github.com/mozilla/global- sprint/issues/299](https://github.com/mozilla/global-sprint/issues/299)

</comment><comment><USER15> Unless I managed to completely miss something, I see no mention of the copyright issues that likely ensare a good percentage of those who would otherwise be their prime audience.

This sounds interesting to me, but having already waded through the issues once on my own, without some serious help resolving the legal aspect of this, the cost of entry is too high for impulse-based participation.

<comment><USER16> I'm so confused by what you're saying, do you not understand how software licensing works in regards to copyright? I thought by now its been pretty well understood by the community. The exception being obscurely licensed software.

<comment><USER15> The problem with copyright is that many of us are subject to broad agreements assigning the ownership of all our programming output to our employers. If we were to contribute to these projects without a clear legal framework in place authorizing us to do so, we open up all parties involved to significant legal risk.

If Mozilla had some kind of pre-packaged kit that we could take to our employers for approval, and that once filled out, had a clear scope of authorization, it would go a long way to giving me the courage to try walking the path to contributing again.

<comment><USER16> I'm not sure there, I see what you mean now. Thanks for the clarification. I'm not familiar with that case, maybe someone else here on HN would know. Usually most people just don't have to worry about that when contributing to open source. Also depending on the software license, it might trump the supposed claimed copyright of your employer, e.g. GPL code once GPL'd there's no going around it. Or other licenses which revoke your use of their code the second you try to sue. Software licenses are kind of smart in their own regard.

Sidenote: I personally would refuse to work for anybody who tries to own code I write outside of work with my own hardware / tools. Thankfully where I work we're very open source friendly, not only do we use open source tooling / OS' but in some cases we contribute back directly where appropriate.

<comment><USER17> Every place that I've worked at with a clause like that in the contract doesn't get to employ me until it's removed. Usually they can't understand my objections, and has just been put in there by their lawyers, but it's always come out eventually.

<comment><USER16> It just makes no sense why they add that in to begin with. Glad to know they'd take it out.

</comment></comment></comment></comment></comment></comment><comment><USER18> Anyone in SF or East Bay organizing together for this? I see a pin on the map in SF but can't tell how legit that gathering is. Is there anything happening at the Mozilla office?

<comment><USER19> I've set myself to drive down to Mozilla from SF and work on this:

[https://github.com/mozilla/global- sprint/issues/307](https://github.com/mozilla/global-sprint/issues/307)

Lots of Meetups happen at the pinned library in SF so it's likely legit.

Shameless plug: Clojure Engs wanted, esp w Reagent or at least (atom) and UI experience. Streaming video, RSS, RasPi, oh my. Just me sofar, late reg.

<comment><USER20> This and your tinydatacenter page seems great. Also I like the styling of that page :-)

</comment></comment></comment><comment><USER21> looks nice but would greatly improve chances if they had labels of what kind of help is needed

<comment><USER21> answering myself, went and read about 20 pages, they really need labels

</comment></comment><comment><USER22> One really cool project would be to make Firefox's webassembly compiler work standalone as a dynamic library. Even baseline compiler would be useful.

<comment><USER15> Do you mean the JIT compiler? If so, there has been some work fusing Eclipse OMR's JITBuilder to wabt here: [https://github.com/wasmjit-omr/wasmjit- omr](https://github.com/wasmjit-omr/wasmjit-omr)

It's probably significantly more primordial than what you want, but mentioning it on the chance it's useful.

<comment><USER22> A library with small binary size that is easy to integrate.

Supporting at least x86(-64) and ARMv7 (default + thumb2, 64-bit ARMv8 would be a big plus).

Something that would enable multi-platform plugins.</comment></comment></comment>


Solutions to reverse global warming - <AUTHOR> http://www.drawdown.org/solutions-summary-by-rank <comment><USER2> Didn't know the CFC replacements in refigeration that don't hurt the ozone layer are super greenhouse gases. [http://www.drawdown.org/solutions/materials/refrigerant- mana...](http://www.drawdown.org/solutions/materials/refrigerant-management)</comment>


Ask HN: Best ways to spread the word about your web app - <AUTHOR>

Hi everyone. I built a beautiful project and task management tool and am now struggling to spread the word about it. Would be interesting to know from who went the same path if you have any pointers for me. Seems to be incredibly hard to push through all the noise out there. <comment><USER2> Step 1: Define your customer segment. Who is hiveflux for? bootstrapped, startups, remote teams, specific industry? If you are not sure yet, look at who your competition is targeting. Niche it down. You can always expand horizontally later.

Step 2: Once you know your customer segment, change the copy on your website to drive the value proposition home for that specific segment.

Step 3: Find out where your target customers hang out. People from specific niche industries hang out at specific niche forums. Hang out at these forums and ask questions and contribute. If you are strapped for time, you could advertise directly on the forums - a lot of them allow you to open paid sales threads.

Step 4: Build a community from the early adopters you find from these forums and then get them to spread the word.

<comment><AUTHOR> Thank you for the awesome pointers :)

</comment></comment><comment><USER3> Hi. I recommend to set up proper social accounts, make them containing clean one-liner/tagline of your web app and link to the page. Then post few tweets with hashtags somehow related to the problem your product solve. Then try to follow 50-100 guys in Twitter who could be your prospectives. Try to get follow backs. Post again. Look for forums and threads where people discuss tools like yours.

To support this campaign, try to write press release and send it to bloggers and magazines popping up on your key search request, set up links with them and ask to post on some date, then buy some targeted Ads in Facebook and Google.

More aggresive you will, more prospectives you engage. The better way is to make natural links on forums and boards related to your product. Better to make it the part of viral loop or even better part of user daily workflow.

<comment><AUTHOR> Thank you for the valuable info.

</comment></comment><comment><USER4> You built a beautiful project and task management tool, make a post about it, yet fail to show us what it is (e.g. link)? That's pretty much your problem right there. You need to advertise the service.

<comment><AUTHOR> Sorry, didn't want the post to sound like an advert.

Here: wwww.hiveflux.com

</comment></comment><comment><USER5> ... link?

Word of mouth, for a quality tool, is significantly better than nothing (though probably _not_ where you should stop... others will have more ideas).

<comment><AUTHOR> www.hiveflux.com</comment></comment>


Show HN: Edit JSON in a Grid. Can handle complex objects, upload to Pastebin - <AUTHOR> https://sodeve.net/sencha/json-table-editor/ <comment><AUTHOR> Hi everyone, I made some enhancements to this 5 years old JSON editor. New feature added: \- create url shortener \- upload to hastebin, dpaste or pastebin

Please provide any feedback or any advice if you have some. Cheers!

</comment><comment><USER2> I've been looking for something like this for ages, thanks!</comment>


Show HN: Minimal Tensorflow and Syntaxnet Docker image (17x smaller than official) - <AUTHOR> https://github.com/nardeas/tensorflow-syntaxnet <comment><AUTHOR> Now included is also a DRAGNN wrapper that exposes an easy to use Python interface to SyntaxNet. Check the README to see how easy it's to get started. Comments and thoughts are welcome!</comment>


Gallery of animations that explain math ideas - <AUTHOR> https://en.wikipedia.org/wiki/User:LucasVB/Gallery and this is a killer: https://upload.wikimedia.org/wikipedia/commons/5/50/Fourier_transform_time_and_frequency_domains.gif <comment><USER2> This is incredible! Such an amazing asset for thinking. I wish we had tools like this when we were kids. Reminds me of a TEDtalk by a math teacher, Dan Meyer: [http://www.ted.com/talks/dan_meyer_math_curriculum_makeover](http://www.ted.com/talks/dan_meyer_math_curriculum_makeover)

He describes how we tend to remove all of the interesting stuff about actually solving problems- formulating questions, figuring out what framework to use, etc- and we just give people really boring questions.

> "I encourage math teachers I talk to to use multimedia, because it brings > the real world into your classroom in high resolution and full color; to > encourage student intuition for that level playing field; to ask the > shortest question you possibly can and let those more specific questions > come out in conversation; to let students build the problem, because > Einstein said so; and to finally, in total, just be less helpful, because > the textbook is helping you in all the wrong ways: It's buying you out of > your obligation, for patient problem solving and math reasoning, to be less > helpful."</comment>