Ask HN: Wefunder has been invited to Washington DC. What should we ask? - <AUTHOR>

Last week, we launched a petition (http://wefunder.com) to raise awareness about the Crowdfunding securities reform being debated in Congress. Thanks to HN and Reddit, after 2 days, over $4 million was pledged... causing Wefunder to be invited to Washington to talk to some of the lawmakers involved in the legislation.
On Friday, we're flying down to DC to meet with staff from all the players in the debate - two Senators (Brown, Merkley), the lead Congressman (McHenry), and the President's Office.
Some good points were raised in this thread: http://news.ycombinator.com/item?id=3529045.  What other concerns or questions can we bring up?  We have a chance of influencing the legislation.
As an example, one question we plan to ask:  High-growth startups obviously don't want 3000 investors on their cap table.  Can the proposed funding intermediaries give a business one giant check, and manage a fund of small investors, one for each startup? <comment><USER2> Section 7(a)(G)(ii)(IX) would require that crowdfunding intermediaries require "each potential investor to answer questions demonstrating competency in" understanding various types of risks involved in such investments. Should the SEC be required to provide a list of questions which, if answered correctly by potential investors, would provide a safe-haven to the intermediary? If not, should the bill be more specific with regard to the level of competency to be demonstrated?

Sec. 7(a)(G)(ii)(XI) requires intermediaries to carry out a background check on the issuer's principals. What must such a background check consist of in order to satisfy this criteria? How is this information to be used? (kept on file by intermediary? Disclosed to potential investors? Filed with the commission?)

</comment><comment><USER3> This thread is important, i hope it gets more attention.

Ability to fund start-ups is a start, you might also need a parallel start-up type visa so foreign entrepreneurs can create jobs and great products.

Just for the record for me a good investor visa:

-Tie the visa to the start up, if it fails they have to leave, cant work for other companies. As a corollary they cant take a job that previously existed, they can only add jobs.

-Reduce or remove current capital requirements 500,000-1m is way overkill.

-Keep the 'must create n jobs' requirement, but give more time to create the n jobs. Forcing start ups to hire 5/10 people in one year is not cool.

</comment><comment><USER4> If the legislation passes, will the intermediary companies be responsible for educating the roughly 230 million new investors in the country or will the government take an active role in this process?</comment>


Hitachi presents a storage medium that should last forever - <AUTHOR> http://www.neowin.net/news/hitachi-presents-a-storage-medium-that-should-last-forever

<comment><USER2> Following the news spam after news spam, here is the AFP story all the submitted page and "sources" copied from: [http://www.google.com/hostednews/afp/article/ALeqM5hrS0Kp5RL...](http://www.google.com/hostednews/afp/article/ALeqM5hrS0Kp5RLa8lIvZ4nTCkZbttjhuw?docId=CNG.4aeae4fa36f6e7fc476fd24e5e9b2688.191)

<comment><USER3> That link won't work without a Google referrer.

<comment><USER4> Doesn't work for me even _with_ a Google referrer. Paste into Google search, click first link, and I'm back at the Google homepage.

This seems to be the same article though: [http://www.smh.com.au/digital- life/computers/glass-slivers-t...](http://www.smh.com.au/digital- life/computers/glass-slivers-that-store-data-forever-unveiled-by- hitachi-20120925-26i3f.html)

</comment></comment></comment><comment><USER5> re the original AP report, people aren't replacing LPs and CDs because the media are wearing out, they're replacing them because newer media have higher storage densities, are more physically convenient and in some cases because they allow higher fidelity recording.

Yes this medium will last longer than LPs, CDs etc, but it will do nothing at all to remedy the actual reasons these older media are being superseded.

Edit: I'm reminded of the old Domesday Book BBC project that recorded everything on laser discs and played the data on BBC microcomputers. The discs are still fine, but it got to the point where there were no machines left physically capable of playing them. There was a project to fix that but I don't know how it went.

<comment><USER6> The second part of your comment is interesting. Can electronics be designed in a way so that it has a very long life?

The idea - hard-code information to silicon and preserve it. e.g. Chips on PCBs that are completely encased in substrate. Provide fused power prongs and a serial port interface to this. Future systems can integrate to this to consume the data.

<comment><USER7> _Can electronics be designed in a way so that it has a very long life?_

NASA seem to be pretty good at that. I guess it's a question of cost more than anything else.

<comment><USER8> The oldest stuff NASA has out there is what, 35 years old? Hardly a "very long life". And it's floating in vacuum, which is pretty much the ideal storage environment. Making stuff last in space is _much easier_ than on Earth (and much easier than getting it there, of course).

<comment><USER9> It seems that the high levels of radiation could make it much less than the ideal storage environment

<comment><USER10> Plus temperature extremes.

</comment></comment></comment></comment></comment></comment><comment><USER11> These kinds of technologies have been tried before (and largely abandoned.) The real problem in long term data storage is figuring out how to interpret decades old binary formats for which the software no longer exists. It doesn't matter if you have a thousand perfect PDFs if Adobe has been out of business for a hundred years.

The other issue with long term data storage is that the whole advantage of using digital technologies in the first place is that data is easy to copy. Using specialty technologies like this totally nullifies that advantage.

If your goal is simply long-term data storage/archival, you'd do better to just use durable and popular media of the day, to maintain an index of your collection, and to upgrade/migrate your media and file formats regularly to keep up with the times. If you're going for _really_ long term storage, such that might go multiple human lifespans without being needed or needing maintenance, you might as well just skip the digital to begin with.

<comment><USER12> You could potentially store them inside/along with a virtual machine image which would be capable of rendering them, and then document the crap out of the VM (which would require as few, and as simple, external interfaces as possible), such that it could be easily re-created/ported to future OSes.

I think quite a few places where continuity over decade timescales (especially in the embedded world) are storing VM images with the exact versions of various parts of the toolchain they use, to ensure compatibility.

And of course, there's plenty of precedent with things like the Hercules IBM mainframe emulator[1], as well as things like VMWare, Bochs, QEMU, etc.

I think I've come across old DOS games being re-released wrapped with dosbox or something similar as a compat layer for modern OSes.

[1] <https://en.wikipedia.org/wiki/Hercules_%28emulator%29>

</comment></comment><comment><USER13> Just to be a smartass: I guess it will last for a significant timespan, but not actually "forever" unless Hitachi also finds out how to reverse entropy or how to leave this universe. If they don't a lot of stuff might get their data, like proton-decay, the upcoming black hole era or the fact that everything is liquid on very large timescales. Further reading: [http://en.wikipedia.org/wiki/Timeline_of_the_far_future#Futu...](http://en.wikipedia.org/wiki/Timeline_of_the_far_future#Future_of_the_Earth.2C_the_Solar_System_and_the_Universe) <http://en.wikipedia.org/wiki/Proton_decay> <http://en.wikipedia.org/wiki/Ultimate_fate_of_the_universe>

<comment><USER14> It's for small values of "forever".

</comment></comment><comment><USER15> How about a disc that is made of glass, has a capacity of a DVD and can be read by standard dvd players and can be bought today, for a mere of €160? THIS is amazing. <http://www.syylex.com/index.php/home_english.html>

<comment><USER8> The reflective layer is still made of metal and the two layers are glued together. You have to take the maker's words on how durable those actually are.

<comment><USER15> Well, sure - but even if the reflective layer loosens, you still have the glass layer - then it would be the same as the hitachi concept: read the glass pits with a miroscope. Or add a new reflective layer.

</comment></comment></comment><comment><USER16> Old idea. Here's a 2009 Coding Horror post about doing the same thing with paper: [http://www.codinghorror.com/blog/2009/07/the-paper-data- stor...](http://www.codinghorror.com/blog/2009/07/the-paper-data-storage- option.html)

</comment><comment><USER17> I still remember the promises of the holographic versatile disc <http://en.wikipedia.org/wiki/Holographic_Versatile_Disc> backed by Hitachi as well, and apparently the company went bankrupt in 2010 :(

</comment><comment><USER18> So it is 21st century digital microfiche? Clever. I do know museums will probably line up for this stuff - standard CD-ROMs start to rot after 10 years and DVDs are better but relatively untested.

I wonder how much FEC is built into them. (In other words, what is the biggest scratch you could put into it without losing data.)

<http://en.wikipedia.org/wiki/Microfiche>

<http://en.wikipedia.org/wiki/Forward_error_correction>

</comment><comment><USER19> So in a million year, people will still have "a computer with the right software" ?

This is useless until they find an "intuitive" way to store the process to decode the binary data into something readable.

</comment><comment><USER20> Sounds great - but maybe I'll wait until it can be done on a material thats not incredibly brittle and thus easy to accidentally break...

<comment><USER21> Like pyrex?

Edit: Like borosilicate glass?

<comment><USER22> Pyrex is a brand. The material you are referring to is borosilicate glass.

</comment></comment></comment><comment><USER4> >Currently the size of the data that can be stored isn't known

Yes it is: [http://www.smh.com.au/digital-life/computers/glass- slivers-t...](http://www.smh.com.au/digital-life/computers/glass-slivers-that- store-data-forever-unveiled-by-hitachi-20120925-26i3f.html)

The density is 40MB/in².

</comment><comment><USER23> Maybe the medium will last longer, but isn't "If you have a computer with the right software and an optical microscope hooked up to it" a big part of the data decay problem on floppy disks etc.? Even if the data is there, it's useless without the right software/hardware to read it.

<comment><USER24> If it's actual visual dots on the glass, it sounds like you'd just need to figure out how to get a good enough photograph of the thing to see the dots in and spend an afternoon whipping up an image processing script in Python to convert the dots to binary code. This sounds a lot simpler than whatever would be involved in setting up the apparatus to read bits of volatile magnetic media where you'd have to interact more closely with the media, be more mindful of not accidentally destroying the stored data and rely on much less intuitive physics than looking at a thing through a microscope for the recovery process.

<comment><USER23> Those are good point. I guess I was more curious about how the data is stored — say someone 100 years from now picks one of these up and wants to read the data. Will the format in which it's stored prevent them from doing so?

<comment><USER24> A very simple format would be regular fixed dot patterns (⣿) corresponding to bytes, spaced a apart a bit. Then it's the user's responsibility to be sensible and encode stuff without too clever compression. This wouldn't guard against trying to read the image sideways or upside down though.

If you get a disc with ASCII text and can read the bits a 100 years from now, even if ASCII coding is lost to history, as long as you can figure out the thing is supposed to contain writing that uses 8 bits per letter, and still know English, a trivial pattern analysis gets you the code table you can use to read the text.

The plaintext can then be used to describe the formats for whatever other data the disk may contain.

</comment></comment></comment></comment><comment><USER25> Makes me think of the write-only storage medium used in space ship black boxes in the Gap series by Steven Donaldsson.

</comment><comment><USER26> They're just punch cards made on glass.

<comment><USER27> CD:s are just punch cards made on aluminium.

<comment><USER8> And that's the difference. Glass is much, much more durable than both paper and aliminium.

<comment><USER28> In a fire there is little difference.

</comment></comment></comment></comment><comment><USER29> sounds fantastic. I will go buy an optical microscope and the software.

Honestly, after all this research is the best Hitachi could come up with? How about a marble stone with some dots on it? They seem to last a long time too.

</comment><comment><USER30> It may last up to 3 billion years... unless the glass gets scratched. Oopsie.

</comment><comment><USER31> Can they rewrite stuff on glass? Or is it a one way write?

<comment><USER32> I can imagine that one could melt the surface a bit and then rewrite it.

</comment></comment><comment><USER33> I wonder what would be the density of such storage

</comment><comment><USER34> what if glass breaks ??</comment>


GPU processing helps lower CT scan radiation - <AUTHOR> http://www.medicaldaily.com/news/20100723/516/video-game-processors-help-lower-ct-scan-radiation.htm

<comment><AUTHOR> One of the first real world, end user facing applications of GPU processing speed-up beyond video and financial applications that I've seen.</comment>


Ask HN: What knowledge and skills should a Head of Security possess? - <AUTHOR> With all the frustration boiling about Equifax's security head being unqualified, and as someone who isn't a security expert myself, I'm genuinely curious about what a head of security needs to know in order to do their job effectively. <comment><USER2> 1.) Politics - ability to negotiate, ability to convince. Experience with management - ability enforce the rules and create organization that follows them. Ability to write down understandable rules. (There is no security if employees dont follow the instruction and share passwords with each other.) That means creating structures for employees learning including lessons etc, understands incentives, knows how to verify things are done the way they should.

2.) Politics two - ability to plan, think ahead and gauge risk vs cost (unless you are CIA you dont aim for zero risk). Follow up plan, have plans about what to do after incident including PR and know that such plan is needed.

3.) Knows big picture security. Knows various standards, what they are good for, how much they cost, their weaknesses and whether they are good idea for your company. Understands what rules in those standards are for and whether they apply.

4.) Lower picture security - knows what is pen testing, intrusion detection a bit about networks etc etc. Does not need to be expert and configure the stuff from top of head, but needs to understand what his/her people are talking about when they talk. Needs ability to distinguish between bullshit and fact.

<comment><USER3> Politics can be a double-edged sword. "Avoiding conflicts" is an unreasonably effective strategy until it stops working.

<comment><USER2> Being good in politics does not imply avoiding conflicts. It implies effective approach to them. Most importantly, ability to diffuse the conflict and ability to find solution that satisfy multiple parties is not conflict avoidance - it is rational approach instead of emotional angry one. The direct angry confrontation is sometimes part of conflict solution too, if you have that kind of personality, but even there you need to control yourself enough not to make complete fool out of you - and know when not to do so. Which is pretty easy for angry people.

The other part of politics is understanding what other people are up to and why they are doing what they are doing. Knowing who can make decisions, who can be trusted in what, who is stubbornly refusing change and thus it is waste of time trying to convince him etc.

<comment><USER3> I agree, but "avoiding conflicts" can make somebody look good at politics, until...

</comment></comment></comment></comment><comment><USER4> Amongst others, people skills. Excellent written and spoken communication skills, good presentation skills; the ability to explain to people why they have to be so inconvenienced and ideally make them _want_ to. Flexibility and compromise; empathy and understanding and the willingness to relax security restrictions in the right circumstances.

The biggest obstacle to security is the people you're trying to keep secure. If you don't get them on side and keep them on side, they will subvert security themselves from the inside. Get them on side and keep them on side and they themselves will identify opportunities to improve security that might otherwise be left open forever.

</comment><comment><USER5> Almost everything most people in here have said.

plus

They must have a strong network in the industry, so they can hire and poach the best from their network.

They must know how to hire. They are not going to be the ones that are doing the actual work so they need a competent team.

They must know enough to listen and make decisions. It's not enough to have a team if you won't listen to them. You must be competent enough to listen to them that if someone comes to you and asks for $100,000. You can gauge that it's a smart spend and authorize it quickly. Security is not one of those things you can sit on and wait on.

</comment><comment><USER6> Broadly Speaking:

\- A good understanding of Functional IT, knowledge about typical Systems and Processes in an Industry(BFSI/Tech/Life Sciences), what sort of things are being protected from hackers (Windows Heavy Environments/MacOS Heavy Environments)

\- Must have hands-on knowledge in Network Security and the tools/processes being used in a company

\- Must understand Regulations related to the Industry (For e.g: HIPAA)

\- Must have atleast 10 to 15 years of experience in 3 or more areas of Security like - Network Security/SOC , Audit/Compliance, Risk Management, Sysadmin/Network , Security Engineering.

</comment><comment><USER7> I would love to tell you but it is classified. Only the head of security is allowed to know the full details.

</comment><comment><USER8> * A solid understanding of security technology. I don't expect a CISO to be able to field-strip a firewall or jump in and take the place of one of her line analysts, but I do expect the CISO to understand firewall technologies and talk intelligently about why they're important. One of the CISO's jobs is advocating for security controls with other business organizations, which necessitates the ability to talk intelligently and in layman-understandable terms about what those controls entail, what those technologies do, and why they're important. A CISO who doesn't understand what a digital certificate is will have a hard time arguing for protecting them or will accept weak protections because they sound stronger than they are. Worse, a CISO who doesn't understand security solidly may call for implementing controls that don't make sense or that don't afford any protection, or will focus too heavily on one area while neglecting another. The amount of technological know-how in the CISO will likely vary according to company and org size: the CISO of a small company will likely also be the security person and therefore should be very security-tech-savvy; the CISO of a large corporation will likely be much further removed from the console glass because their scope is much larger. In the latter case, you would expect the CISO to have a solid organization of very security-tech-savvy people _to whom the CISO would listen closely and trust to make good recommendations_. (This latter part seems to get overlooked.)

* CISOs must understand risk, and be able to articulate it in a balanced picture to non-security people. CISOs who always say no and couch risk in the most apocalyptic terms are actively disabling their companies; CISOs who always say yes and couch risk in the gentlest terms are setting their company up for Equifax-level failures. The old saying is "A ship in harbor is safe, but that's not what ships are for"\--the CISO needs to be able to let the ship sail when appropriate while still pointing out the reefs on the map.

* Along similar lines, the CISO needs to understand her particular company and its industry well. If you don't understand what makes the company money, you may wind up arguing for controls that cut profits or hinder business. CISOs also need to understand and anticipate trends in their industry and as a whole. Cloud, containers, agile development, devops, these are all huge trends in the industry right now, and a good CISO will see them coming and have considered where to fit them in (or where to say "nope, can't do that (right now)...and here's why") so when the business pops up and says, 'We want to do that!' she can explain what's possible, what's reasonable, and where the risks are for their particular business. A healthcare company with extensive HIPAA and Fedramp regulations is going to have an entirely different approach to the cloud than a software-focused startup working on a new social media solution!</comment>


Make Time-Wasting Sites Less Appealing by Switching Your Monitor to Greyscale - <AUTHOR> http://lifehacker.com/#!5770297/make-time+wasters-less-appealing-by-switching-your-monitor-to-greyscale <comment><USER2> Link just goes to the Lifehacker front page for me.

<comment><AUTHOR> ugh. Sorry about that. I cannot stand their new site.

[http://lifehacker.com/#!5770297/make-time+wasters-less- appea...](http://lifehacker.com/#!5770297/make-time+wasters-less-appealing-by- switching-your-monitor-to-greyscale)</comment></comment>


How to look out for yourself inside a particular company - <AUTHOR> http://rachelbythebay.com/w/2018/03/21/next/ <comment><USER2> How does this not have any comments?

I work on a team that is 90% on visas, mostly Chinese and Indian but some Canadians too.

Everyone acts like this on my team. If they don't, their visa can be terminated, as can mine.

We can't connect as people and a team when we're all defensive and only looking out for ourselves.

But that's what's rewarded and incentivised.</comment>


Ask HN: Please explain what happens in this execl() problem. - <AUTHOR>

We were studying for the Unix System programming module. And a friend came up with this problem. I got the code, simplified and did several changes to it. Following is the code.
#include<stdio.h> main() {
   printf("Here comes the date");
   printf("Line number 3 before execl\n");
   printf("Line number 2 before execl");
   printf("Line number 1 before execl");
   execl("/bin/date", "date", 0);
   printf("Line number 1 after execl");
   printf("Line number 2 after execl\n");
exit (0); }
Friend complained that execl() overlaps not only the code after it but the code before it. But found that execl() overlaps the code before it until it finds a line feed. Why this happen?. Please explain. (Yes, code looks lame & I get two warnings for execl() & exit() when compile) <comment><USER2> This had better not be a homework problem.

The lines "Line number 2 before execl" and "Line number 1 before execl" will not be printed on most systems because most systems default to line-buffering (when writing to a terminal) or fully buffering (otherwise) output.

The lines "... after execl" will not be printed if execl succeeds, because execl does not return if it succeeds.

Other bugs: You're not checking the return status of execl; you've declared main incorrectly; you need to #include <unistd.h> and <stdlib.h> if you're going to use execl and exit; you should pass a terminating NULL to execl, not 0 (the C compiler will coerce 0 to a pointer, but NULL is not guaranteed to be (void *)0).

<comment><USER3> I thought 'the' standard said that 0 used in pointer contexts is interpreted by the compiler as a null pointer, even if the machine's representation of a null pointer is not 0.

<comment><USER2> I'm sure there is _a_ standard which says that... but the nice thing about standards is that there are so many to choose from. :-)

It's not something which you should rely upon.

</comment></comment></comment><comment><USER3> > I get two warnings for execl() & exit() when compile

      man execl
      man 3 exit

will tell you which headers you need to #include.

<comment><AUTHOR> Thank you. I hope that is a good 'habit' on the way becoming a good sys programmer, which I didn't think of (reading man for those things).

</comment></comment><comment><USER4> buffers?

BTW, don't think this is "Hacker News" ;)

<comment><AUTHOR> If you mean my problem is not suitable here, I'm sorry. I know I had to ask in stackoverflow, but when I got this problem I felt that HN sure has answer. But now I realize this kind of problems will make HN a mess. I'll try to post the best & appropriate here in future. I keep learning :) .</comment></comment>


