Type 1 Diabetes Therapy Shows Promise for Long-Term Reversal in Humans, Dogs - <AUTHOR> https://www.eurekalert.org/pub_releases/2018-08/pu-nt1082118.php <comment><AUTHOR> Here is a link to the original, very dense study: [http://twin.sci- hub.tw/7028/b28e7f2a10ed20f118272743121ee42e...](http://twin.sci- hub.tw/7028/b28e7f2a10ed20f118272743121ee42e/stephens2018.pdf)</comment>


Need several 1 to 10 page static website? where to go? - <AUTHOR>

I'm trying to help some friends put simple personal website and looking for the most affordable solution.  Websites will be html/css only.  Anyone find a really cheap solution to 1) buy domain and 2) host?  I've seen hostgator and godaddy, but I was wondering if there are lower offers.  Thanks <comment><USER2> For cheap hosting of static sites, I'd look at either Nearly Free Speech[0] or an Amazon S3 Website Endpoint[1]. Amazon will be cheaper, but more complex to set up. Throwing $20 into a Nearly Free Speech account will probably keep your friend running for quite a long time.

[0]: <https://www.nearlyfreespeech.net/services/hosting>

[1]: [http://aws.typepad.com/aws/2011/02/host-your-static- website-...](http://aws.typepad.com/aws/2011/02/host-your-static-website-on- amazon-s3.html)

</comment><comment><USER3> check out github pages. you'll get the added benefit of version control as well.</comment>


More money than legal ability - <AUTHOR>

Hey HN.
I've gotten revenues of random iPhone and Android apps (I wont link here, but think farts) that now have earned me a considerable amount of cash.
I don't know who to turn to when it comes to financial advice. None of my friends have financial advisers, so I can't go on community suggestions. Anyone in the Califonia/Bay Area who can help me navigate this? I probably wont have this money next year, but as a crazy liberal I want to make sure I do this right (my farts can't last forever).
Any help would be excellent. Thank you for your time. <comment><USER2> Depending on the amounts you are talking about, I might not have the experience to help you. The general advice would be to park it somewhere safe for now, realize there is no rush, invest it over time rather than all at once, and find a fee-based (rather than commission-based) financial advisor to assist you.

But I would suggest that if it's money that you can potentially afford to lose, you should at least consider investing in small local companies that you enjoy patronizing. It's easier if you are an "accredited investor", but still may be possible if you are not. There's no easy way to find which businesses are seeking investment, but it never hurts to walk up and ask. There's potential for high returns, and it's certainly a lot more interesting than a mutual fund!

(My specific advice would be to find the best local sorbet shop you can and talk to the owner about investment opportunities. OK, just joking, but feel free to check my profile for contact information. I'd be happy to discuss in general how it works on the business side.)

</comment><comment><USER3> Advices from Paul Buchheit: "First, don't lose the money!"

More details in [http://paulbuchheit.blogspot.com/2010/05/what-to-do-with- you...](http://paulbuchheit.blogspot.com/2010/05/what-to-do-with-your- millions.html)</comment>


Chiming in on the MIT Scheme to Python Switch - <AUTHOR> http://benjisimon.blogspot.com/2009/05/chiming-in-on-mit-scheme-to-python.html <comment><USER2> I don't have an opinion about the Scheme -> Python switch, but I didn't find this a very compelling objection.

The author seems to assume that a CS degree is meant to teach you to write software. (E.g., "how exactly do you write software if you don't start with small working primitives (like unit tested classes, PLT scheme modules, or a PHP library script)? Isn't taking a complex problem and breaking it down into testable/reliable chunks a fundamental principal of writing software?") But who said anything about writing software? Certainly many CS grads do go on to write a fair amount of it, but it's hardly the only goal of the curriculum, especially at a place like MIT, where a CS grad is as likely to go on to a career in research as in programming.

The priorities here seem frankly bizarre; the author derides learning about "electricity whizzing through CPUs", but the principles governing how CPUs work are way more core to computer science than is unit testing, which is more of an industry best-practice than a deep principle.

Looking at it another way, a full education in CS is going to have to cover everything from processor hardware to programming techniques to theoretical foundations. Intro courses at most schools have tended to focus almost exclusively on programming. The old SICP-based intro course at MIT blended programming with a taste of theory, and the new intro course sounds like it will switch to blending programming with a taste of hardware and a crash course in real-world problems like faulty and undocumented libraries. I wouldn't say that's obviously a good move, but it's not obviously wrong, and it doesn't seem any less true to the soul of computer science.

</comment><comment><USER3> Well me personally, I love SICP, I think it's one of the most important books to read as a developer.

However, I don't think its importance can really be appreciated by a neophyte programmer. The elegant modular approach to programming that is introduced in SICP seems like too much work until you have been programming for a while using the large, buggy, mostly undocumented APIs that the working developer has to deal with. (the blog post above seems to think that these don't exist, and all I have to say is that he has either been very lucky or doesn't do a lot of coding)

I always felt a first programming course should actually teach assembly first, then C, then an OOP language like Python or Java. If you are unaware of how the higher-level languages actually get mapped into the world of pointers and registers, it's really hard to understand performance issues, and how the various higher-level languages evolved in the way that they did.

All things considered, I think most people would agree Python is easier to pick up than Scheme, especially for someone who has never programmed before. As long as they eventually do teach a purely functional language at some point and introduce the concepts of functional programming, I think this is a great change.

Surely making a robot move around is more fun than calculating the Newton- Rhasphon method? :)

<comment><USER4> Python is easier to pick up than Scheme, _except_ for someone who has never programmed before. Scheme has the simpler syntax and semantics, but Python is more likely to resemble programming they've already done.

And yes, making a robot move around is fun. SICP wasn't designed for fun. During the late '80s and early '90s it was a weeding-out course when too many people wanted to major in EECS. I thought it was fun, but a lot of people didn't.

</comment></comment><comment><USER5> Testable and reliable chunks are totally cool, but they are increasingly unrealistic and "passé". Modern systems use lots of unreliable parts which are not well defined (eg Google's server farms), and before long (especially at MIT) there will be quantum computers whose behavior will be impossible to exactly quantify or predict. Teaching students how to get real work done in these uncertain environments is definitely preparing them for real computing systems of the future.

<comment><USER6> I wonder how much of it can still be called science when all it does is with incomplete unreliable and unpredictable stuff. We can rename it "Computer Magic" or "Paracomputology"

</comment></comment><comment><USER7> Am I the only one who finds pure math more fun than programming an actual robot to move?

<comment><USER6> no.</comment></comment>


AT&T: We need to buy DirecTV because U-verse TV is a failure  - <AUTHOR> http://arstechnica.com/business/2014/06/att-we-need-to-buy-directv-because-u-verse-tv-is-a-failure/

<comment><USER2> I am a long-time DirecTV customer and regularly (monthly) get glossy mailings from AT&T promoting U-Verse with various discounts and enticing promises of high-bandwidth internet and an advanced DVR. But when I specifically explored it, I found that it wasn't available "in my area." Apparently my neighborhood in one of the most affluent zipcodes in the nation (a few blocks from the Jobs's place) is not one where AT&T has run fiber. But still, month after month, the U-Verse brochures come through the mail slot...

Tantalized beyond measure, I went to an a physical AT&T office/showroom to get f2f human verification of what att.com was telling me. Yup, true. Plus, while there, I took a few moments to flip some channels on a U-Verse monitor. Not impressed. I generously showed the salesman how on the supposedly hi-def ESPN channel, there was clear posterization of the colors of the presenter's tie and little fine detail in hair or beards -- as compared to the consistent 720p that comes down from DTV. I was convinced by this demo that AT&T had absolutely nothing to offer in the realm of TV either; after all, if they can't get a decent picture in their own showroom...

<comment><USER3> I had the same experience with the in store demo. I was blown away at how terrible the quality was.

I actually have UVerse internet (in fact I just got them to double my speed and lower my price today because I've been with them so long). My internet came with free TV for a couple months.

The quality was so terrible that I stopped watching after about an hour. Also, I think it stole my internet bandwidth when I was watching.

</comment></comment><comment><USER4> One of the reasons U-verse is a failure is that AT&T can't even figure out how to connect customers in neighborhoods it has actually wired. I have been trying to get U-verse for years, even though linemen have called the business office to confirm I can be wired. They cant figure it out. My best guess is that the maps of the physical plant are a complete mess and, at least in older neighborhoods, they can't figure out what is wired to what.

Help me Google, you're my only hope!

<comment><USER5> I had U-Verse in SF. Wildy inconsistent. Had to get a lineman multiple times, before finally one of them literally suggested for me to switch over to Xfinity.

</comment></comment><comment><USER6> How is adding about 20% to the subscriber base going to drastically put downward pressure on pricing for existing DirecTV users. Consolidation rarely helps overall pricing.

<comment><USER7> More customers allows them to negotiate better pricing with TV networks, but I guarantee none of the savings from this will be passed on to customers.

<comment><USER6> It helps the companies cost of entry, but rarely does it translate into a benefit for the consumer.

</comment></comment></comment><comment><USER8> I think it's time for Google to spin Google Fiber out to an independent company. Then wire up everywhere in the US that lacks fiber direct to the home.

This would cost tens of billions of dollars, but Google could send them with $1B seed money. Maybe some other web companies could pitch in? And I would buy bonds from these guys in a second, there should be a return here.

Let me know if I can help.

</comment><comment><USER9> I'd probably get U-Verse if they just sold me the full fiber connection without all the TV crap...

<comment><USER10> They do, but you'll be charged a $200 (or more) "installation fee" if you don't bundle TV with it. When my service was installed, the guy literally walked in, plugged the modem into the wall, and was done. However, if you do order bundled TV with it, they'll prorate the fees if you cancel it... so I ordered TV + internet, cancelled the TV the next day, and now have an internet connection only (without paying their ridiculous $200 "plug it into the wall" fee). I only bought one day of TV service (the cost of which was negligible) and dropped the cable box off at UPS.

I would be using something else if there were ANYTHING else, but my apartment complex won't let cable providers wire the place. I'm moving soon, to hopefully greener pastures.

<comment><USER11> Not necessarily. I know it's a small subsection of their potential customers, but in markets competing (or about to compete), the subscription process for UVerse's gigabit service (contractually 300Mbps until September then 1Gbps) is quite reasonable. I paid a $100 installation fee that included my first month's service, and I got a $50 Visa card for signing up. Meaning, in the end, my installation cost -$20. It's the same price as Google Fiber, but there is a 1yr contract with a decreasing cancellation fee that makes sense considering the connection process is lengthy and equipment heavy.

And, for the curious, I chose AT&T over Google because Google won't be in my neighborhood for, at the very least, 6 months. I'll take a year of AT&T until Google can get their fiber laid on my street.

Oh, and I only have their internet service. No TV. Although, the deal for that was relatively nice too ($30 a month more, free HBO/HBO-Go for 3 years, free Galaxy Tab 2).</comment></comment></comment>


On exploiting the jemalloc memory manager (2014) - <AUTHOR> http://phrack.com/issues/68/10.html#article <comment><USER2> Another fun attack vector that I don't think has been well explored yet involves the use of C++ sized deallocation functions. If a base class is missing a virtual destructor, or if an array allocated with new[] is deallocated with delete (instead of delete[]), then the allocation can be freed with an incorrect size parameter. If this happens, you can trigger some of the same sorts of state corruption issues that a double-free would cause (you set a random bitmap bit to "free" in the metadata, since you're calculating offsets from the start of a slab incorrectly).

Valgrind won't ever catch this, and Address Sanitizer won't always (it depends on both the exact type of bug, and the sanitization settings).

<comment><USER3> When in doubt just assume Mark Dowd found it first [http://taossa.com/index.php/2007/01/03/attacking-delete- and-...](http://taossa.com/index.php/2007/01/03/attacking-delete-and-delete- in-c) (dead link) but see here too [http://www.blackhat.com/presentations/bh- usa-07/Dowd_McDonal...](http://www.blackhat.com/presentations/bh- usa-07/Dowd_McDonald_and_Mehta/Whitepaper/bh- usa-07-dowd_mcdonald_and_mehta.pdf)

<comment><USER2> Oh yes; while certainly mismatched new[]/delete has been a source of problems since forever, what I mean specifically is the new types of exploits possible with the "operator delete(void* ptr, size_t sz)" overload (and its array cousin).

Before C++14, using delete (rather than delete[]) to deallocate an array of ints (or other trivially destructible data types) would be safe in practice, even though it was disallowed. In a world with sized deallocation functions, it's exploitable.</comment></comment></comment>


VW accused of ruining Mexican crops with weather-altering technology - <AUTHOR> https://money.cnn.com/2018/08/23/news/companies/vw-volkswagen-mexico-drought/index.html <comment><AUTHOR> weather altering technologies should probably be illegal in all cases... VW is particularly evil lately...</comment>


Ask HN: How to set up home wireless for reliable WFH - <AUTHOR> I have a wifi network at home, with my cable provider's highest tier of service. I have a nice wifi routers. My cable provider sometimes has outages. As with many city homes, there are many overlapping networks, and I do run into wifi issues on the other end of the home.
I'd like reliable, robust internet. Ideally, I would have:
1) Cheap cable service and some kind of cheap backup services (e.g. DSL) as a seamless fallback
2) Some kind of mesh network which covered the whole home with reliable wifi
I am interested in having a secure router, which won't get compromised tomorrow, and which firewalls the house. I am uninterested in having a cloud router, which spies on me, and sends off my internal data to Google or some company in China.
Any recommendations on how to set something like this up?
I don't need a ton of bandwidth. I do need reliable ssh connections which stay up and have low latency. <comment><USER2> Just a question: you wouldn't happen to have coaxial cable in the house, right? If so, you could use an adapter to run ethernet over it: [https://www.amazon.com/dp/B008C1JC4O/](https://www.amazon.com/dp/B008C1JC4O/)

I agree with the other poster, if you want reliability then there is no substitute for ethernet. Anything else will simply have lower reliability.

That said, I'd personally try HomePlug (ethernet over powerline) solution first. I was not able to get that stable and have tried two generations of the technology.

If it works -- fine, if not, I'd try mesh products like Eero next. They're owned by Amazon though, which I personally wouldn't like. I did hear some good reviews on the ATP.fm podcast, who usually are quite critical.

</comment><comment><USER3> > As with many city homes, there are many overlapping networks, and I do run > into wifi issues on the other end of the home.

> I'd like reliable, robust internet.

>Any recommendations on how to set something like this up?

For at least the WiFi issues, the answer is: don't use WiFi. Use Ethernet cables and you will have reliable, robust connections. Which means (exclusive of a comcast outage) "reliable ssh connections which stay up and have low latency".

> I am interested in having a secure router,

Building your own from a PC, plural ethernet cards, and Linux is one way to know exactly what the router is, and is not, doing. It is also not going to become obsolete tomorrow because the maker no longer releases firmware upgrades for it. However you are also taking on the effort of upgrading things yourself as necessary to maintain security.

<comment><AUTHOR> > For at least the WiFi issues, the answer is: don't use WiFi. Use Ethernet > cables and you will have reliable, robust connections. Which means > (exclusive of a comcast outage) "reliable ssh connections which stay up and > have low latency".

I don't think I'm allowed to punch holes in the walls as would be needed to run Ethernet.

As a point of curiosity: Typical wifi is now faster than typical ethernet. I did benchmarks. Although both my computer and router advertise gigabit, they typically negotiate to 100M. I tried swapping cables, so it's not just random cable issues. Wifi gives consistently higher speeds than ethernet. Of course, 100M is plenty, and as you point out, does give better reliability.

> However you are also taking on the effort of upgrading things yourself as > necessary to maintain security.

That's my concern. Cost of maintenance becomes astronomical. I'm not a sysadmin by trade, and I'd need to stay on top of zero-days and similar. Plug- and-forget is nice.

I'm comfortable with the middle ground of trusting the vendor, so long as they say they're not monitoring things and they're reasonably credible. Thing is, most vendors seem to advertise cell phone apps, Alexa integration, and other stuff which necessitates sending my privates all over the web.

<comment><USER4> You don't have to punch holes in walls.

Edit to clarify: most houses I've lived in, the internal doors could easily fit an Ethernet cable under them when closed. It's not pretty but if it's mostly routed along walls behind furniture you'll likely not notice it that much.

100mbit is not "typical" for new, non bargain-basement equipment in 2020.

If they aren't connecting at gigabit reliably one of the three things (router/switch, computer, Ethernet cable) either not rated for gigabit or is faulty.

I had some similar symptoms with an isp provided Huawei fttp ont+router. I ended up plugging the computer (along with a network a3 printer) into a little desktop gigabit switch and it's all been peachy since then.

The moral of the story is that isp provided devices are usually worse than bargain basement because you aren't even getting the savings.

If possible I'd either replace it, or if you're on eg docsis (aka cable) and can't find a reliable one aftermarket, put their device in bridge mode, and run a good quality router of your own.

<comment><AUTHOR> Running wires would be profoundly impractical. The home has stairs, and the whole layout is profoundly non-conducive to running wires. It'd be a massively long wire, running along floors, walls, and ceilings. Even if I decided to do that, I'm not the sole deciding party. Everyone at home needs to be happy, and I don't think anyone else would agree to that. I could do powerline or something, but I really think wifi is the way to go here.

The wifi is robust when it goes to make desktop in my bedroom, which has a PCI wireless card with a proper antenna. Where it fails are things like laptops. That's why I'm pretty sure a good mesh network would get us there.

100mbit was with Netgear+Intel equipment, and swapping several cables. I even bought a fancy new cable on Amazon, just in case that was an issue. The equipment isn't 2020, but it's definitely not bargain-basement either.

<comment><USER3> The problem with wifi, in a crowded environment, is the lost packets from the crowding. Which you allude to here:

> As with many city homes, there are many overlapping networks

Every single wifi network other than your own is a source of interference for yours, and interference impacts latency first, then when the interference gets bad enough, throughput is impacted.

You can paper over the issues with stronger signals, for a time, until the density of the surrounding networks grows (or others begin strengthening their signals because your stronger signals are now causing them excessive interference). But you can never escape the interference without moving somewhere very rural where you are the only wifi close enough to detect.

You can escape some of the wireless interference by switching to 5G wireless (much shorter range, so fewer other 5G wireless networks will be in range to cause interference and a much larger number of channels, so fewer collisions), but then you have to be operating within that shorter range of your own AP, which could again mean running some ethernet to bring the transmitters closer to where you need them to be to operate reliably.</comment></comment></comment></comment></comment>


Why does software cost so much? - <AUTHOR> https://insights.sei.cmu.edu/sei_blog/2018/04/why-does-software-cost-so-much.html <comment><USER2> Was able to get the site to load after several tries, which has led to a humorous juxtaposition with the comments here. Other commenters are saying that they know what drives software costs, and while I agree with some of the comments, there's also stark irony as the linked research is explicitly aimed at trying to debunk "gut feeling" about correlated data that leads to higher costs and discover causation data:

>> "If we want to proactively control outcomes, we would be far more effective if we knew which organizational, program, training, process, tool, and personnel factors actually caused the outcomes we care about. To know this information with any certainty, we must move beyond correlation and regression to the subject of causation. We also want to establish causation without the expense and challenge of conducting controlled experiments, the traditional approach to learning about causation within a domain. Establishing causation with observational data remains a vital need and a key technical challenge."

>> "Armed with this new approach, we are exploring causal factors driving software cost within DoD programs and systems. For example, vendor tools might identify anywhere between 25 and 45 inputs that are used to estimate software development. We believe that the great majority of these factors are not causal and thus distract program managers from identifying factors that should be controlled."

Since down, didn't read: Don't assume you know the answer. The point of the research is to prove what's actually a causal driver of costs, not just an unrelated correlation winking suggestively at it.

<comment><USER3> It does look like a really interesting avenue of research. I see a lot of statistical "evidence" presented as justifying interventions without even hesitating to consider if they've got it the wrong way around in terms of causality.

It seems it will be focused on large scale products out of necessity because of the availability of structured data and public disclosure.

There is one preliminary paper linked in the article, which I haven't read: [https://dl.acm.org/citation.cfm?id=3172876](https://dl.acm.org/citation.cfm?id=3172876)

It is really interesting to see ways to establish causality without a randomized controlled trial, since in a lot of circumstances an RCT is impossible or unethical, and because for many decision making purposes you need to evaluate interventions, not just relationships.

</comment></comment><comment><USER4> I've been experimenting with what one may call "CRUD shorthand", which is a way to define typical CRUD activities in as short a way as possible. However, changes in UI/UX expectations and/or fads generally muck up the consistency. The industry keeps reinventing the wheel such that we can't stop to master and simplify one kind of wheel: we throw it out for the Next Great Wheel and invent different ways to do the same CRUD things. Some changes are good, others are a waste and distraction. People do judge books by covers, and that costs us.

Another "problem" is that software tries to model the messy "organic" external and internal office politics, making the software messy. Either make the organization more logical, or accept messy software that tries to mirror messy human and organization relations.

<comment><USER5> CRUD alone doesn't provide much value to an average company, the real value comes from managing and automating the workflow, which is of curse the expensive part of developing software because it requires full knowledge transfer from a company that likely has never stopped to understand their process to developers that have varying grades of familiarity with the domain

<comment><USER4> I generally consider "workflow" as part of CRUD, although there are more literal interpretations of "CRUD". But changing the workflow shouldn't be that hard if the stack/tool has a standard way of configuring & managing workflows and user roles.

<comment><USER5> Workflow is usually so much more than an object state. You might have required documents or a proof of work that go in attach to the state change, some state change roles might be asymmetrical (i.e. only this role can roll back a state transfer) so permission need to be dynamic depending on object states, and then you have good ole transformative batches on top which are squisitely custom.

I mean, I know the problem quite a lot, sice one of my many backburner ideas is a workflow centric self service crud builder :D

</comment></comment></comment></comment><comment><USER6> If by "software" you mean bespoke custom software developed especially for you, the reason it's expensive is probably mostly because of bad development practices.

If by "software" you mean off-the-shelf proprietary products, the price you pay for it is entirely an arbitrary construct chosen by checking what other market players charge for similar software and seeing what buyers are prepared to pay. Absolutely no other considerations go into pricing a software product, since the software is literally free to produce, plus the cost of packaging.

(I could, for completeness, as a clarification to the latter point, mention that the cost of hiring programmers etc. _does_ enter into the equation at the _start_ of a proprietary software project, but once the cost of development has been paid, it's a sunk cost and no longer relevant for making any pricing decisions.)

See also:

[https://www.joelonsoftware.com/2004/12/15/camels-and- rubber-...](https://www.joelonsoftware.com/2004/12/15/camels-and-rubber- duckies/)

<comment><USER7> Ignoring the huge cost of R&D (the sunk cost you refer to) is disingenuous. It isn't even free to produce the copy of the software. There is marketing, bandwidth, upkeep. Maintaing backend servers and so on. I agree, for the most part the price of the software doesn't have a lot to do with the cost to develope it, but you cant ignore the R&D costs.

<comment><USER6> I'm not ignoring the R&D costs. But a sunk cost is a sunk cost¹; wanting to charge more for software because you worked hard on it is a sweat-of-the-brow argument, and it doesn't work. Nobody cares how much money was spent on the R&D which went into some software. People care about what they can _use_ it for.

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

<comment><USER8> I mostly agree with you, but to the extent that your software competes with other, similar software built by companies with similar cost structures and addressable market, the cost of that sweat factors into _their_ costs as well, so does have a (loose) connection to the viable costs for that software in the market.

</comment></comment></comment></comment><comment><USER9> Why does software cost so little?

When you look at the value created by tech, the productivity gains from buying solutions instead of rolling your own, the possibility to focus on your own competencies vs getting distracted by maintaining your own re-invention of the wheel...

Or maybe, just maybe, it is priced just right.

<comment><USER4> The buy-versus-build decision is not clear cut. Pre-packaged solutions often have a lot of "buttons" and layers that are distractions and/or extra steps that are not otherwise needed by a particular customer, and thus slow things down.

For example, a given org I once worked for had a 1-to-1 relationship between subscription user and payer (bill-to). But the pre-packaged software implemented it as a many-to-many relationship to be more flexible for different shops. One can use this to emulate a 1-to-1, but it's more layers, screens, and data tables than a dedicated 1-to-1 design. (My job was to build reports based on those data tables.)

Good home-grown software beats bad purchased software, and good purchased software beats bad home-grown software.

<comment><USER10> And what if it's a decision between both goods? Does good purchased beat good home-grown, or is that a matter of which costs more?

<comment><USER4> My point was that neither type is inherently better just by being a member of that type. The devil is in the details and both can be good or bad for a given organization or product need.

</comment></comment></comment></comment><comment><USER11> Site is down, but there a lot of things to contribute to the cost of software:

1\. Business doesn't know what they want, or can't communicate it well. 2\. Business reluctant to go with startups and rather pay out the nose for large, entrenched and very expensive companies (Oracle Applications, SAP, rent chargers, etc) 3\. Scope creep, scope changes mid development. 4\. Negative productivity developers (who make things worse) 5\. Absolutely poor hiring practices industry wide. 6\. Vendor lock in. 7\. Poor development tools and languages (weak-typed js makes refactoring 10x harder). 8\. Overburdening development processes. 9\. Inter-departmental friction for developing software. 10\. Hands off, ivory tower management. 11\. Trying to make software fit everybody. 12\. Security concerns.

These are just off the top of my head. There are many many more. Having said all that, that's why software costs what it does. As far as it being expensive, if it's more expensive than the manual way of doing it, don't buy it. If your company is competent enough to roll your own, do it. It's a hell of a lot cheaper than folders, paper and filing cabinets (just ask the VA).

<comment><USER12> I would add to the list: 13. CV driven development 14. developers with no interest in the underlying domain they are trying to solve making bad design decisions 15. excessive bureaucracy of IT department & rigid policies

<comment><USER13> "CV" as in Constant-Velocity? Sounds like an Agile concept ;)

<comment><USER14> You're probably being sarcastic but I think the parent meant Curriculum Vitae. Making technical decisions based on what will look good on your resume instead of what's the best way to solve the problem at hand.

<comment><USER15> Chicken and egg perhaps; as a Java contractor back in the day, I noticed the eventual creep of Ruby on Rails stealing some of it's limelight, then JavaScript or whatever the new hotness became (not saying JavaScript is in any way hot there).

As a contractor, I was compelled to learn those technologies because the companies were demanding these skills, not because I had a desire to learn another scripting language or whatever. Of course, it's often (senior) developers within the company that push the new, less-well-travelled technologies and the cycle repeats.

I guess the lesson is, don't let frontend developers dictate that JavaScript should be on the server, or is in fact a good language for desktop apps and so on.

</comment></comment></comment></comment></comment><comment><USER16> Answers:

Because it costs so much to make.

Because it has, in some cases, a measurable benefit in productivity, and is being priced accordingly.

Because it's something that's still relatively new, and like anything else, things slowly get cheaper as time goes on, but start out priced decently high.

<comment><USER17> Because 'big ball of mud' is the most common system architecture.

<comment><USER18> I love PG's description of development in the Python Paradox: "You push blobs of source code around the way a sculptor does blobs of clay."

[http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)

<comment><USER19> > people don't learn Python because it will get them a job

Maybe not in 2004.

</comment></comment></comment></comment><comment><USER20> We have a piece of software for handling child cases in the public sector in Denmark. It cost around 100 million Danish KR to develop, it's up for renewal, and because the old system was build on mainframe tech that nobody wants, it's up for a do over. The new bid was for something around 120 million DKR. Software is called DUBU if anyone wants to google the exact figures or want to know more.

Around 30 municipalities run a record keeping ESDH software called SBSYS. It's not open source but it's owned by the muniplacities who hire private companies to maintain and develop the code.

A couple of years ago they decided to build a DUBU like module, which cost them around half a million DKR, and it operates so well that it's managed to replace DUBU without any ill effects in our third largest city.

Now, the base of SBSYS provided a nice base to save documents, but I simply can't imagine what those 119 million are paying for. If you need 119 million to classify and save documents on cases in a database you probably shouldn't be developing software - yet one of our most prestigious software houses won the contract.

Honestly it looks like theft of tax payer money that is possible because the deciding politicians aren't tech savvy enough to know when they are being ripped off. Especially because it's likely to be both delayed and have it's costs increased before it's implemented, at least if it follows the trend of most our major software projects (including SBSYS).

Obviously I can't be as blunt in my professional life, and I haven't actually seen the deal and I am speculating, but it just seem off.

</comment><comment><USER21> I have worked on software in domains including DARPA, defense, and robotics, among others. While I agree with many of the things said here, from my experience, the single biggest factor affecting the cost of software is complexity.

When I say complexity, I don't mean the kind that is inherent to the problem being solved. What I mean is synthetic complexity; that is, complexity that is artificially and unintentionally introduced by the solution.

This kind of complexity is common in software and usually stems from 1) poorly defined or rapidly changing requirements, 2) technical incompetence, 3) lack of technical oversight, code review and feedback loops, or 4) mismanagement of technical debt.

The larger problem is that the aforementioned problems, in concert, are corrosive and toxic to the culture of the work, and that in turn becomes its own cost factor in terms of the care and feeding of teams.

The largest problem is the realization that the factors I've enumerated here are clearly observable while being difficult if not impossible to measure. Cyclomatic complexity scores will tell you that you've got complexity issues, but not that you've reimplemented half of the standard library badly. Thus, these factors are among the reasons that software remains as much art as science.

</comment><comment><USER22> Too much complexity, too many coders, too much code.

Too little restraint.

<comment><USER19> Hm - software costs a lot because programmers are hard to find, and it takes a long time even once you've found them. Even now, more than 30 years after it was pretty commonplace for an individual to have their own computer, programming continues to be difficult to learn and master - there's a whole cottage industry of people who insist that this is some form of "gatekeeping" on the part of the programmers and that programming is really easy, but programmers are conspiring to make it seem harder than it really is. Their attempts to "simplify" programming (usually with something along the lines of a drag-and-drop GUI flowchart builder) end up being unmaintainable, unworkable, hideously expensive, and extraordinarily popular with the people who believe that they stand to profit if programming can just be reduced to (as they're positive it really is) a minimum-wage burger-flipper type McJob. But even when they finally get around to swallowing the bitter pill that programming needs to be done by programmers if you want the programs to work, it continues to take a long time to produce because the same people who are absolutely convinced that programming computers is as simple as tying one's shoelaces make a career of putting up roadblocks in the name of "efficiency" that have the exact opposite effect, slowing down the whole process to a snail's pace as the individual programmers are expected to predict the future and state precisely what they're going to do and how long it's going to take, sometimes months in advance. The result is that nothing gets done _except_ for the stuff that's trivially predictable.

</comment></comment><comment><USER23> An approach I'm finding of interest to goods and services with long-term price trends (increasing or decreasing) is to focus not merely on the supply-side dynamics, SLOC or COCOMO models, for example, but on demand side.

Software costs are increasing because the market (or government contract purchases) exhibit a willingness to pay. _If_ markets are efficient, rational, and accurate,[1] then this suggests that prices rise due to use value available to be captured by the expense.

And if not, this suggests specific market pathologies, particularly around the realm of information, systems, complexity, and risk.

A discussion of which I'd be very interested in seeing out of CMU and SEI, who seem not to have moved much from when I was first researching software development methodologies and failures in the early 1990s.

There's also the success (and failures) of nonproprietary software development, particularly the Free Software world. Excellent for infrastructure, less so for GUI applications and specific high-touch business solutions, though the infrastructure components frequently comprise major elements of same.

________________________________

Notes:

1\. Assumptions I do not as a general rule hold, thogh I'm entertaining them here.

</comment><comment><USER24> Or so little, with regard to apps.

Many consumers scoff at spending $5, or even $1, on an app, but they'll willingly blow it on a drink that will be consumed in 10 minutes.

<comment><USER25> Consuming a drink is a social act (i.e. you do it among other people, who notice that fact). We're social creatures who are wired to value such acts highly.

<comment><USER26> Replace social drinking with impulse buys in shops.

</comment></comment></comment><comment><USER27> The developer needs to make enough profit/free cash flow/etc to build the next version. So it's essentially a bet on the expected lifespan of the current version. Which is why if someone is offering something for free, forever, or very cheap, forever, you can bet that they are fairly certain they will never be displaced.

<comment><USER28> Not always there is a period where new services are offered for free only to trap you into paying more later.

<comment><USER29> There's a literature about switching costs. One result suggests that the present value (technical term) of the customer to the company is equal to the cost of switching away, under certain assumptions. Obviously this formula is unhelpful/infinite in the case of total lock-in. I guess a good capitalist charges what the customer can bear, in that case.

<comment><USER27> Agreed. To this I'd add that the switching cost is highly dependent on perception. Costs are almost always as much about perception as they are about reality.

<comment><USER29> Hmmm, I guess if one has any alternatives at all, your evaluation of their desirability is going to be subjective. Including in the case of "offers one can't refuse". But, when are our evaluations not subjective? That is the human condition.

</comment></comment></comment></comment></comment><comment><USER30> A cursory examination of the article seems to indicate that it is the DoD who finds software to cost so much. Maybe it is not that software costs so much, but that your procurement process is broken when it comes to software?

</comment><comment><USER31> The page won't load, but in my experience the initial development costs aren't usually that bad. The cost to maintain, make bug fixes, and improvements is where everything starts to explode in cost.

</comment><comment><USER32> One reason is developer time. A common contributor to that is poor documentation. Sparse, vague, and unclear documentation. Verbose documentation that explains too much theory without actually telling you what you want to know. Copious amounts of simple examples, but no intermediate or advanced examples.

</comment><comment><USER33> Undervalued refactoring/modernization of legacy code, not necessarily implementing a whole new stack. Just paying technical debt.

But some think that if you stop providing features or fixes at the fastest pace possible or if you stop to refactor you're just wasting time or slacking off.

</comment><comment> gm-conspiracy Why do movies cost so much to make?

<comment><USER34> Thanks to digital, it's substantially cheaper to make a movie today than it was just 10 or 15 years ago. From the film and cameras to the editing process to the effects to the distribution. Distribution is now actually risk-free -- just upload to YouTube if that's what it takes. Probably the only thing that hasn't changed is how much lenses and actors cost.

And we got the added bonus of removing nasty chemical film process from our lives!

So why are movie budgets higher? It's gotten so easy to make high quality content and distribute it that you have to out-spend/out-spectacle the others. Netflix, HBO, 400 hours of Youtube uploaded per minute is what you're competing against!

Software has a lot of similarities. There are a million apps in the app store. Cow Clicker won't get it done anymore. So while it's gotten cheaper and easier, there is more competition. This requires people to attempt larger/more difficult/less-well-defined things than before. This is true in consumer and business software.

</comment></comment><comment><USER35> Link to the MOOC: [http://oli.cmu.edu/courses/all-oli-courses/causal- statistica...](http://oli.cmu.edu/courses/all-oli-courses/causal-statistical- reasoning/)

</comment><comment><USER36> Because it requires developers who inherently need to have fairly decent academic qualifications (though not always) but often food maths, which costs in terms of bigger salaries

<comment><USER36> Good maths _

</comment></comment><comment><USER37> Depends on what you mean by software. Think spreadsheets, Google forms, Trello, Slacketc. What remains is special requirements.

</comment><comment><USER38> tl;dr: Because hardware in all industries is made by poor third world slaves earning pennies per hour, and software is made by rich white Americans, mostly, and other western nations (you matter too!).

:)</comment>


Guardian Truncation Team - <AUTHOR> http://guardiantruncationteam.tumblr.com/

<comment><AUTHOR> funny site, real issue: how to deal with headlines on mobile / responsive devices?</comment>


Defunct Soviet reconnaissance satellite may hit Earth today - <AUTHOR> http://www.n2yo.com/?s=12054

<comment><USER2> The site now has an infobox stating "It has been reported that COSMOS 1220 has reentered the atmospehere [sic]".

No other reports that I can find, but this site[1] seems to have a lot of good info. Oddly, I get a completely different orbital inclination when I click on "To see where this object is expected to fall click here." (and, rather alarmingly, an impact site next to me) The main page and NORAD both agree however that it's currently still in orbit and currently somewhere around Cape Horn.

It's hard to tell whether a particular map is using live data or extrapolating a stable trajectory. At this point I imagine there'd be a large discrepancy.

[1][http://www.satview.org/decay.php](http://www.satview.org/decay.php)

<comment><USER3> Here's the forecast:

[http://www.satview.org/spacejunk.php?sat_id=12054U](http://www.satview.org/spacejunk.php?sat_id=12054U)

</comment></comment><comment><USER4> Well, that's the ISS. Here's the link to the ACTUAL decayed satellite (COSMOS 1220): [http://www.n2yo.com/satellite/?s=12054](http://www.n2yo.com/satellite/?s=12054)

<comment><AUTHOR> Yes - same satellite number, your link includes the word "satellite," and it appears that the site defaults to the space station if you do something wrong, with no indication.

Very helpful.

The site also thinks it's now decayed or re-entered and no longer actually plots the track. Which is a shame.

</comment></comment><comment><USER5> The link leads to a page that tracks the international space station. As far as I know, it's not going to come down for years, if not decades...

</comment><comment><USER6> [http://www.satview.org/?sat_id=12054U](http://www.satview.org/?sat_id=12054U)

</comment><comment><USER7> Do we know where is it gonna to crash?

<comment><USER8> In a general sense, no. However once its orbit decays to the point where friction with the upper atmosphere can impart a couple of kilonewtons of delta-v you can then create a probability ellipse and lay that on the globe. One of the interesting confounding factors is how much "side" force (perpindicular to the orbit) is created by the various parts sticking out burning up. A satellite where its appendages burn off cleanly quickly becomes ballistic and its impact point is fairly tightly constrained, one which still has onboard propellant will sometimes get a kick in some random direction by that tank exploding, and satellites which, in their deployment configuration, are prone to spinning, can be spun by atmospheric re-entry to the point where they are ripped apart by the centripetal forces generated. But even in that case, the things that are likely to make it all the way to the ground (like tungsten fuel tanks) are pretty small and constrained again by the ballistic footprint from where it started.

From a pure statistics point of view you can say "in the water" and be more likely correct than incorrect. If that helps.

</comment></comment><comment> daniel-cussen It's just taking a close-up.

</comment><comment><USER9> Here is the last spot tracked: [http://www.satflare.com/track.asp?q=12054](http://www.satflare.com/track.asp?q=12054)

<comment><USER10> So Saudi Arabia? Edit: Or Europe or the South Pacific depending on which website and where I click.</comment></comment>


Which Price Will Win This A/B Test? - <AUTHOR> https://common-form.com/blog/price-will-win-test/

<comment><USER2> I'd guess that the lowest one wins.

</comment><comment><AUTHOR> We're running out first A/B price test. I'd love the feedback of this community.

Obviously getting price dialed in is critical for any business, but it is even more so for us, a highly seasonal business with declining margins.</comment>


From 0 to 2 Million DAU's: The Guide To Growing Your Startup via Partnerships - <AUTHOR> http://brianbalfour.com/post/60293339476/complete-guide-growing-consumer-startup-partnerships

<comment><USER2> I tend to think that partnerships are more successful at fulfilling demand than creating it. Big Co's often have a hard time seeing the need at first. Just my 2 cents. [http://robkornblum.wordpress.com/2012/10/19/early-stage- busi...](http://robkornblum.wordpress.com/2012/10/19/early-stage-business- development/)

</comment><comment><USER3> Theoretically the best way to scaling a startup, but unless you are YC funded and Techcrunch AND NYT and other similar hyped, dont expect any success with this. You have to bring a critical mass to the table, 0 -2million improbable but more likely can we say 30k-5,000,000 is very possible

</comment><comment><USER4> Do you have any other examples of sizing up a potential partner before reaching out to them? If certain metrics are confidential, it seems like it's not as straightforward.

<comment><USER5> There are all the obvious public metrics from things like Compete, Alexa, app rankings, twitter following, facebook following, etc etc.

But beyond that I would dig deep into using the product. If I was going to assess the engagement (DAU/MAU) of a social network I would look at how people are commenting. Or maybe send 20 friend requests/messages to random people and see how fast on average they respond. You can get a feel for certain things just by using the product.

Otherwise I would just reach out and start a discussion. Some partners will be shy to give up metrics, but you usually can pull it out of them over time.

</comment></comment><comment><USER6> Hey Brian, of the partnerships you mentioned, or any others, what is a good example of a deal that killed it for both parties? Any 1+1 = 10 kind of deals come to mind?

<comment><USER5> Good question. Not to be a pessimist, but in most scenarios I have found partnerships to under perform initial expectations. Part of that can be mitigated with the things I outline in the post. But I think more than anything finding that one key predictor of success is important. For Viximo it was sites that had high DAU/MAU ratio. We'd rather take a company with 1/10 of the total audience, a crappier experience, and worse business terms but a high DAU/MAU ratio. It made a huge difference.

But that key predictor is different for every business. Finding it can be tough. But once you find it you increase partnership success chances by a lot.</comment></comment>


NSA mass surveillance so overwhelmed with data, it's useless, says whistleblower - <AUTHOR> http://www.zdnet.com/article/nsa-whistleblower-overwhelmed-with-data-ineffective/ <comment><USER2> The NSA is a disgrace. Budget: [classified]. Number of employees: [classified]. Accountability: only being provided by whistleblowers who are risking their freedom by exposing the actions of the organization. I will never understand why abolishing the NSA is not a talking point during this election race.

<comment><USER3> > _I will never understand why abolishing the NSA is not a talking point > during this election race._

That's an awfully defeatist attitude.

<comment><AUTHOR> I'll vote for the guy who puts a nail in NSA

</comment></comment></comment><comment><USER4> Evil but dumb. I guess we can all breathe a collective sigh of relieve.</comment>


Apache Geode (incubating) first ASF release is out: grab it while supplies last - <AUTHOR> http://geode.incubator.apache.org/releases/ <comment><USER2> I am looking at Geode to replace our Cassandra test cluster. Is Geode good for a Time series usecase ?

Do you have a roadmap/ ETA ? for the 1.0 GA. Any good architecture documentation & how to guide for Java ?

</comment><comment><USER3> Here are some presentations explain the technology: [http://www.slideshare.net/apachegeode](http://www.slideshare.net/apachegeode)

</comment><comment><AUTHOR> If you need ideas on what you can do with Geode, here's a few of our past hackathons [http://ambitious-apps.devpost.com/](http://ambitious- apps.devpost.com/)

</comment><comment><USER4> Awesome news! In case you don't know - this is the technology that first started as GemFire, the in-memory data grid.

</comment><comment><USER5> When would I use this vs kudu?

<comment><AUTHOR> Geode is orthogonal to Kudu, here's the IoT'ish like architecture diagram that can help understand where Geode fits a little bit better [http://pivotal-open- source-hub.github.io/StockInference-Spar...](http://pivotal-open-source- hub.github.io/StockInference-Spark/)

</comment></comment><comment><USER6> great product running in many organizations, this is an excellent development

</comment><comment><USER6> great product that is running in production in many organizations

</comment><comment><USER7> Nice!

</comment><comment><USER8> woot woot!</comment>


TumblrArchiver: Hacky Clojure program to download media from tumblr liked posts - <AUTHOR> https://github.com/aphyr/tumblr-archiver <comment><USER2> TumblThree is also a decent tool (Windows-only):

[https://github.com/johanneszab/TumblThree](https://github.com/johanneszab/TumblThree)</comment>


The story of ISPC: origins (part 1) - <AUTHOR> https://pharr.org/matt/blog/2018/04/18/ispc-origins.html <comment><USER2> Whoever wrote ISPC "gets it", that SIMD lanes can be treated as if they were threads. You almost have to program in OpenCL or CUDA before you realize that SIMD code can be like normal serial code (with just a few, really really weird performance quirks).

I haven't really been able to use ISPC myself yet, but its on my to-do list. I've found that a lot of code fails to run well on a GPU and still needs a normal CPU for computation... but some SIMD bits here and there can really benefit from a higher-level language (rather that writing in intrinsics or relying on auto-vectorizers).

GPUs are still very far away from the CPU. You gotta push your data to RAM, then over a PCIe lanes... and spend many microseconds to miliseconds pushing the data to-and-from the GPU. While SIMD on a CPU benefits from L1 cache locality.

Intrinsics definitely work, but are hard to program. Auto-vectorizers don't really structure the program correctly... and require a ton of study to use correctly.

ISPC seems like the real way to get well-"threaded" SIMD code written productively for CPUs. It hides things behind relatively easy to understand abstractions and is the best 'CUDA / OpenCL for the CPU' I've found so far.

\</comment><comment>---

Why not use CUDA? Well, CUDA doesn't share L1 cache with my CPU cores. That's why. You can't beat AVX in terms of latency. CUDA / NVidia GPUs are way faster, but you have to spend a LOT of time transferring data before CUDA code even begins to compute.

In contrast, ispc compiles to a .o that links into your standard C or C++ code you've been writing.

<comment><USER3> SIMD lanes can absolutely not be treated as threads. Not only can they not diverge in the instructions they execute (obviously) they can't efficiently load from different addresses (gather) or write to different addresses (scatter) on AVX.

Thinking of SIMD lanes as threads is not likely to be a path that pays off.

<comment><USER2> Performance wise, you are correct.

But from a programming point of view, CUDA and OpenCL PROVE that you can use SIMD-cores as if they were a bunch of threads. Yes, there is a performance penalty (an exponentially increasing penalty) on every thread divergence. However, a HUGE set of problems (Deep learning, matrix multiplication, graphics, ray-tracing, encoding, databases: Join-Merge, Join-Hash, etc. etc. ) which have successfully been implemented as "SIMD as if it were threads".

How to deal with divergence? Just don't use if-statements! If you can figure out how to cheat if-statements out of your code (or to group "threads" so that they take if-statements all together at the same time), you get HUGE performance on these architectures. And GPU programmers have consistently found more and more ways to "reconverge" threads so that they can be "ganged up" as SIMD-threads in the most efficient manner possible.

No, it doesn't work for Chess or other "innately divergent" problems. It doesn't work for many problems. But this "gang up SIMD into threads" works very well for many, many problems. And its easy to do.

Case in point: Ray-tracing. Every ray starts off as a camera-ray, but then when it hits an object, it may turn into a diffuse, specular, or sub-surface scattering ray (or many other types, depending on what object you hit). Seems like we have to use an if-statement to continue...

But that's wrong! Raytracing becomes GPU-friendly by grouping all specular- rays together, and computing SIMD-gangs on all specular-rays. Then, group all diffuse-rays together, and gang up the threads across those. Etc. etc.

Specular rays may bounce off and turn into Diffuse, specular, Sub-surface, or other kinds of rays on each bounce. But just "re-configure" the SIMD-gang on each bounce, and you get huge SIMD-based-benefits.

Again: get rid of your if-statements, and you scale. I admit it doesn't work all the time, but it does work a LOT of the time.

> Thinking of SIMD lanes as threads is not likely to be a path that pays off.

Every supercomputer that is buying a V100 disagrees with you (ie: Summit). There are plenty of useful problems that work under the SIMD-as-threads model.

[https://en.wikipedia.org/wiki/Summit_(supercomputer)](https://en.wikipedia.org/wiki/Summit_\(supercomputer\))

We're talking $325 million into a NVidia V100-based supercomputer. It seems like Oak Ridge National Laboratory believes in this methodology.

> they can't efficiently load from different addresses (gather) or write to > different addresses (scatter) on AVX.

AVX2 has Gather instructions. While Scatter instructions were added to AVX512.

See AVX2 instruction: VPGATHERDD

<comment><USER3> > But from a programming point of view, CUDA and OpenCL PROVE that you can use > SIMD-cores as if they were a bunch of threads.

This is nonsense - to beat a CPU you have understand that you can't have every thread doing something different.

> How to deal with divergence? Just don't use if-statements!

Individual threads don't have to avoid if statements. Trying to group threads and SIMD lanes together, only to make all sorts of concessions as to how they are different is silly an counter productive.

> We're talking $325 million into a NVidia V100-based supercomputer. It seems > like Oak Ridge National Laboratory believes in this methodology.

Just because they are using recent GPUs doesn't mean they 'treat SIMD lanes as threads'. It just is not correct to say 'SIMD lanes are just like threads except you can't diverge, you have to run the same instruction, it's better if you don't load from different memory addresses and any non-trivial branching kills performance, including looping a different number of times on different cores'

</comment></comment></comment></comment><comment><USER4> Even if you don't care about ispc, the description of Intel's culture might be interesting.

<comment><USER5> By all the reports, it seems really astonishing that Intel ever manage to ship anything.

The subtext might be that Intel upper management's main job is to kill projects that might distract from things that absolutely must ship. And, maybe the wholesale killing frequently gores stuff that succeeds in shipping despite all.

<comment><USER6> Isn't this basically every company larger than a few 100 workers? The top chooses some random direction, the middle managers feuds, and the bottom does some work wich gets thrown away half the time. Even so, these orgs are so big they dominate their industry despite all this.

</comment></comment></comment><comment><AUTHOR> Link to all posts: [https://pharr.org/matt/blog/2018/04/30/ispc- all.html](https://pharr.org/matt/blog/2018/04/30/ispc-all.html)</comment>


Ask HW: What Is the Sunway SW26010 260C CPU in China's New Super Computer? - <AUTHOR> <comment><USER2> Read this - pretty much the best explanation I've found.

From google translate: 作者:秦楚戈 链接:[https://www.zhihu.com/question/47628487/answer/107866295](https://www.zhihu.com/question/47628487/answer/107866295) 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Mentioned above by employing CPU + Accelerator way for heterogeneous computing, only use a CPU was homogenous computing. But Shen Wei 26010 seemed more special, if you define isomorphic calculated using the calculation method to calculate the same type instruction set and architecture units system, then, since the light divinity Taihu Lake using only Shen Wei 26010, and computing core and management of the core instruction set are the same, may be considered homogenous computing.

But in fact, divinity Taihu double precision floating point peak light up 125PFlops, stable performance 93PFlops, is indeed high-performance accelerators was made - essentially, Shen Wei is a 26010 CPU and accelerators combined - Shin 260 Granville 26010 core is divided into two kinds, one is the management of the core, play a similar CPU function, the other is the core operations, play a similar role in the accelerator, which makes Shen Wei 26010 single chip to complete the Intel E5 + PHI or Power + Tesla two products function.

And with respect to Intel E5 + PHI, or Power + Tesla, Shen Wei 26010 can be shared memory, which avoids the Intel E5 + explicit copy PHI, or Power + Tesla must face, thereby reducing the pressure on the memory, and reduces the performance loss.

Presumably, too, Shen Wei 26010 cache and memory are obviously too small, because memory access model may be very simple - it is tantamount to abandonment complex memory management model existing cpu and memory scheduling the task entirely to the developers, only CPU supports a simple memory access model, the hardware does not cache the conformance requirements of hardware (Intel KNL the cache consistency referred hardware), will work to synchronize software.

This unusual design makes Shen Wei 26010 at the same time have high performance and low power consumption to make up their own short board memory.

</comment><comment><AUTHOR> I can not find anything about it:

[https://www.google.ca/search?q=Sunway+SW26010+260C](https://www.google.ca/search?q=Sunway+SW26010+260C)

Would love to know if people can use this CPU rather than Intel's incredibly expensive Xeon CPUs for high intensity compute. What is the Sunway's instruction set? What are its OSes? If there is a low cost high performnce competitor to Xeons, it could really change the serve landscape.</comment>


Dueling Rhetoric of Clojure and Haskell - <AUTHOR> http://tech.frontrowed.com/2017/11/01/rhetoric-of-clojure-and-haskell/ <comment><USER2> The dueling rhetoric is the same rhetoric that has been around for decades: Some people really feel type systems add value; others, feel it's a ball and chain. So which is it? The answer is probably "yes." We should all believe by now since history has proven this correct. Most of the time you start with no type system for speed. Then you start adding weird checks and hacks (here's lookin' at you clojure.spec). Then you rewrite with a type system.

I'm a devout Clojure developer. I think it delivers on the promises he outlines in his talk, but I also have no small appreciation for Haskell as an outrageously powerful language. Everyone robs from Haskell for their new shiny language, as they should. Unfortunately, not a night goes by where I don't ask God to make me smart enough to understand how a statement like "a monad is just a monoid in the category of endofunctors" can radically change how I implement marginably scalable applications that serve up JSON over REST. Clojure talks to me as if I were a child.

Rich Hickey is selling the case for Clojure, like any person who wants his or her language used should do. His arguments are mostly rational, but also a question of taste, which I feel is admitted. As for this writer, I'm glad he ends it by saying it isn't a flame war. If I had to go to war alongside another group of devs, it would almost certainly be Haskell devs.

<comment><USER3> The fact that Haskell is smarter than me is exactly why I have been keeping at it!

There is no fun left if you know all the overarching principles of a language, and you realize it still doesn't solve your problem. This happened to me when learning Python, this is also why I don't really look at Go or Rust. They're good languages, I might use them at a workplace someday, but you can get to the end of their semantics, but be still left with the feeling that it's not enough.

(EDIT: minor wording improvement)

<comment><USER4> I love how I just keep learning Haskell, and keep improving, despite how much I already did it.

That said, Python is also smarter than me. The possibilities with monkey patching and duck typing are endless. But differently from Haskell, Python is not a good teacher, so I tend to only create messes when I go out of the way exploring them.

<comment><USER5> > That said, Python is also smarter than me. The possibilities with monkey > patching and duck typing are endless.

Don't do it, 99.9% of the time. It's that simple.

There is seldom a reason to use more than just defs - and a little syntactic sugar (like list comprehensions) just to keep it readable.

Even the use of classes is typically bad idea (if I do say so). Just because: there is no advantage to using it, except when everything is super dynamic. And if that's the case, I suggest that's a smell, indicating that one is trying to do to many things at once, not properly knowing the data.

Nevertheless using classes (or any other superfluous feature) makes everything more complicated (less consistent - need new ways to structure the program, new criterions whether to go for a class or not to or where to bolt methods on,...).

Don't use "mechanisms" like monkey patching just because they exist. They are actually not mechanisms - just curiosities arising from an implementation detail. The original goal is simplicity: Make everything be represented as a dict (in the case of python)

> The possibilities with monkey patching and duck typing are endless.

I think there are many more "obvious" ways to do things in Haskell than in Python just because you as a developer need to draw the line between static and dynamic. And if you later notice that you chose the line wrong, you have to rewrite everything.

In Python - or any other simple language - there is typically one obvious way to do things. At least to me.

<comment><USER6> Classes definitely give you a lot of rope to hang yourself with (metaclasses, inheritance, MULTIPLE inheritance), but they have their place. I'll usually start with a function, but when it gets too big, you need to split it up. Sometimes helper functions is enough, but sometimes you have a lot of state that you need to keep track of. If the options are passing around a __kwargs dictionary, and storing all that state on the class, I know which I 'd pick.

You can memoize methods to the instance to get lazy evaluation, properties can be explicitly defined up-front, and the fact that everything is namespaced is nice. You can also make judicious use of @staticmethod to write functional code whenever possible.

<comment><USER5> You can always opt for explicit dict passing. You are right that it's more typing work (and one can get it wrong...), but the resulting complexity is constant in the sense that it is obvious upfront, never growing, not dependent on other factors like number of dependencies etc.

When opting for explicit, complexity is not hidden and functions are not needlessly coupled to actual data. Personally I'm much more productive this way. Also because it makes me think through properly so I usually end up not needing a dict at all.

Regarding namespacing, python modules act as namespaces already. Also manual namespacing (namespacename+underscore) is not that bad, and technically avoids an indirection. I'm really a C programmer, and there I have to prefix manually and that's not a problem.

</comment></comment></comment></comment></comment></comment><comment><USER7> > Much of the rhetoric that is currently flying around is a false dichotomy.

The author here is missing the rhetoric. The rhetoric is not about the programming language but about how we should be doing information processing. Except that the author _isn 't_ missing that point:

> In Haskell we typically "concrete" data with record types, but we don't have > to.

Great. That _is_ the dichotomy. And it's not a "false" one. This is the question: should we be "concreting"? That's the whole dichotomy/point that is being made. By encoding EDN/Clojure in Haskell the author has gone through a cute intellectual puzzle but hasn't contributed to the crux of the discussion. (Indeed, he's tried to dismiss it as "false".)

The ergonomics that he ends up with are fairly lean (at least in the examples he's shown), though the Clojure expressions are a little leaner. But that's probably because Clojure has actually taken a stance/belief/opinion on the very real question/dichotomy at hand.

<comment><USER8> It's a little bit more than just a cute intellectual puzzle. One could build an efficient EDN library based on that or very similar type. See Haskell's JSON library:

[https://github.com/bos/aeson/blob/master/Data/Aeson/Types/In...](https://github.com/bos/aeson/blob/master/Data/Aeson/Types/Internal.hs#L342)

> though the Clojure expressions are a little leaner

Yes they are. The price is complete lack of type safety. And the benefit is an insignificantly small reduction in boilerplate code.

The number of bugs I've seen where somebody would "get" a number that turned out to be a string or string that turned out to be a number...

<comment><USER9> EDN is not JSON. EDN is Extensible. OP has everyone in this thread arguing about a strawman.

<comment><USER10> Then I think you're really going to need to educate us about what EDN really is ...

<comment><USER11> Educate yourselves. [https://github.com/edn- format/edn/blob/master/README.md#tagg...](https://github.com/edn- format/edn/blob/master/README.md#tagged-elements)

<comment><USER10> > edn supports extensibility through a simple mechanism. # followed > immediately by a symbol starting with an alphabetic character indicates that > that symbol is a tag

OK, so it's trivial to add that as a constructor to the Haskell EDN type in the post, and you can even support it in JSON with a dictionary like

        #myapp/Person {:first "Fred" :last "Mertz"}

is represented as

        {"#myapp/Person" : { "first" : "Fred", "last" : "Mertz" } }

What are the remaining objections?

<comment><USER9> EDN is much more like XML than it is JSON.

1) When I read #uri "[http://google.com"](http://google.com") my app code sees (java.net.URI. "[http://google.com"](http://google.com")), not Tag "URI" "[http://google.com"](http://google.com") or whatever. clojure.core/map does not see tagged values, it does not know that the values were ever read from edn.

2) Extension happens in userland library code, you don't need to go modify the hardcoded pattern match in core. (Talking about reifying actual instances that we can code to, not reader tags)

3) Data is just information. Information isn't coupled to code, it's abstract values, totally separate from the concrete implementation. As RH says: "code is data. But data is not code until you define a language around it." Typeclasses are about code.

4) EDN values are cross platform and a platform's EDN reader can reify the value into an idiomatic type for that platform. E.g. a haskell edn reader could reify #error "foo" into Left String; a Java reader a Throwable to be re- thrown later.

5) The whole prism diversion is sophomoric. Once you've read the EDN into concrete values of whatever platform type, you can use whatever platform abstractions you like to manipulate them. Clojure has lenses too: [http://funcool.github.io/lentes/latest/#composition](http://funcool.github.io/lentes/latest/#composition)

You can watch the EDN talk or read the transcript if you'd like to learn more. This topic is very deep but this thread is not doing it justice.

<comment><USER10> I think it would be a great service if someone would write up a technical introduction to this for non-Clojurists. You seem to be communicating a subtle point that not many of us are getting ...

<comment><USER9> Just wrote this in r/clojure hth [https://www.reddit.com/r/Clojure/comments/7a4qxp/dueling_rhe...](https://www.reddit.com/r/Clojure/comments/7a4qxp/dueling_rhetoric_of_clojure_and_haskell/dp8m4fk/?context=1)

RH already gave a great nontechnical introduction in the EDN talk in 2012, I linked you a transcription of it upthread

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Watching Hickey's talk, many of the complaints seemed to be valuable, _but they didnt seem to be about static types_. Rather, it was about some problems with existing data types locking one into a rigid data model when the domain is constantly expanding.

This post by DeGoes makes the same point. [http://degoes.net/articles/kill- data](http://degoes.net/articles/kill-data)

The default model of algebraic data types is too inflexible.

There are different extensions which work with this issue. Good record system, Extensible cases, using free monads etc. We can have concise syntax for automatically declaring an interface for a algebraic data type based on some field values (ie, customizable deriving statements). Namespace qualified keywords, so we have rdf like attribute based semantics.

The post doesnt respond to the issue but suggests that if you want to do the same thing in clojure with error handling etc, you will need to think about this stuff.

Also, Hickey's mention of Monads was again not about static types. Monad laws are not typechecked. Their motivation is purity. The only slight inconvenience in a dynamic context is that you dont have return type polymorphism, so you have to type IOreturn instead of return.

<comment><USER10> > [Monad's] motivation is purity.

This is not true and it's important to clear up this misconception lest anyone thing "the only good reason to use monads in Haskell is because it's a pure language".

* The use of monads in functional programming arose purely technically as an innovation in denotational semantics

* Then someone noticed you could use it to wrap up IO purely in Haskell

* Then it was noticed you could use it for _all sorts of other stuff_ besides dealing with IO in a pure language.

Monads are only a little bit related to purity.

<comment><USER12> Yes, sure, monads, applicatives etc. have plenty of applications beyond IO, which is part of why keeping that abstraction separate from any particular use is of value.

My point is that this doesnt have much to do with static typing vs dynamic typing per se, as we dont check them statically. They are just important examples of an interface with implementations for many data types, which can be useful even in a dynamic language like Clojure. People who write a parser in a dynamic language might benefit from learning about distinction between applicatives and monads.

<comment><USER10> Yes I agree. I just wanted to clear up a potential misconception.

</comment></comment></comment></comment><comment><USER13> I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language extensions were a contributor to these feelings. I also felt as if I spent more time wrangling with the type system than actually solving my business problems.

Yet I really do like Clojure, F#, and PureScript. There's an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target?

Anyway, one of the things I like about PureScript is the row-types. Does anyone know if there's a plan to get row-types into Haskell?

[0] [https://github.com/andyarvanitis/purescript- native](https://github.com/andyarvanitis/purescript-native)

<comment><USER14> I am unconvinced of the practical utility of what row types give you for the added complexity.

The proposal to remove the Eff type (going back to IO) from purescript is telling

<comment><USER15> Do row types add a lot of complexity?

<comment><USER14> I think they add more complexity if you have to track and spell out each effect that is being added or removed from the stack

</comment></comment></comment></comment><comment><USER16> I recently added Flow Type to a Javascript project and it changed my opinion on this debate. I realized that I really don't care about static vs dynamic typing. What I care about is a hierarchy of the ways that my code can be more likely correct. Given the same level of verification, integration tests and are worse than unit tests are worse than runtime checks are worse than compile time checks. There may be cases where static typing makes code more performant, but I usually care a lot more about development speed and correctness. In this world, I just want a way of verifying my code as quickly as possible. Gradual typing lets me specify some validations of my code that will run at compile time. This is a huge win for me in both correctness and development speed.

I don't know if we will ever invent the perfect static type system, but I do know that having the ability to specify some types in a pretty good type system, is better than not being able to specify any types.

I'm convinced that a language with a progressive type system is strictly better than one without. Therefor, any debate that compares static vs dynamic, instead of static vs progressive is not interesting to me.

</comment><comment><USER17> Fwiw, you can map over Maps and Strings in clojure:

        (map identity "foo")  ;; a seq for String is its chars
        ;=> (\f \o \o)

        (map identity {:foo :bar}) ;; a seq of a Map is the
                                   ;; pairs of key/values
        ;=> ([:foo :bar])

<comment><USER18> And get works on more types, like vectors. It also returns nil instead of throwing:

        cljs.user=> (get [:x :y :z] 1)
        :y
        cljs.user=> (get 5 :x)
        nil

</comment></comment><comment><USER9> EDN ( _Extensible_ Data Notation) is extensible in userland, which is the whole point of it. This is JSON plus some extra types.

.

.

.

r/clojure on JSON vs EDN: [https://www.reddit.com/r/Clojure/comments/6gytlf/json_vs_edn...](https://www.reddit.com/r/Clojure/comments/6gytlf/json_vs_edn_what_does_rich_hickey_mean/)

Transcript of Rich Hickey EDN talk which OP obviously hasn't seen: [https://github.com/matthiasn/talk- transcripts/blob/master/Hi...](https://github.com/matthiasn/talk- transcripts/blob/master/Hickey_Rich/LanguageSystem.md)

Transcript of Rich Hickey talk OP linked, C-f "edn": [https://github.com/matthiasn/talk- transcripts/blob/master/Hi...](https://github.com/matthiasn/talk- transcripts/blob/master/Hickey_Rich/EffectivePrograms.md) Perhaps OP had his fingers in his ears while he watched it. This blog post should be retracted with an apology.

<comment><USER10> Would you care to expand on that? It's not clear what you mean, neither from your comment nor the linked Reddit post.

> Transcript of Rich Hickey talk OP linked, C-f "edn":

What do you mean? There are these three occurences of "edn", none of which is enlightening.

* That's great, I'll start shipping some edn across a socket and we're done.

* How many people ever sent edn over wire? Yeah

* So the edn data model is not like a small part of Clojure, it's sort of the heart of Clojure, right? It's the answer to many of these problems. It's tangible, it works over wires

It sounds like he mostly cares about edn because of wires.

<comment><USER9> You have the primary source right in front of you!!!!!!!! What do you need me to explain it worse for? Print out the damn paper, sit down with a highlighter and read. FFS.

<comment><USER19> He _looked_ at the primary source, and doesn't see it saying what you claim it says. So he's asking you for where, from the primary source, you found the source for making your claim. Given that he already looked at the source you cited, that doesn't seem like an extraordinary request...

</comment></comment></comment></comment><comment><USER10> What's _really_ sorely lacking from these discussions is concrete examples of functionality that's easy to write in Clojure and hard in Haskell. I don't mean functions like `assoc-in`. I mean real functional parts of programs.

<comment><USER9> It's about the way you think, not about what you can and can't do. Haskell lets you safely think the really complicated types needed to do programming with zero effects; you couldn't think those thoughts without Haskell because the types we use today are too complex. Clojure encourages you to think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to transform that data.

[http://hyperfiddle.net/](http://hyperfiddle.net/) (my startup) is an example of a data driven system. Hyperfiddle itself is implemented as a large amount of data + 3000 loc to interpret it. If the system is only 3000 loc, you're really not at the complexity scale where all that category theory gymnastics really pays off.

<comment><USER10> That's not especially convincing to me. Haskell also encourages me to "think in terms of data, to push as much logic as possible out of the code and into the data, and then write simple programs to transform that data.".

<comment><USER9> c-f "degoes" in this thread

<comment><USER10> You know John De Goes is a massive Haskell proponent, right?

</comment></comment></comment></comment></comment><comment><USER20> This is great. Why have I never heard anyone make this argument over beers when the debating starts?

Seems like critiques of a programming language or paradigm are usually made by someone imagining a very bad codebase from their past.

</comment><comment><USER21> A dynamically typed language is a statically typed language with precisely one type.

It is extremely easy to use haskell in "dynamic mode". Just use `ByteString`(or Data.Dynamic for safety/convenience) for all your data. Types just present a way to encode some statically known guarantees about the structure of your data/code. You are free to not encode any properties if you want to.

But it is very rare that the data you are working with requires the full generality of `ByteString`. You usually have _some_ sort of structure rather than just working with strings of zeros and ones.

<comment><USER18> > A dynamically typed language is a statically typed language with precisely > one type.

While technically true, saying this is about as useful as saying "You can do anything in any Turing-complete programming language."

<comment><USER22> No, it's really not equivalent to cracks about Turing completeness.

Doing "dynamic" typing in a static language requires me to add all of 5 characters, e.g. ": Any"

Doing static typing in a dynamic language requires me to write a type checker.

These are nowhere near the same.

<comment><USER23> Being able to work with "Any" implies either working with Strings (since you can encode anything in strings) or it implies a memory unsafe language (e.g. working with void* in C) or it implies subtyping and hence an OOP language.

But OOP subtyping is already about solving polymorphic call sites at runtime. And because you carry a vtable around for every instance, thus objects being tagged with their classes, you can always do upcastings and downcastings. So OOP languages are already very dynamic on that scale and fairly unsafe.

No, you cannot do " _: Any_ " in Haskell.

<comment><USER10> > No, you cannot do ": Any" in Haskell.

[https://hackage.haskell.org/package/base-188.8.131.52/docs/Data-...](https://hackage.haskell.org/package/base-18.104.22.168/docs/Data- Dynamic.html)

<comment><USER10> On second thoughts I think kod used Any to mean something like Dynamic and bad_user assumed Any meant a top type, something like I believe Scala has.

</comment></comment></comment></comment></comment></comment><comment><USER24> _" If EDN is an improvement over JSON, then it is marginal at best."_

Why is it only a marginal improvement? It adds considerably more semantic information.

 _" Utilizing EDN also promotes a lot of invisible coupling. Some may tell you that dynamic types don't couple, but that is incorrect and shows a lack of understanding of coupling itself. Many functions over Map exhibit external and stamp coupling."_

Coupling implies a bidirectional connection. Functions rely on data types, but not vice versa.

</comment><comment><USER18> EDIT: deleting this post because it was needlessly counter-inflamatory.

<comment><USER14> No need for typeclasses/existentials. That is trying to approximate some typed/untyped middle ground. You would just use 'dynamic' if you want true dynamic behavior

<comment><USER18> The Edn type given here is closed. That's a correct definition of Edn, which is a closed sum. Edn accomplishes extensibility via the Tag type. However, not all Clojure data is Edn. In order to implement the clmap and clget functions with their full generality, they need to support an open set of types. For example, both `#inst "..."` and `(eval '(Date. ...))` are separate types: TaggedLiteral and java.util.Date respectively.

You need either Dynamic or existentials because Clojure enables you to pass data structures between two functions expecting collection elements of differing capabilities without either A) whole program / inter-module analysis or B) an O(N) type translation.

<comment><USER14> Right.</comment></comment></comment></comment>


The function of criticism: On T.S. Eliot's essay on the evaluation of literature - <AUTHOR> http://www.newcriterion.com/articles.cfm/The-function-of-criticism-8644 <comment><USER2> My network proxy is blocking this, but I believe it to be a link to the actual TS Eliot essay in question: [http://tseliot.com/prose/the-function-of- criticism](http://tseliot.com/prose/the-function-of-criticism)

<comment><USER3> It's not the original Eliot essay, which I had trouble finding too. It can be found on Library Genesis in Volume 2 of The Complete Prose of T.S. Eliot if you're especially eager to read it.

</comment></comment><comment><USER4> I'm terrible with reading these kinds of essays - can anyone summarize?

<comment><USER5> Key quotes from Eliot himself in the article:

"I maintain even that the criticism employed by a trained and skilled writer on his own work is the most vital, the highest kind of criticism; and . . . that some creative writers are superior to others solely because their critical faculty is superior"

"The critic, one would suppose, if he is to justify his existence, should endeavour to discipline his personal prejudices and cranks—tares to which we are all subject—and compose his differences with as many of his fellows as possible, in the common pursuit of true judgment."

Finally, from the body of the text:

"To pick up a phrase he used earlier, taste is the custom by which we like something with the right liking. That is the direction of good teaching. It is easy to like something for the wrong reason. Many of us like trash for no good or right reason. Trying again: the function of criticism—as of good teaching—is to lead our students, our readers—to like something for the right reason. What is the right reason? That is what we have to know and to be able to show."</comment></comment>


Woolly flying squirrel spotted in Uttrakhand's Gangotri National Park - <AUTHOR> https://in.news.yahoo.com/woolly-flying-squirrel-spotted-uttrakhands-052802395.html <comment><USER2> > We spotted this squirrel in 18 of the 13 forest divisions of the state > during a survey,

Umm?

<comment><USER3> > Woolly flying squirrel uses its furry claws as a parachute to fly

I really wanna see these claws

<comment><USER4> "The Englese, she is the very hard language to speak."

Translation requires of the reader a forgiving nature.</comment></comment></comment>


2012 in Review: Encrypting the Web with HTTPS - <AUTHOR> https://www.eff.org/deeplinks/2012/12/end-year-blog-post-2012-https-rise <comment><USER2> I made the switch just recently to making my perosnal site HTTPS only. It was surprisingly easy to do with nginx.

StartSSL gives free 1 year certificates - although each certificate is good for only one sub-domain and the root.

I do wish wildcard, and multi-domain certificates weren't so expensive though - it would give me so much more flexibility.

<comment><USER3> SSL/TLS Server Name Indication (<http://en.wikipedia.org/wiki/Server_Name_Indication>) is supported by all major browsers nowadays. No need for a multi-domain certificate, just use an individual certificate for each virtual host.

<comment> mike-cardwell I think the problem is that startssl will only give you one certificate per domain. Ie, they wont give you multiple free certificates for different subdomains of the same domain.

Also, as far as I understood it SNI doesn't (and never will) exist for Windows XP IE users, making it a non-starter for most websites for many years to come.

<comment><USER4> I know for a fact they will give out separate certificates for individual subdomains; we do it regularly.

<comment> mike-cardwell Free ones?

<comment><USER4> Yep.

Remember, "www" is a subdomain just as much as "somethingelse" is.

<comment> mike-cardwell If that's the case, I wonder why they only let you use one domain in the certs subjectAltName field. I have a cert from them with my domain (which we'll pretend is example.com) in the Common Name field, and "www.example.com" in the subjectAltName field. But I really want a second subjectAltName field in the same certificate for a legacy hostname. This, they don't offer.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> HTTPS is certainly a better option than no HTTPS. But we shouldn't forget that its trust model it is fundamentally and irrecoverably broken -- it has hundreds of single points of complete failure (to wit, DigiNotar and Comodo who both silently and completely broke HTTPS for the entire internet, for a time).

So, for the short term -- HTTPS is the best we have. In the medium term, the security model of HTTPS (and by implication, SPDY) must die, and CAs along with it. DANE or Convergence seem like good replacements. Convergence certainly has the right trust model. DANE is perhaps more easy to migrate to, but suffers from being built on DNSSEC's unacceptably shitty crypto infrastructure.

<comment><USER6> A remember hearing a talk about a half solution to the broken model of HTTPS that could be done with the existing system, which was either a proposol or being implenented. The idea was that when you establish an HTTPS connection to a new site, you save their certificate for a certain amount of time. In the future when you log in, if the certificate they provide dissagrees with the one you have then you assume it is compromised. Becuase of the obvious promblem of legitimatly changing certificates there was a mechanism for the server to inform you of that, but this requires active participation by the server, so the entire system is only done if the server explicitly enables it.

In the long term, we need to replace HTTPS entirely.

</comment></comment><comment><USER7> More people would use HTTPS if self-signed certificates weren't something that scared users into leaving and SSL certificates were cheaper. You can get one for around $10 a year, but that's still not free.

<comment> mike-cardwell You can get one from startssl.com for free.

</comment></comment><comment><USER8> The notion that SSL is a cost keeps it from mass adoption.

<comment><USER9> Do you believe that is an incorrect notion? It most certainly _is_ a cost. Even if certs were free, there is overhead. Not a lot of course (on modern hardware), but it is there.

<comment><USER8> I mean its something perceive as a burden rather than a benefit.</comment></comment></comment>


Study: Amazon Trouncing Google in Android App Revenue - <AUTHOR> http://www.pcmag.com/article2/0,2817,2402443,00.asp

<comment><USER2> App Sales != App Revenue

There are tons of apps on the Android market which make loads of money from advertising alone. Flurry doesn't track that. The model Amazon's AppStore uses is entirely different to the one Google Play uses: the appstore encourages app sales, google play encourages free apps with advertising. Remember, advertising is the core income source for Google.

To quote the Google Play terms, <the 30% "tax" imposed on app sales is going to carriers, not Google>. This is why when the Android Market was launched in 2008 didn't allow paid apps at all. Not only they didn't have payment processing integrated, the banned one of my apps (twice) in Octover 2008 (a month after the G1 launched) for integrating PayPal payments. This was their plan all along...

</comment><comment><USER3> To anyone else who finds it hard to understand what this is measuring, it is supposedly [EDITED] the money that app-developers make per-active-user on in- app purchases (measuring some 'top applications' only). How it is determined is anybody's guess - even the original link [1] is quite opaque on the subject.

I'm not sure I can make the same leaps from this to statements like 'the decision to fork Android was a profitable lesson' (for Amazon) as the original links.

Please correct me if I have anything wrong here.

[1] [http://blog.flurry.com/bid/83604/For-Generating-App- Revenue-...](http://blog.flurry.com/bid/83604/For-Generating-App-Revenue- Amazon-Shows-Google-How-to-Play)

</comment><comment><USER4> Google Wallet is still a joke, i don't have a credit card and it is totally uncommon here in Germany. I have an Amazon account and a PayPal account, these are the two services i can pay with. Google Apps supports Direct Debit, what is the god damn problem? I would have spent probably 50 Euros for Android apps by now. You could believe Google want's to establish Ad revenue first before they make their payment system competitive.

</comment><comment><USER5> The article basically concludes that iOS and Amazon users pay for apps, Android Market users don't. Ouch. Google really messed up the launch of Android Market and promoting apps worth paying for.</comment>


Show HN: Brandsketcher –  Free startup name brainstorming service - <AUTHOR> http://www.brandsketcher.com// <comment><USER2> Some years ago there was a site called NameThis by klustr where people could request names for specific things for money and have users submit suggestions, then voting on them. The winning users would get some nice money. Sadly there was a lot of cheating going on and very bad communication from the company. They went offline after a fairly short time.

I loved it, it was a mixture of puns, wordplay and general creativity. Got my first overseas pay check for it (or was it a filled credit card? It was a bit weird and complicated...). Still remember my winning suggestion and I hope the.company uses it, it was purrfect.

</comment><comment><USER3> I am not convinced this isn't some kind of innovative lead generation method or an ingenious scheme to collect lots of juicy juicy business ideas. Could at least put your name on there so people know who they're dealing with ;)

<comment><AUTHOR> Haha, luckily its all about execution. Ideas are easy. Its more to help those ideas get a push into the right direction. A name shouldnt hold great ideas back. Thats where i try to be of service.

<comment><USER3> Yeah, esp. love the "Would you possibly need a logo design later?" part of your questionnaire. That seems incredibly relevant to choosing a good name for a company. (Not intending to troll you though, hats off to a clever lead generation strategy!)

</comment></comment></comment><comment><USER4> Looking forward hearing back, nice idea. Hopefully you'll also get some design work out of it too!

</comment><comment><USER5> This service is a great idea, I personally can never come up with a name.

<comment><USER6> I'm one of those people who has a journal of 15 executable ideas at one given time.

The problem is that if I'm unable to find a name I'm attached to, I won't work on it.

<comment><USER7> I am the same way. It's such a strange need - like the product cannot exist, even in my imagination, until it is named properly.

</comment></comment></comment><comment><USER8> This looks fun - nice idea.

Submitted my one =), looking forward to what you come up with!

</comment><comment><USER9> Why are you doing this?

</comment><comment><USER10> Cool, submitted!

</comment><comment><USER11> oh look now your ideas are all for sale!</comment>


The Russell-Einstein Manifesto - <AUTHOR> http://www.umich.edu/~pugwash/Manifesto.html <comment><USER2> The linked URL forwards me to a login prompt. For others experiencing the same, you can view the manifesto here: [https://pugwash.org/1955/07/09/statement- manifesto/](https://pugwash.org/1955/07/09/statement-manifesto/)</comment>


Mobile operators to install biometric system, hike SIM verification fee - Ash-k http://www.nation.com.pk/pakistan-news-newspaper-daily-english-online/business/17-Sep-2013/mobile-operators-to-install-biometric-system-hike-sim-verification-fee <comment> Ash-k Is this future in every country ?</comment>