If your product is great, it doesn't need to be good (2010) - <AUTHOR> http://paulbuchheit.blogspot.com/2010/02/if-your-product-is-great-it-doesnt-need.html <comment><USER2> > Pick three key attributes or features, get those things very, very right

I think the trouble with this advice is, when you're developing a product, isn't not really clear which attributes are key. You have a hypothesis, but you could easily be wrong.

Or perhaps this advice could be interpreted as: decide on your hypothesis, and go all in on it, and only it. If you're right, it'll turn out well (as discussed in the article) and if you're wrong you would have failed anyway and you probably fail quicker following this advice.

<comment><USER3> _" isn't not really clear which attributes are key"_

If that isn't clear, you're missing the "doing deliberate research" part of such a venture.

<comment><USER4> Part of the reason Agile/XP/etc. exist is to argue against this line of thought. Iteratively putting a working product in front of people is more effective at getting you high quality information than millions of dollars of upfront research.

<comment><USER5> Agree but it's not really a dichotomy. From initial conception to final release, you should be researching by iteration. Eventually that means user- testing prototypes, then betas, then RCs.

<comment><USER3> _" you should be researching by iteration"_

This!

Research doesn't just mean to read stuff.

</comment></comment></comment></comment></comment><comment><USER6> It certainly fits the startup style concept where you expect the product to take off or eventually "pulled" out from the company by customers. Customers in those situations don't jump on board for a bazillion features (that actually sounds like a headache) rather it is probably just for the core of whatever the product is. If they're not interested in that... bazillion side features won't get them either.

I was working on a ancillary product connected to my employer's main product a while ago. It was barely done, missing a lot of features but they wanted to ship it. I was all "ok but .."..... and the folks who wanted it ate it up. No complaints about all the missing tidbits I was thinking of, not a peep. As far as adoption went, it didn't matter. I probably could have spent a month or more longer on that stuff, but it wasn't what was important to get started.

<comment><USER7> Going through that process a few times before, I learned about the importance of understanding which among the many equally time consuming ways to build something will give you the best tradeoffs as the product grows (or doesn't).

Should a record be updated or a new version inserted? Hard or soft deletes? Creating a column for each setting or have a JSON blob?

No one answer is correct for every situation. You can be future proof, ready to implement reporting/backup and restore/power user features when the time comes, or setting yourself up for pain.

</comment></comment><comment><USER8> > Disclaimer: This advice probably only applies to consumer products (ones > where the purchaser is also the user -- this includes some business > products). For markets that have purchasing processes with long lists of > feature requirements, you should probably just crank out as many features as > possible and not waste time on simplicity or usability.

I hate it because it's true.

</comment><comment><USER9> This is a problem with almost all open source software: for all the talk of doing one thing and doing it well, they almost all end up being kitchen sinks in the end. The only major success story I can think of was when Mozilla was forked and trimmed down to Firefox. Hopefully the same thing will happen to Firefox, and we can get a browsing experience where the focus is the average user experience, with easy ways to change it into an expert user interface. And even more hopefully something similar happens to every desktop manager, email client and shell tool out there. Make things extensible, then remove the cruft. Continue until the core functionality is all that remains.

<comment><USER10> > with easy ways to change it into an expert user interface

Show me one product that could achieve this? Never have I ever seen something that executes that particular step well.

So I vote against 'average user experience' aka dumbed down and locked down crap.

<comment><USER11> VSCode, Firefox, KDE, tilix, cmder, the latest version of blender...

<comment><USER10> I would agree with VSCode, seems ok in my book.

Firefox of the past maybe, when it allowed unsigned extensions. AFAIK now it isn't possible in non-dev version.

Others I have not heard of/not used.

</comment></comment></comment></comment><comment><USER12> What he means: If your product (first version) is Great (at a few important things), it doesn't need to be Good (at everything)

I think the unstated "first version" part is important. You should be gradually adding the missing parts. And not just leave it at the great, simple but missing too many things state forever.

<comment><USER8> True but I think another important factor is that by avoiding the missing parts, you might realise they're not really missing after all. What once seemed essential actually isn't.

</comment></comment><comment><USER13> Previous discussion 10 years ago:

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

<comment><USER14> No, you're mistaken that article is from 2010, that's oh...

</comment></comment><comment><USER15> This works sometimes. Like, the article notes, it worked for the iPod. For the iPad, it landed much softer than its predecessors, even if they still made a killing on sales.

The large format was awkward to hold as a content consumption device, and while it could have made for a neat content creation device, that never became a mass-market phenomenon. Later, smaller models were then eclipsed by phones that grew in size. Then, recently, the line was repositioned to import some more traditional computing expectations, after the Surface line proved that there was demand for that paradigm.

If you squint, you'll notice that the iPad wasn't a failure, but the critiques leveled against it at the time that challenged whether consumers would recognize that an iPad was something they needed turned out to be right. Those who waited and never bought an iPad were rewarded by phones that grew in size until they could reliably satisfy much of the iPad's usecase. Those who used the iPad for content creation found that software was a significant part of their workflow, which translated poorly to competing platforms that later emerged to innovate with hardware -- so their long-term retention was a blend of lock-in and merit.

At first, the high price of the product initially contributed to a significant self-selection of its customer base -- by dissuading unsure prospects from an impulse buy; but this gatekeeping effect was lessened when smaller, cheaper models were introduced later. Gmail achieved gating through invitations; Facebook achieved gating through requiring an ".edu" email address. The iPad, Gmail, and Facebook all benefited from the marketing value of gating, but in the latter two's case, the network effect kicked in in earnest once the gating was lifted. In the iPad's case, once less-invested people began buying iPads, that now-shifting market of people began moving closer and closer to the consensus that it's simply a Really Big iPhone, with all the benefits and drawbacks that come with that.

I'd generalize that lesson to say that your product must appeal to a self- selecting, highly-invested fan, so that it's profitable to solely cater to them and ignore everyone else. Then, to survive an intentional or unintentional pivot to a more mass-market appeal, your product must readily offer a smooth and coherent way to satisfy a set of usability needs people currently have. Gmail, Facebook, the iPod, and the iPhone did this, but the iPad fell well short.

<comment><USER5> These really good observations. One thing that made me appreciate the _current_ ipad a little more is my recent experience with MS's Surface which is an explicit tablet/desktop hybrid. There is a lot I like about what MS is doing, and I recognize the hybrid model is extremely difficult to accomplish, but their tablet experience just doesn't stack up to the ipad's. I felt frequently frustrated by the lack of gestures which would help me quickly navigate between applications, and (even worse) the click targets don't change for the tablet mode, so pressing things with my finger is nearly impossible. Watching youtube is like rocket surgery because of how the controls hide until hover and remain very small. Even UIs which the OS could ostensibly alter, like click targets for window controls, stay small and difficult to hit.

Microsoft is trying to hit two products at once, and (to a degree) the desktop mode is still strong, but the tablet mode just isn't. It gives me more respect for Apple's decisions than I previously had.

</comment></comment><comment><USER16> > We took a similar approach when launching Gmail... The secondary and > tertiary features were minimal or absent. There was no "rich text" composer. > The original address book was implemented in two days and did almost nothing

Even today, Gmail doesn't do a lot of things that Outlook does like rendering web fonts / inline calendaring, but I still vastly prefer Gmail (even with the new clunky UI) over any other client

Also shoutout to Paul for envisioning the iPad as a quarantine savior in 2010 haha

</comment><comment><USER17> > back when 4MB quotas were the norm

Hotmail had a very low quota, somewhere in the 1 MB to 10 MB limit, so users had to delete an email before sending a new email. lol.

That was the motivation for most users to switch, not "because gmail is fast," despite the humblebrag.

<comment><USER18> Exactly. Paul B gets a lot of credit for designing a nice AJAX product, but me and most people switched from hotmail mainly because of the storage, and partially because of google's cool aura at the time (remember "don't be evil"?)

The search bar was nice but would have been pointless in hotmail where you were forced to delete your old emails anyway.

</comment></comment><comment><USER19> Reminds me of something a colleague once told me (not sure if he was qouting someone): "your product needs to be _the best_ , but that doesn't means it needs to be good."

That is to say your success is relative to your competition (and sometimes all solutions are "not good")

This advice seems to me like the parallel for enterprise products.

</comment><comment><USER20> Good article and the disclaimer at the end is appreciated as well.

<comment><USER21> Yeah, I like to think of that as the "Salesforce clause." Salesforce is a very powerful system, and can be bent to do just about anything. But, actual users frequently hate it, and customization is involved enough that you need someone who's an expert in doing it.

I consider myself lucky that I don't have to use very much software at work that was chosen for me by a CTO, or, worse yet, a CFO, or other executive.

</comment></comment><comment><USER22> Still spot on. I think this applies to software as well as physical products.

</comment><comment><USER23> Just read this, this week. Excited to see what others think.

</comment><comment><USER24> Very well-timed and helpful, thank you.

</comment><comment><USER25> I think a lot of companies have become features-hungry, gathering more and more side-features and forgetting their core value.

<comment><USER21> Very true. Microsoft Word is a great example of this. It has a ton of features. Nobody uses them all. Everybody uses a small fraction of them. The problem is that my useful subset is probably not the same as your useful subset.

And, this is about a piece of software that's fundamentally just about producing documents for people to read. You know, text, and the occasional picture or graph. Excel is worse: never become known as the person who "knows Excel" in the office, unless you want people bugging you forever about it.

Why do so few software projects ever reach a state that's considered "finished," anyway?

<comment><USER26> I remember years ago, when 4:3 CRT monitors were still prevalent, opening up Word at work and turning on every optional menu plus the ridiculous paperclip assistant just to make this joke in a snarky email (before there were snarky Slack messages instead).

The resulting blank space left for actually typing something with every feature enabled: zero.

<comment><USER21> That takes me back to the bad old days of browser toolbars. I remember seeing someone's screen almost completely filled with them.

<comment><USER27> I hadn't though about them in ages but turns out, at least the Google Toolbar is still around. [https://www.google.com/intl/de/toolbar/ie/index.html](https://www.google.com/intl/de/toolbar/ie/index.html)

<comment><USER17> If you have any old browser toolbars installed, remove them ASAP.

Often they were subcontracted out, even by name-brand companies, and the result was a security bugfest. In particular, I'm thinking of one that starts with Y.</comment></comment></comment></comment></comment></comment>


Ask HN: Why not make the "Who's hiring" threads weekly not monthly? - <AUTHOR> I feel that A lot of startups and freelancers/Consultants would agree with me when I say that a weekly or at least bi-weekly thread would be more beneficial <comment><USER2> I think at the core of it all, Hacker News is about discussion and conversation, and sharing job opportunities are a by-product of that, not the main focus.

By cluttering up the feed with auto-generated content on a more frequent basis, the value of all the other good stuff we come to read would be diminished. Not to say that 'Who's hiring?' isn't useful, maybe we just don't need it that often

</comment><comment><USER3> Why would it be more beneficial?</comment>


Rusty's API Design Manifesto - <AUTHOR> http://sweng.the-davies.net/Home/rustys-api-design-manifesto <comment><AUTHOR> In case someone is curious about the original presentation [https://ozlabs.org/~rusty/ols-2003-keynote/img39.html](https://ozlabs.org/~rusty/ols-2003-keynote/img39.html)</comment>


Facebook iOS SDK Remotely Crashing Spotify, TikTok, Pinterest, Winno and More - <AUTHOR> https://github.com/facebook/facebook-ios-sdk/issues/1374 <comment><USER2> Seems to be some suggestions now that apps were continuing to crash even after commenting out the FB implementation because FB is managing to do remote API calls just because the framework is linked.

[https://github.com/facebook/facebook-ios- sdk/issues/1373#iss...](https://github.com/facebook/facebook-ios- sdk/issues/1373#issuecomment-624944045)

> It does not matter. Their libraries are dynamic, and they abuse +load > functions for classes with some business logic calls. So, +load will be > called anyway on the application launch when dyld loads all linked > frameworks.

and

> I really don't understand why it is still crashing when we turn it off? > Could you please explain, why there is a remote connection even we comment > out the implementation? Linking binary framework just enough to break things > down, why? What do you do in background? Sending or receiving some data even > it's not been initialized?

<comment><USER3> I'm shocked but perhaps not surprised at many of the comments in that thread. These people are app developers who voluntarily link in huge multimegabyte binary-only third party sdks, and then act surprised that the code they are linking is prone to crashing? It should be obvious that any bug in such an SDK might bring down any app, even on launch and even if your own code never makes an explicit call to the SDK.

Third party SDKs have free reign in your apps. They can launch background threads, intercept and log any and all UI interaction and UI widget/input field values, and call home. All of this without you ever calling a single method explicitly.

It gives the SDK developers a foothold inside each app's sandbox/keychain/developer-specific app ID. It must be a gold mine for correlating and tracking users across apps and websites, breaking down the intended barrier between different apple developer team IDs and app containers.

Last time I checked one of these binary SDKs along the likes of FB, Gmaps, etc just running strings on the binary framework lib was enough to send chills down any developer's spine.

<comment><USER4> Every time we include a dependency in an application, we give its maintainers commit privileges to production. Who do we trust?

<comment><USER3> An open source SDK can at least be audited and locked to a particular version, with no hidden shenanigans.

</comment></comment></comment></comment><comment><USER5> For those wondering why the Facebook SDK is so widely used in popular mobile apps: Facebook Login is actually in the minority of reasons to add the Facebook SDK to your mobile app. The vast majority of apps will add the Facebook SDK because it contains Facebook App Ads; a library that "completes the circle" in terms of finding out how effectively the ads you ran on Facebook were at getting people to download, install and run your mobile app. So really the Facebook SDK is there to collect data of that advertisement being effective and provides both Facebook and the mobile app developer with knowledge of how their ad spend went.

Is that "spyware"? Some would call it merely wanting to know if your marketing budget was wisely spent - I suppose a lot depends on what data it collects on people.

More info: [https://developers.facebook.com/docs/app- ads](https://developers.facebook.com/docs/app-ads)

<comment><USER6> >Is that "spyware"?

Yes, absolutely.

It uses energy and bandwidth I paid for to surreptitiously transmit my information for use which will solely benefit Facebook and the software developer.

<comment><USER7> I feel like I'm in the minority here -- but I don't understand the problem.

Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this. You always have the choice to not install the app (if you don't want to).

This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.

<comment><USER6> >Software developers want to know whether their existing marketing methods are effective. The FB SDK helps with this.

As you mention, this is something the _software developer_ want, not necessarily the _user_.

>You always have the choice to not install the app (if you don't want to).

This argument may have some teeth if directed toward a user in our industry. Depending on the scope of the particular software in question, the majority of users is likely to be those outside the software industry; the layman. The argument falls flat when the other person doesn't have the necessary understanding to be able to perform thoughtful analysis.

>This also helps developers make sure their marketing is effective and reaching the right people, which seems like a win-win to me.

That may be one reason this practice is in-use. I don't see how it makes the difference: the software developer continues these practices with no consideration of their user, much less the user's consent or indication anything is going on at all. It's all about what the software developer wants, not the user and that's not OK.

<comment><USER8> This very same argument would apply to, say, "5% of the price of my dinner goes towards healthcare for the waitstaff. That's something the company wants, not something I want."

There are much better argument for it being spyware, e.g., that it spies. It's not a very strong argument that a thing is bad simply because it helps the provider of the thing.

<comment><USER9> I certainly don't want 5% of the price of my dinner going to healthcare costs. Don't tell me that's something that actually happens where you live?

<comment><USER10> Is your objection the 5% or that it's going to healthcare costs?

<comment><USER4> I think the objection is that for most of western civilisation, healthcare costs are paid for by taxes not employers

<comment><USER8> OK, but those taxes are paid by someone (usually business taxes). I am strongly in favor of government-funded healthcare but the number of countries where the government can be funded by, like, drilling oil is very small, so I think my argument stands - some portion of the money I spend on dinner is going not towards things that directly produce my dinner but things that someone else thinks is worthwhile. Even if I agree with it, it's not my decision.

<comment><USER9> Structuring something in the interests of what benefits them won't necessarily align with what benefits you, since the actual structure of the relationship matters, as brief regard to my flippant comment on your analogy. It isn't about what % of dinner goes to healthcare - it's (and I was assuming some hideous employer-pays healthcare system) rather about the system which is built to align incentives and benefits in certain ways. That is, I stand to lose in many situations if healthcare is provided directly by the payments of my customers, or whatever. Likewise, with privacy, it isn't just that 'it spies', it's that what it purports to aid me in is likely coincidental. Just like a targeted advertisement actually really benefiting me is effectively irrelevant to the advertiser - it's just nice if our incentives happen to align, for one brief moment. :-)

It isn't so nice when they don't.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Why is facebook spyware part of Spotify. I signed up to Spotify via email not facebook login.

<comment><AUTHOR> i mean, they offer FB sign in in the app, so the FB SDK is bundled with the app binary. looks like the mere presence of the library is causing crashes. someone on a related GH thread noted they commented out the code invoking the FB SDK but the issue remained.

<comment><USER11> Yeah these SDKs are siphoning off data without authorization like your location, songs you listen to and who knows what else (eg other processes or apps running on your phone). Eg the latest iOS exploit allows any app to get access to all SMS data. Tech companies of today trample upon individual privacy openly. Amazing!

<comment><AUTHOR> i'm by a longshot no facebook fan but... are you sure the SDK can actually siphon out what songs you listen or your location from the app it's sandboxed in (which, BTW, is in its own sandbox from an iOS system POV, and also has its own set of permissions)?

<comment><USER11> Well the reason FB/Foursquare/Google etc add these to 3rd party apps is so they can get data. Example if you visit a website which has a Facebook like button, your browser fetches the js files/which maybe even makes an API call to let FB know your IP (and hence location). All this data is fed to the giant system that feeds you ads. Adding their SDK to other apps/sites (even if there is no user facing need) is a common strategy used by most big companies to get data. In return the app that puts in the SDK gets $ from the company.

<comment><USER12> You have no idea what you're talking about. Apps use the Facebook library because a good portion of end-users want to be able to login with a Facebook button --or Google, or whatever that doesn't require them to create a user/password account. It's just that simple.

<comment><USER11> I have been witness to such business partnerships to embed SDKs to siphon telemetry/other data. The world is not as simple as you think...

<comment><AUTHOR> well, this would be extremely believable

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> We found a couple workarounds while Facebook was busy fixing this.

1\. Airplane mode 2\. Block facebook.com as adult content under Settings | Screen Time | Content Restrictions | Web Content | Limit Adult Websites | Add a site. 3\. Block facebook.com at your router.

Option 2 could be helpful if you want to block it for privacy reasons.

<comment><USER14> Does the adult filter work in apps? If so this seems like a lovely workaround for the lack of firewall.

<comment><USER13> It worked to fix this, so I'm assuming so.

<comment><USER15> I tried adding spotify.com as a limited adult website and I can still use the Spotify app normally. So either I'm missing something or it can't be used as a firewall.

<comment><USER16> You might be using their magical p2p network.

<comment><USER15> I tried with various app and I can't break any of them. I'd be really interested in a firewall for iOS

</comment></comment></comment></comment></comment></comment><comment><USER17> Perhaps this outage will raise awarenesses more broadly as to the prevalence of "non essential" third party SDKs like these, and the risk that their failure can significantly impact on the wider ecosystem.

I can't imagine Apple will be all too pleased by this. Perhaps time for them to look at clamping down on SDKs that make remote network requests? (Given they have their own private sign in system now as well, they might even have a secondary incentive)

<comment><USER18> Not likely. FB has made it too easy, and developers are lazy. For the marketing/sales/PR types of the company that made the app, the info the SDK returns is exactly the type of information they want/need. At the end of the day, the "morality" of a developer will always come second to the sales/marketing/PR people. After all, you're just a developer, and there's a line a mile long of people waiting to replace you.

</comment></comment><comment><USER19> I block all Facebook domains with the NextDNS iOS app — didn't seem to be affected by this. Blocking spyware has its perks.

<comment><USER20> Ditto!

        facebook.com
        fbcdn.com
        fbcdn.net
        fbsbx.com
        fb.com
        instagram.com

(^ These won't break WhatsApp)

NextDNS automatically blocks subdomains.

More info here: [https://qz.com/1234502/how-to-block-facebook-all-the-urls- yo...](https://qz.com/1234502/how-to-block-facebook-all-the-urls-you-need-to- block-to-actually-stop-using-facebook/)

</comment></comment><comment><AUTHOR> Also: Tinder, Venmo, GrubHub (think of the botched deliveries heh), and more. An ongoing list here: [https://twitter.com/aburninghilll/status/1258169688959352832](https://twitter.com/aburninghilll/status/1258169688959352832)

Also see: [https://github.com/facebook/facebook-ios- sdk/issues/1373](https://github.com/facebook/facebook-ios-sdk/issues/1373)

</comment><comment><USER21> We have a few thousand apps on the App Store and got bit by this today.

The SDK is very useful for a smooth login experience if the user has the Facebook app installed, because your app can offer Facebook as a login option, then just pop the user over to the Facebook app, they can tap "okay" (or whatever), and jump back to your app.

That said, we're going to rip this thing out of our apps ASAP. No framework should be calling network code in "+load". The convenience for the user (and the dirty tracking Facebook apparently does) is just not worth the trade-off of handing our app's stability over to Facebook.

<comment><USER22> How can one developer have thousands of apps? It sounds just like a giant scattergun for malware. There are not 1000 distinct useful ways to use an iPhone.

<comment><USER23> A consulting company or a company that makes "white label" apps like for restaurants or stores.

<comment><USER22> Can we agree that each restaurant having a separate app is one of the dumbest outcomes imaginable?

<comment><USER24> That's not how it actually is. Apple actually rejects those type of template apps. The restaurants use an ad-hoc way of installing the apps. So those apps are only available to the restaurant for example.

<comment><USER25> No, Apple accepts white label applications. Their requirement is that if you're going to release a white label application, then it should be released under the customer's own individual Apple developer account rather than having them all under one developer account.

</comment></comment></comment></comment></comment></comment><comment> a-wu I hope that this incident and the Zoom incident will motivate app developers to remove the Facebook SDK when possible.

<comment><USER26> In most cases, it's not really up to the app developers.

</comment></comment><comment><USER27> From the crash log, it looks like the server response it's getting back is missing a field that the SDK wants. Facebook should be able to fix this on their end?

Edit: from the issue it looks like they've done something, but people are still reporting crashes…

<comment><USER28> The description is definitely weird. Any server change change should never crash an app, which should have proper validation for all data that it receives.

Thereby the mitigation "to update something on the server that takes time to propagate" also sounds wrong more like a rollback/mitigation than a fix of the actual issue.

</comment></comment><comment><USER29> This comment made my day LOL [https://github.com/facebook/facebook-ios- sdk/issues/1374#iss...](https://github.com/facebook/facebook-ios- sdk/issues/1374#issuecomment-624939133)

</comment><comment><USER30> I really think the use of remote, undocumented and unknown code just needs to end. Including the SDK which can make changes invisibly should never be an acceptable practice.

And it's why I am weary of installing apps in general. Tip: use f-droid, check privacy exodus and stick to the browser where possible, where you can have much greater control, and not be spied on by FB.

</comment><comment><USER31> Hi everyone,

Please use the oauth-only version for login and strip the facebook SDK garbage from your apps. It seems it's not worth the trouble.

<comment><USER32> The Facebook SDK is a single point of failure it seems.

If you must integrate Facebook, it is better to use OAuth + API and then control every call, only necessary ones needed i.e. login, friends, maybe game leaderboards, profile photo, etc.

Not sure why people are still putting the Facebook SDK in their apps, it is basically malware and tracking for authoritarian ends [1][2].

Engineers are supposed to be anti-authoritarians.

Engineers are supposed to be into decentralization and distributed systems, and not have single points of failure like libs with hard crashes that inject network calls that don't fail gracefully before your app can even launch.

[1] [https://www.nytimes.com/2017/11/05/world/yuri-milner- faceboo...](https://www.nytimes.com/2017/11/05/world/yuri-milner-facebook- twitter-russia.html)

[2] [https://www.theguardian.com/news/2017/nov/05/russia- funded-f...](https://www.theguardian.com/news/2017/nov/05/russia-funded- facebook-twitter-investments-kushner-investor)

<comment><USER24> > Engineers are supposed to be anti-authoritarians

Strongly disagree on this. Exact opposite maybe but I don't want to generalize. Modern authoritarian tactics are pretty much impossible without engineering.

<comment><USER33> Wait, are you saying that (software) engineers should _actually_ be authoritarian? And you suggest this is because otherwise "authoritarian tactics" wouldn't work?

<comment><USER24> No, I did not say that. I am not even talking about what they should or shouldn't be. There's no set rule which says engineers are supposed to be pro- authoritarians or anti-authoritarians.

I was disagreeing with what the parent said: "Engineers are supposed to be anti-authoritarians."

I take that to mean that the person thinks engineers are anti-authoritarians - which is simply false and not what happens in real life. Engineers are often enablers of authoritarians.

And this is a bad thing but just fact of life. Humans are flawed and greedy for power. There are higher chances of someone with power to abuse it (engineer in this example but could apply to others too).

<comment><USER33> Ah, right. Your wording of "Exact opposite maybe" made me think you were suggesting that.

I agree that what engineers _should_ be is different from engineers _actually_ are, and that today you see how software is definitely enabling authoritarian rule. I wish it wasn't so, and I guess that's what OP wanted to communicate.

</comment></comment></comment></comment></comment></comment><comment><USER34> Is there a comprehensive list of applications that have the FB SDK in them so that I can decide to not install those?

Does Apple use FB SDK in their apps? I think not, but can someone confirm?

</comment><comment><USER35> Same thing happened with Google Maps SDK just a few weeks ago.

[https://www.reddit.com/r/androiddev/comments/g6t8fu/google_m...](https://www.reddit.com/r/androiddev/comments/g6t8fu/google_maps_sdk_error_started_popping_on_last_hour/)

</comment><comment><USER36> > This is insane, half of the apps on my phone aren't launching!

> Please move slower and break fewer things. Thank you.

</comment><comment><USER37> Maybe this will motivate product owners, developers, marketers, to start thinking before implementing a dozen of SDKs in a mobile app (or website). It's understandable when you need some analytics/crash reporting, but it becomes a privacy and ethics question when a lot of data is wandering around, and even better, crashes your app. And the users will blame you, they don't even know how many SDKs are there and what they are doing.

<comment><USER38> > And the users will blame you

Rightfully so. If you add an SDK to you app, it's your fault if the SDK causes your app to crash.

</comment></comment><comment><USER39> A similar thing happened with Google Maps recently: [https://twitter.com/GergelyOrosz/status/1253608276660551680](https://twitter.com/GergelyOrosz/status/1253608276660551680)

Not sure what the lesson is, other than that you can't trust third party code, even if it's written by the worlds largest companies!

</comment><comment><USER40> Waze, a company owned by Google was also broken and force crashing over and over again for a few hours.

Whenever I hear of some Facebook offering all I think of is when you dance with the devil, you shouldn't be surprised when you get burned.

</comment><comment><USER41> Wow. At almost exactly the time that report was filed ... about 30-40 Minutes, my spotify ios app started crashing. I was listening to a song on my desktop, and wanted to share it on my instagram so I went to the app to do it. everytime I opened up the app it would crash immediately, I restarted my phone, tried it again, and it was fine for about 5 seconds and then crash ... crash ... crash ...

I filed a report with Spotify and by the time they got back to me, the problem had gone away ... I thought it was very odd, until I read this post ...

I guess now I know what happened.

</comment><comment><USER42> This is one of several reasons why I refuse to install apps unless I absolutely must. You have no way of knowing what kind of spyware is bundled with them, and there's no way to block it (like you can in a proper browser with uBlock Origin).

</comment><comment><USER43> Is there a postmortem available on this? Perhaps I missed it in the sea of comments.

<comment><USER44> I've always wondered how the word postmortem found its way into tech. Are we calling code reviews autopsies now?

</comment></comment><comment><USER45> Looks like it's back to normal (ish) now. I'm curious as to what kind of testing they have that this wasn't caught by a test suite though--login integration seems like an incredibly important thing to not break.

</comment><comment><USER46> Is there a list somewhere of all the apps importing the spyware Facebook SDK?

</comment><comment><USER47> For all the privacy stuff that Apple does on Safari, it does absolutely nothing against the tracking issues in the mobile app ecosystem.

The unspoken rule is because apps make money for Apple and websites don't.

</comment><comment><USER48> Ouch. Not knowing how the iOS apps are written, two questions come to mind:

1) Why wasn't the SDK written to tolerate bad data and fail gracefully?

2) Could clients integrating the SDK be written to tolerate failures like this?

</comment><comment><USER49> I had to remove the SDK a few months ago due to it causing crashes. If I remember correctly they injected some code into didSelectRowAtIndexPath for table / collection views...Looks like its fixed now but I definitely won't be adding it back, [https://github.com/facebook/facebook-ios- sdk/issues/1318](https://github.com/facebook/facebook-ios-sdk/issues/1318)

</comment><comment><USER50> How to gain market share? Release a breaking server-side update and "forget" to inform other vendors in time so that their apps crash, while yours do not.

</comment><comment><USER51> Zoom dodged this bullet.

<comment><USER52> And got so much flak for it. How much "zomg you're spying on me" press are the other 50% of the iOS ecosystem going to receive for doing the same thing Zoom did, going on a decade.

<comment><USER14> Just because others are doing it doesn't make it okay.

</comment></comment></comment><comment><USER12> You beat me by a couple of minutes. Dear Facebook: Please move slower and break fewer things. Thank you very much.

</comment><comment><USER53> This is a good resource to see who is being impacted[1].

[1] - [https://downdetector.com](https://downdetector.com)

</comment><comment><USER54> This is a nice demonstration of why exceptions, in particular untyped exceptions, are a major liability.

</comment><comment><USER55> I had no idea why my app was suddenly crashing multiple times all of a sudden. God fucking damnit.

</comment><comment><USER56> Hm my whatsapp crashed midcall today, wonder if they use the Facebook SDK or something else

<comment> alex-wallish Given that whatsapp is owned by facebook, that seems very likely.

<comment><USER56> that's exactly why I was wondering if they use something else, a better internal shared library for accessing facebook services

</comment></comment></comment><comment><USER57> Move fast and break other things

</comment><comment><USER58> 18 minutes ago:

> _Server side change is already reverted. The crash will vanish._

<comment><USER59> > Still crashing 30 minutes after your revert. Are you sure you reverted the > right thing?

</comment></comment><comment><USER60> Ah that is what is happening!!! Thanks HN. :)

</comment><comment><USER61> Guess Joma was right: [https://www.youtube.com/watch?v=rR4n-0KYeKQ](https://www.youtube.com/watch?v=rR4n-0KYeKQ)

</comment><comment><USER62> At least they moved fast.

</comment><comment><USER63> This is surely a competition violation, wordly blocking competing products from operating.

</comment><comment><USER64> guess we're back to "move fast and break things"

<comment><USER65> Move slowly with unstable infra.

</comment></comment><comment><USER66> But all of the engineers passed LeetCode, how could this be?

<comment><USER67> Facebook engineering generally is super competent. Leet code or not, such slip ups are bound to happen from time to time. True test of competence would be these mistakes don't repeat and that they learn from it, which I'm pretty sure they would.

<comment><USER68> So you're saying we can be confident they won't break democracy again?

<comment><USER69> What does that have to do with engineering talent?

<comment><USER68> It has everything to do with it. Software engineers should take care to consider the risks and potential downsides to the shady products they build with that talent that aren't just downtime or tech debt but the larger impact to society itself. Silicon Valley prioritizes technical talent while completely disregarding strength and quality of character.

</comment></comment></comment></comment></comment><comment><USER70> But Apple advertising says we have privacy!

</comment><comment><USER71> good

</comment><comment><USER72> Unpopular opinion: bugs happen. Be bold.

<comment><USER73> What's "be bold" supposed to mean?

<comment><USER27> Break every application that links your SDK, of course.

</comment></comment></comment><comment><USER74> I'm calling it "lefb-pad"

</comment><comment><USER75> Is this a library or an SDK? Why on earth would you install an SDK on an end- user's phone?

<comment><USER76> The SDK contains the library. I guess in app developer circles these terms are conflated.

</comment></comment><comment><USER77> 10 to 1 it is going to be about SDKs generated from php with its bizzaire associate arrays.</comment>


$1 Bus with WiFi, Beats $4 Gas - <AUTHOR> http://www.time.com/time/business/article/0,8599,1812012,00.html

<comment><USER2> I live in Calgary, Alberta. For a long, long, long time there has been a company doing the exact same thing between Calgary and Edmonton (a 3 hour drive). I love it- in fact, I take it instead of a plane: its more comfortable, and when you factor in baggage/security, only takes about 20 minutes extra (not to mention it saves the organisation I work for a couple hundred).

<comment><USER3> Amazingly the nicest busses I have been on are in Mexico (Tampico/Monterrey). They have huge comfortable brand new Merc busses available, with fully reclining seats. No wifi yet but some busses have plane-style entertainment systems.

The contrast between those and Grehound McAllen-Houston was amazing, more Spanish was required on the US side of the border, and it was hard to immagine the bus was road legal.

<comment><USER4> You should come to Turkey and ride a bus. They know how to run an affordable and effective bus system. (Effectivity is a rare sign in Turkey though.)

You also get free snacks and beverages on busses there.

</comment></comment></comment><comment><USER5> Took the Lucky Star to Boston for $15. Took the BoltBus back to NYC for an extra $5. It worth it.

Free wifi, power outlet and roomier seats.

Be sure the bus lands at locations near the local transportation lines.

</comment><comment><USER6> Its £1.34 a litre where I am (more or less $10 a gallon) yet public transport usage has more or less remained the same, people have instead opted to just travel less.

<comment><USER3> Thats partly because bus fare (at least here in the north) has been going up just as fast as petrol prices.

As my current place pays overtime I would need the cost of petrol to go up to 5gbp/litre (~$40/gal) without an increase in the cost of the bus to make catching it worthwhile, factoring in the longer trip times.

Decent wifi and a nicer bus would certainly change my view on the tradeoff though. The sooner they make the top deck a first class, recliner seating, no child zone the better :)

</comment></comment><comment><USER7> Why, I do believe I've spotted the logo on that bus somewhere else before: [http://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Bri...](http://upload.wikimedia.org/wikipedia/commons/thumb/3/31/British_Union_of_Fascists_flag.ant.svg/800px- British_Union_of_Fascists_flag.ant.svg.png)

<comment><USER8> Well, they are trying to compete with a British bus line that started the same low cost service in the US two years ago...

<comment><USER9> But megabus lacks comfort and wifi, at least here in the UK.</comment></comment></comment>


Adora Svitak: What adults can learn from kids - <AUTHOR> http://www.ted.com/talks/adora_svitak.html

<comment><USER2> A timely reminder to forget about the sometimes irrational limitations we put on things as adults.</comment>


NSA Statement: NSA Stops Certain Section 702 "Upstream" Activities - <AUTHOR> https://www.nsa.gov/news-features/press-room/statements/2017-04-28-702-statement.shtml <comment><USER2> Excellent what I'd expect from my government. A ways to go but this is progress to some extent.</comment>