AQAP trying to hide explosives in laptops, official says - <AUTHOR> http://edition.cnn.com/2017/03/21/politics/electronics-ban-devices-explosives-intelligence/index.html <comment><AUTHOR> AQAP = Al-Qaeda in the Arabian Peninsula

[https://en.wikipedia.org/wiki/Al- Qaeda_in_the_Arabian_Penins...](https://en.wikipedia.org/wiki/Al- Qaeda_in_the_Arabian_Peninsula)

</comment><comment><USER2> I'm sure it has nothing to do with this: [https://theintercept.com/2017/02/09/airline-competition- trum...](https://theintercept.com/2017/02/09/airline-competition-trump/)

<comment><USER3> From [http://www.pcmag.com/commentary/352511/airline- electronics-b...](http://www.pcmag.com/commentary/352511/airline-electronics- ban-is-protectionism-not-security)

 _"..business travelers assume they'll have access to their laptops on flights. A tech-free, or even a tech-lite flight isn't much of a flight at all in 2017. So by targeting our gadgets, the government can take an entire airline down."_

From [https://www.washingtonpost.com/news/monkey- cage/wp/2017/03/2...](https://www.washingtonpost.com/news/monkey- cage/wp/2017/03/21/trump-wont-allow-you-to-use-ipads-or-laptops-on-certain- airlines-heres-the-underlying-story/?utm_term=.27c5dbb62f88)

 _" These three airlines, as well as the other airlines targeted in the order, are likely to lose a major amount of business from their most lucrative customers — people who travel in business class and first class. Business travelers are disproportionately likely to want to work on the plane — the reason they are prepared to pay business-class or first-class fares is because it allows them to work in comfort. These travelers are unlikely to appreciate having to do all their work on smartphones, or not being able to work at all. The likely result is that many of them will stop flying on Gulf airlines, and start traveling on U.S. airlines instead.

As the Financial Times notes, the order doesn't affect only the airlines' direct flights to and from the United States — it attacks the "hub" airports that are at the core of their business models. These airlines not only fly passengers directly from the Gulf region to the United States — they also fly passengers from many other destinations, transferring them from one plane to another in the hubs. This "hub and spoke" approach is a standard economic model for long-haul airlines, offering them large savings. However, it also creates big vulnerabilities. If competitors or unfriendly states can undermine or degrade the hub, they can inflict heavy economic damage."_

<comment><USER4> It's important to get these booby trapped laptops out of the cabin and into the hold because uh...

<comment><USER5> Because the useful volume of a laptop is somewhat limited and in the cabin you can ensure placement against the skin of the aircraft. In the baggage hold it will have been scanned better and by a process that is less susceptible to compromise by a single person, it will have been placed in a somewhat random position inside another container with a fragmentation blanket around it, etc. Yes, you can certainly bring down an aircraft by putting a bomb in luggage, but a lot of effort has been put in place to prevent this exact thing.

<comment><USER6> > In the baggage hold it will have been scanned better

What information is this statement based on?

<comment><USER7> In some airports, your technology will even be removed from your luggage by a helpful and diligent TSA or airline employee, and they will take it back to their own home for a very thorough functional check that may take years to complete.

[http://blog.tsa.gov/2008/02/tsa-our-officers-public-and- thef...](http://blog.tsa.gov/2008/02/tsa-our-officers-public-and-theft.html)

CNN, Chicago Tribune, and ABC News ran a few stories about this "extra-special luggage screening" around 3-5 years ago, which I won't link because of autoplaying videos and/or slideshows.

</comment></comment></comment></comment></comment></comment><comment><USER8> Let's accept that for a moment, for the sake of argument.

I want an explanation for why AQAP won't just hop on an airline unaffected by this ban, drive the bomb to a country unaffected by this ban, or put a timer/altimeter on the laptop bomb that's in the cargo hold.

<comment><USER9> When reading comments like these, I can't help but wonder what the public response would have been if the government had taken action against a vague hijacking threat in Aug-Nov of 2001.

<comment><USER10> Fair point, but most likely it would have been ineffective. sept 11 was led by highly trained and organized people belonging to a large group. Had the american government taken actions against hijacking with knifes, and they would probably switched to a back-up plan (say, putting bombs in laptops for instance ;).

And that's exactly what the gp is talking about.

<comment><USER11> _sept 11 was led by highly trained and organized people_

You wrote that as fact, but is it? Those "highly trained" guys could barely fly a small plane, but where able to fly huge airlines at top speed.

<comment><USER12> They didn't even train to land the planes - they weren't going to have to know that. They knew precisely enough to cause damage and no more. So trained, but not 'highly'. More like, went through the tutorial until they could take off and steer a little.

<comment><USER10> Yes, and for terrorists that's what I call «highly trained». Remember, last year a terror attack failed in France because the guy just accidentally shot _himself_ in the leg !

Most terror attack in western countries where commited by lone wolves or tiny groups. 9/11 was incredibly well-thougth in comparison.

<comment><USER11> One interesting aspect of 9/11 is we never did get to see a shot or video of the hijackers as they boarded the flights. Or were cameras not installed at the gates back then?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Airlines and economic politics and terrorism threats aside, letting laptop batteries in airplane cabins at all has to be just the craziest hypocritical lapse in air travel safety ever.

The very idea that your personal incendiary device is totes A-OK because it also plays movies seems completely bonkers. It's like a million hyperlocalized somebody-else's-problem fields wrap around portable electronics that we all just collectively ignore.

Hell, continue to forget the explosive capacity of these commonplace electronic grenades for a moment. The chemical fumes produced by lithium battery fires are absolutely terrifying.

You can quickly vent the storage compartment and nobody even has to know. In the absolute worst case you can dump the luggage and cover losses with insurance. You just can't do the same to the passenger compartment.

I want the rules to be fair, and I want the rules to make sense, but damned if I don't find myself more and more wishing it were a complete ban.

<comment><USER14> As with any ban, I question if the response is proportional to the threat. Yes we have all these chemical devices with us (hell you're flying on a burning tank of jet fuel, make no mistake), but the actual number of exploding electronics is so low we don't bother thinking about it. Even the Note 7, which was outright banned on flights, had only a couple hundred incidents, in a market that transports millions of phones a day (not to mention other electronics) routinely for _years_.

In fact, let's compare apples-to-apples how likely you are to die from some of these things in a given year [1]:

* Air accident (any cause): 1 in 767,303 * Traffic accident: 1 in 8,938 * Fall from ladder: 1 in 752,688

In fact, I'm having a hard time finding statistics that indicate passenger consumer electronics are a threat at all. Nearly all plane crashes are some form of human error from the flight crew and mechanical failure. Even the Note 7 didn't bring down planes, despite actually exploding on them several times. Even that ban isn't about the lethality, but the inconvenience and delays suffered because they _must_ check for worse problems.

So to reiterate my point: What is the threat you are trying to solve?

EDIT: Formatting

[1]: [http://www.iii.org/fact-statistic/mortality- risk](http://www.iii.org/fact-statistic/mortality-risk)

</comment></comment><comment><USER15> The hardware workaround seems obvious enough:

1\. Negotiate a "standard laptop" voltage, connector, and max current. Parties at the table: Boeing, Airbus and Lenovo, HP, ...

2\. Redesign laptop packaging to function well with main battery detached.

3\. Refit airliner interiors to supply "standard laptop" power to each seat.

#3 could take a while -- retrofitting a few pricey front-cabin seats during the interim looks like a profit opportunity for someone.

<comment><USER16> Many long haul flights of Tier 1 carriers already have AC power at the seats, so #1 and #3 have already been taken care of.

</comment></comment><comment><USER17> No one's talking about that fact that the US trusts Abu Dhabi to have a customs port there[0], but not enough to let a passenger travelling via Abu Dhabi to put a laptop in their carryon ...

0\. [http://www.etihad.com/en-us/before-you-fly/us- preclearance/](http://www.etihad.com/en-us/before-you-fly/us-preclearance/)

</comment><comment><USER18> Didn't Samsung already do this with their phones?

</comment><comment><USER19> Is this true or a fig leaf. Hard to know for sure, but the fact that the restrictions do not apply to passengers on American airlines certainly doesn't decrease my skepticism.

<comment><USER20> The ban applies to all flights from the cities in question. If it doesn't apply to American airlines, it's only because no American airlines have direct flights from those cities.

Edit: this is only half right. Part of the ban is for specific cities, and part is for specific airlines: [http://www.usatoday.com/story/travel/flights/todayinthesky/2...](http://www.usatoday.com/story/travel/flights/todayinthesky/2017/03/21/what- fliers-need-know-airline-laptop-ban/99447660/)</comment></comment>


Tissue Engineers Hack Life's Code for 3-D Folded Shapes - <AUTHOR> https://www.quantamagazine.org/tissue-engineers-hack-lifes-code-for-3-d-folded-shapes-20180125/ <comment><USER2> Very cool. I learned about the role of actin fibers within the cell, and which ultimately respond to tension in the extracellular matrix, in controlling growth and reproduction. If we could make self replicating artificial tissues, we'll probably need that kind of mechanism in place.

[https://www.cellsignal.com/contents/science-cst-pathways- cyt...](https://www.cellsignal.com/contents/science-cst-pathways- cytoskeletal/regulation-of-actin-dynamics-signaling-interactive- pathway/pathways-actin)</comment>


Apple Watch - <AUTHOR> https://www.apple.com/watch/ <comment><AUTHOR> Did anyone notice (on safari) How the background of the chrome window is translucent ? I've never seen this before.</comment>


Please review my project - <AUTHOR>

We created a simple tool for asking quick questions and getting extremely fast answers to that question. The generated url for the question is easily shareable.
We would love some feedback on our project so we can improve it and make it even more fun and simple to use.
The url is http://fastask.it
Thanks in advance! <comment><USER2> You forgot to escape your HTML output.

[http://fastask.it/%3Cscript%3Ealert%28%22asdf%22%29;%3C/scri...](http://fastask.it/%3Cscript%3Ealert%28%22asdf%22%29;%3C/script%3E)

Also, there's SQL injections too:

[http://fastask.it/%27](http://fastask.it/%27)

[http://fastask.it/%27%20OR%201=1;--](http://fastask.it/%27%20OR%201=1;--)

And you can vote more than once, because there's no server-side check: (ignore the question text)

[http://fastask.it/register_votephp](http://fastask.it/register_votephp)

Also, including a slash in a question (like "Red is good, yes/no") breaks your layout due to relative paths:

[http://fastask.it/a/b](http://fastask.it/a/b)

The maximum length of questions is also only validated on the client. This question is longer than the normally allowed length:

[http://fastask.it/asdf-asdf-asdf-asdf-asdf-asdf-asdf-asdf- as...](http://fastask.it/asdf-asdf-asdf-asdf-asdf-asdf-asdf-asdf-asdf-asdf- asdf-asdf-asdf-asdf-324234324432432324432234234)

Your server side cuts too long questions off at some point too; this was originally 8kb of periods, plus the string "8kb":

[http://fastask.it/8kb](http://fastask.it/8kb)

I think it's now 225 periods, so that might be the size of your "ask" column in the question table.

Also, if you click a vote button really fast you can vote multiple times (until a request success callback is called and the button is faded away).

Also, the "No"-button seems to have stopped disabling itself entirely, at least for me.

You should probably read up prepared statements for MySQL, about input sanitizing, and security in general :)

In terms of the non-technical side: I had no idea what was going to happen after I clicked "Create". If you promise Instant answers, why would the button be named "Create" and not "Answer"? But the questions are not answered _Instantly_ , so I would remove that term from your entire site.

I'd term it "polling" instead of "asking a question"/getting "answers" as well, since it's just yes/no. And what use-cases do you have in mind? If it's for group emails or quick polls or whatever, perhaps add a comment box for responses that are more than just yes or no.

</comment><comment><USER3> HI

I think it should say get instant yes/no answers to simple questions.

A border round the input box might be worth while, but I am old school!

Good luck with it!

</comment><comment><USER4> If you type a "?" in the textbox it generate the following link: "[http://fastask.it/"](http://fastask.it/"). I think that in that if the question has no printable characters (?, space, enter) you should behave as if no answer is entered.

What do you think?

</comment><comment><USER5> [http://fastask.it/%3Cscript%3Ealert%28'test'%29;%3C/script%3...](http://fastask.it/%3Cscript%3Ealert%28'test'%29;%3C/script%3E)

This link is throwing a PDO exception and has exposed your server path which is potentially dangerous.

</comment><comment><USER6> It's very simple. But your description is unclear: >a simple tool for asking quick questions and getting extremely fast answers to that question.

It's really a tool for creating and sharing simple yes/no polls.

</comment><comment><USER7> Try [http://www.coverity.com/](http://www.coverity.com/)

</comment><comment><USER8> Clickable: [http://fastask.it](http://fastask.it)

</comment><comment><USER9> You should make it obvious that it needs to be a Yes or No answer question

<comment><USER4> Totally agree

</comment></comment><comment><USER10> [http://fastask.it/am-i-gay](http://fastask.it/am-i-gay)</comment>


Show HN: Swift Demand – A Basic Income Experiment - <AUTHOR> https://www.swiftdemand.com/ <comment><USER2> Why "Legal First Name" and "Legal Last Name" for me this threw up warning flags. Why do you need to know that?

What's to prevent me from lying? Also, with no "work" (cpu or human) required to get coins there's no incentive to NOT lie and just make a ton of accounts to multiply your effective daily income.

Basic income is a great concept, but the cash isn't magically created. The govt's don't just print new cash. if they do they cause inflation which devalues the current cash that's in circulation. every day you put more "money" into circulation you're devaluing the money that's already there. This just seems to violate fundamental economic concepts. I don't see why anyone would want to take this in exchange for goods or work.

<comment><AUTHOR> For Swift Demand to work your account will need to be completely tied to your true identity. Initially the methods of verification aren't very strong to prevent any unneeded friction for early adopters of the service. Once Swift Coins start having real value I will be placing much stricter rules and requirements for identity verification. Starting with extremely strict regulations is both hard to enforce at the start and will harm the ability for Swift Demand to succeed.

Adding more money into the economy will constantly devalue it, you are correct. As I mentioned in another comment in order for this to work there needs to be speculation that the currency eventually will become more valuable and people start to buy it as a form in investment in a similar style to how bitcoin started. Once value has been established and new coins are created at a constant pace the hope is that it will be usable in the same fashion as any other form of currency.

Government due indeed print new cash, it is what causes the constant inflation that is present for all major currencies. All of your arguments appear like they would be the same for other real world currencies that do indeed function normally. There's a decent chance that it will fail, but I believe it's worth it to try.

</comment></comment><comment><USER3> This looks really interesting. I _think_ I get what you are trying to do. Just want to give a bit of feedback:

Even after clicking through "Learn More" and your FAQ, I still wasn't sure what this is or how it works. I am familiar with online currencies and basic income, so I would imagine a visitor to the site less familiar with this stuff would be even more confused.

I get it's an "experiment" and TNSTAAFL and it's still very new. But maybe a sample explanation of how a new user might sign up, receive coins and then use them somewhere would help clarify things.

<comment><AUTHOR> Thanks for the feedback! I really appreciated it.

Is there anything in particular that you would suggest to add to the landing page to clarify it? I was hoping the graphics would give users a basic idea on how exactly it worked. I would like to focus on making the intent as clear as possible so I'm all ears as far as suggestions go.

I would like to make the process more clear with an example, I think this will be much easier to accomplish once I can get a few vendors to agree to use the service for some small items. The site was just released today which is why it's difficult for me to implement this currently. I do agree that having instant feedback of being able to sign up and immediately use coins is crucial for people less familiar with Basic Income to grasp the idea quickly so I will make this a focus of mine.

<comment><USER3> I understand this is very new. As more people visit the site hopefully a lot of feedback will stream in for you. I'm just one person so I can't really suggest what you should add, only where I found things wanting. If you aggregate feedback from visitors and do your A/B testing or whatever system you use, that should point to the right places to make changes.

For example: Your landing page says "You can do whatever you want with them". Imagine a person not familiar with any of this stuff, I could imagine such a person asking themselves, "what can I do with them?" and "what's the catch?"

For someone familiar with online currencies and/or basic income, I could imagine such a person clicking around and finding no info or evidence of a back-end infrastructure that would support this idea. Nor is there any explanation how you expect to give away something every day and have users or vendors want to accept such a thing for something they do know the value of. Play all product launch games you want, but you are asking for people's real first and last name and their email, I don't see experienced early-adopters giving this up without more proof of concept and knowing more about you guys and your plans.

I wish you a lot of success, just wanted to point out two groups of users who might be more apprehensive to sign up and why.

</comment></comment></comment><comment><USER4> Be warned, this is a very very elaborate scheme to phish peoples cc data. If you dig around, you will see that there is a ton of fake blog posts to give it some fake credibility citing the same thing with fake timestamps and such. Once you look into the coin itself, its linked to a bunch of super shady sites and if you want to "cash out" theres only one super shady site that requires you to enter your cc number cvv and expiration date. Wonder why they need that :)

<comment><AUTHOR> This is complete nonsense. There are no blog posts about SwiftDemand nor is there any place where you have to enter in sensitive data. If you want to make claims like this please cite sources instead of being an "online detective".

Edit: I just did some digging myself, it appears that there is another currency called Swiftcoin out there that is based on the blockchain that I was not aware of. Please be aware that this Swiftcoin is in no way related to Swift Demand. I may need to change the name of Swift Demand's currency to avoid people accidentally assuming these are related.

Second Edit: I have updated the website and removed all references to the term Swiftcoin. The website will continue to be SwiftDemand, but the currency will simply be called coins.

<comment><USER4> Sorry for the accusation, but the two sure seemed very similar in terms of naming. One thing I did notice is that your execution of the website was leagues away from the rest of the guys but I just assumed they uped their game. I'll play along with the project since if it is legit is, it is interesting to me and would provide value.

Good luck with the project. Also if you need extra input feel free to ask.

</comment></comment></comment><comment><USER5> Happy to write anyone a poem at the rate of 100 Swiftcoin per Haiku. Simply respond to this post with a subject for the poem and transfer the 100 to #Poetry.

<comment><AUTHOR> This is awesome, I'll take you up on that offer. Can you write a poem/haiku about Swift Demand itself? Coins have been sent.

<comment><USER5> Sweet deal. First customer buy one get one free bonus. Is it easy to see I am not a poet?

      Swift demand oh boy!
      Writing poems for a money,
      It gives me such joy.

      It's ideas like these
      that inspire hope for us yet.
      We won't stop growing.

Poems can also be requested via... [http://swiftpoetry.club/](http://swiftpoetry.club/)

Hoping to open it up to other types of poems in the near future.

</comment></comment></comment><comment><USER6> While I disagree with some of the details with your approach, I think this is a great Idea. It really has gotten my mind racing with different solutions for the problems such a system presents. I signed up and will definitely keep an eye on it.

Is there an rss-feed I can add to my rss reader to keep me updatet on new developments?

<comment><AUTHOR> I would love to discuss your disagreements, I've thought a great deal about my implementation, but there may very well be several ways I could improve my approach. Feel free to shoot me an email at email@example.com if you would like to talk more.

I don't have anything set up yet to update people on new developments, but it is something that I'm looking at implementing soon as I continue development. I'll let you know once I set something up.

</comment></comment><comment><USER5> Free stuff! Great!

But I imagine one barrier to this gaining traction is trust. Cryptocurrencies are open source and peer to peer, everyone can see everything that goes on. Do you have any plans on open sourcing the current implementation or perhaps moving to a blockchainlike implementation after the initial experiment?

</comment><comment><USER7> The big problem I see is the 3%. why wouldn't I just use paypal if I wanted to lose 3% per transaction.

<comment><AUTHOR> The 3% is there due to the fact that Swift Demand is trying to be more than just another currency. It's also supposed to be able to act as a way to perform normal day to day commerce. This 3% fee is needed to provide buyer and seller protections as well as support the development of new features for Swift Demand. I'm assuming you are asking why you want to use this over Paypal from a vendors point of view and there are several reasons.

The first one being that Paypal isn't known to very trustable and often freezes funds. The second is that I intend to eventually make a very developer friendly API that lets vendors add Swift Demand to their websites very easily. Early merchant adopters will also have the potential to set it up by allowing people to essentially sign up for their service for free by letting people set up a Swift Demand account and automatically transferring Swift Coins to the vendor for a subscription based service (This means merchants can sell their products without ever requiring a user to break out a credit card which could be a potential large source of extra revenue).

</comment></comment><comment><USER8> Signed up. Would be hard pressed to actually supply any products/services in return for Swift coins though. Cool experiment!

<comment><AUTHOR> Yea, it will be very difficult at the beginning to convince people to actually accept Swiftcoin for services. In order for this to occur there will need to be speculation that coins will be worth a certain amount in the future.

I.E. if a person is willing to make the bet that Swift Coins will become valuable in the future they might try to buy a large amount now for a discounted price so in the future they can turn a profit. Once this begins to occur it will likely become a self-fulfilling prophecy since more users will want to sign up since the coins will have value due to people buying them as an investment. Once the price stabilizes at a reasonable number it can then proceed to be used as a normal currency.

</comment></comment><comment><USER9> send me monies #Shravan</comment>


WP.me — url shortener from wordpress - <AUTHOR> http://en.blog.wordpress.com/2009/08/14/shorten/ <comment><USER2> In a couple of years, we're going to look back at URL shorteners as a fad as lame as the <blink> tag, animated mailbox GIFs, and logos from FlamingText.com.</comment>


Distributed Systems Testing: The Lost World - <AUTHOR> http://tagide.com/blog/research/distributed-systems-testing-the-lost-world/ <comment><USER2> _"..trace logs, a relatively old technique that glorifies printf as First- Class Citizen Of The Testing Guild.."_

I don't understand the stigma attached to logs and debug-by-print. When is a tool that uses x to provide y 'glorifying' x?

I've built and regularly use two tools that rely on logs:

a) I write white-box tests that allow me to check not just what a function returns but specific events in the course of the function running: [http://akkartik/name/post/tracing-tests](http://akkartik/name/post/tracing- tests). This allows me to check, for example, that searching in a sorted array doesn't require double the lookups when the size of the array doubles. It also allows me to test subcomponents without calling them directly, leaving their interfaces underspecified and flexible to change later without needing to modify a bunch of tests.

b) I often debug my programs by dumping a trace and running it through a 'trace browser' which starts out showing just the coarsest level and allows me to drill down in specific places as I want. This 'zoomable' google-maps-like UI gives me all the benefits of time-travel debugging at a fraction of the system engineering it usually takes. (I _still_ can't get the feature to work in gdb..) Try it out:

      $ git clone https://github.com/akkartik/mu
      $ cd mu
      $ ./mu browse-trace .traces/factorial-test

It'll take ~30s to compile the first time you run it (C compiler required on Linux/OS X). Once it compiles, you'll see an ncurses program. Use 'q' to quit, hit enter to zoom into lines (you can see how many lines are collapsed in parens), backspace to zoom out on a line.

These are both things nobody can do on a conventional toolchain, and super easy to build. Maybe print seems trivial because nobody's building tools around it?

</comment><comment><USER3> The best way to test a distributed system is to break it intentionally after you think you have sufficient monitoring to find all the problems. Then you'll know if you have sufficient monitoring.

And if you have an outage where you didn't have sufficient monitoring, then you add it afterwards. But at least by breaking it intentionally you can at least be watching.

<comment><USER4> +1

This is the entire idea behind Netflix's Failure Injection framework ([http://techblog.netflix.com/2014/10/fit-failure-injection- te...](http://techblog.netflix.com/2014/10/fit-failure-injection- testing.html)) which was briefly alluded to in OP's link.

<comment><USER5> Which makes sense considering jedburg works (worked?) for Netflix after he left Reddit.

<comment><USER3> Worked, but yes I was deeply involved in that project.

</comment></comment></comment></comment><comment><USER6> Distributed testing is very important, but based on article doesn't get as much papers on it. Some plausible explanation:

1\. Making things that actual work is industry, which writes very few papers comparing to academia. Academia cares more about design, less about working large scale systems.

2\. Testing is more about well-oiled machinery, less about some super clever algorithm. Testing is more of a craft than art.

<comment><USER7> Let's not forget about the social aspect -- testing is seen by many in the industry as a less prestigious activity, one which you hire barely competent "developers" and can hurt career progression if accepting a job doing it (exceptions always exist).

<comment><USER8> It seems like the marketplace has decided that it's usually okay to push/deliver/ship questionable software. We even have a cute colloquial industry term for this, "MVP". _Minimally_ viable. That's Grade-D beef... by design.

When the focus is pushing out Grade-D goods what's the point of rigorous testing? If you get it wrong, it barely matters. If it matters at all.

Perhaps the social view of software testing is just a corollary to the state of software engineering?

<comment><USER9> I feel like MVP design winning is the market clearly deciding that it values features over stability. I'm curious if the economics of this will change when / if we come to the end of exponential hardware growth.

<comment><USER8> I think to some extent the boundary of friction that's going to grow between software creators and hardware manufacturers as various shapes of Smart- thing-X become more prevalent might ebb this a bit.

Because as more feature-laiden software is written to facilitate growth in consumer and industrial markets that is deployed on something more akin to an embedded device than a PC or server there's going to have to be more rigor applied to the correctness of the software to compensate for how tightly coupled it is to the largely immutable use-specific hardware.

<comment><USER9> Frighteningly possible counter-alternative: continue to ship bad software on embedded devices and just toss network connectivity in there in the event the device becomes popular / customers demand an update.

<comment><USER8> Yeah. I certainly fully expect a certain cross-section that is shaped just like that. Take "Nest" as an example. Unless the "smart" thermostat can somehow manage to burn my house down by turning the heat up way, way too high... then the fact that it's almost comically broken as a "smart" device doesn't really matter. Just keep pushing updates to it.

However, I think there's a growing surface area where our consumer expectations for iteration and features are going to bleed into places that were previously left largely untouched by such demands. "Smart" cars are probably a good example. There's growing and intensifying competition for the ownership of the experience in the cabin/cockpit of the car, and in order to draw lines of competition there's a lot of focus on how to integrate that space with the rest of your normal and your digital lifestyle. That ends up being a place where, to avoid ending up the subject of very public screw ups, some amount of rigor that's applied to the lower-level stack will also eventually bubble up to the feature/application level at the same time that enablement for features/applications (network connectivity, new kinds of input devices, etc.) will end up being forced into the lower levels of the stack. Or at the very least a useful set of stable abstractions and tools will be built to prevent today's software developers from having to care very much about applying that rigor and the abstractions/tools will just take care of it for them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> Having seen both sides, I would argue that academia doesn't really have a subfield that fits distributed systems well (most industry systems span multiple academic fields, from networking to fault tolerance, databases, OS, etc). Not to say that people don't research it, but more people research subcomponents.

Also, I would argue that academia is about 7 years behind industry in this area, and so papers don't match up to reality well.

On the other side, industry testing is usually very specific to the internal product created, and so there is an incentive not to publish anything.

There is some nice academic research outside of CS, notably mechanical engineering, on systems testing. It is pretty applicable. Contracts, sub-unit testing, etc are all anaolgous.

My two cents.

<comment><USER11> Interesting point about the MechE literature. There's a whole academic field of multidisciplinary design analysis and optimization that tries to deal with systems problems. They have a whole suite of tools for coming to grips with the couplings between subsystems. I hadn't ever thought about it in terms of distributed software systems, but it definitely applies.

</comment></comment><comment><USER12> A friend and colleague of mine developed a simple distributed testing framework in JavaScript - [https://github.com/PsychoLlama/panic- server](https://github.com/PsychoLlama/panic-server) (It works in conjunction with Mocha, Jasmine, and possibly other test frameworks - [https://github.com/PsychoLlama/panic- demo](https://github.com/PsychoLlama/panic-demo))

(We work on an open source distributed data sync engine and needed a way to test distributed aspects of that engine - [https://github.com/amark/gun/](https://github.com/amark/gun/))

</comment><comment><USER13> IMO if testing this stuff is difficult, rather than simply understudied, one shouldn't be dismissing formal verification sans evidence.

</comment><comment><USER14> >> There's too many things packed into the concept of testing distributed systems, and that is pretty clear in what came into my Twitter feed

I think this gets closest to the truth. That first slide regarding "testing a microservice architecture" with its complicated block diagram hints at why the level of abstraction is too high to be useful. In the end a distributed system consists of components that have interfaces and which interact with each other through those interfaces. You test the component modules in unit testing, the components themselves at the interface level, and the whole system in end-to- end request and response flow. That latter is assisted by centralized event collection and storage tools like logstash + elasticsearch, but it could just as easily be dumped log files. Whatever works. That's the closest I've personally come to "distributed systems testing."

</comment><comment><USER15> Distributed systems testing is well studied and applied in industry, but there is significant IP and competitive advantage attached to it. For this reason, papers are rarely published. So, this world is not lost to everyone ;). You will see such expert frameworks defined and applied in aeronautics, military and transportation systems, for example. The key challenge is reproducibility of the testing. Central logging of events is not enough, you need some way to enforce or guarantee the global causal ordering of events. Leslie Lamport is recommended reading.

<comment><USER9> It seems there's an under appreciation for pre-digital systems engineering lessons at the ground levels of computer science. There's a lot of cool and really useful smart stuff in there.

</comment></comment><comment><USER16> What worked for me best was to have as thorough monitoring as possible (IO, mem, CPU, per process, etc.) on infrastructure side and as complete event sourcing on the app domain side. It's easier said than done of course, and in a brownfield situation you will never achieve perfection in terms of coverage.

Once that's in place, write tests with selenium or unit test framework with parallel extensions (depending if cases are frontend or backend based) and analyze using home made tools.</comment>


Vim Cheat Sheet Kickstarter - <AUTHOR> http://www.kickstarter.com/projects/maxcantor/beautiful-vim-cheat-sheet-poster?ref=category

<comment><USER2> That sounds pretty interesting. The video was rather funny too. I'd throw in some money, but after a failed start up adventure I'm rather broke at the moment so my "good job" will have to suffice.</comment>


API Without Secrets: Introduction to Vulkan - <AUTHOR> https://software.intel.com/en-us/articles/api-without-secrets-introduction-to-vulkan-preface <comment><AUTHOR> I was trying to find out whether or not SteamOS supports the hardware of the Intel NUC Kit NUC6i7KYK "Skull Canyon" Mini PC when I came across an AMA on reddit by the Skull Canyon team [0] and at one point in that thread someone asked about Vulkan and that's where I found this.

[0]: [https://www.reddit.com/r/IAmA/comments/4j15bs/were_the_intel...](https://www.reddit.com/r/IAmA/comments/4j15bs/were_the_intel_team_behind_the_new_skull_canyon/)</comment>


Amazon to Disable S3 Path-Style Access Used to Bypass Censorship - <AUTHOR> https://www.bleepingcomputer.com/news/security/amazon-to-disable-s3-path-style-access-used-to-bypass-censorship/ <comment><AUTHOR> I saw the announcement several days ago, but I never realized the censorship angle. I wonder if AWS will reconsider. I also wonder if AWS knows exactly what they're doing here and are playing along with certain countries.</comment>


How to become better at software estimations - <AUTHOR> https://medium.com/code-runners-blog/how-to-become-better-at-software-estimations-part-1-b50ef0619884 <comment><USER2> My rule of thumb for the last 25 years has been: Double how long you think it will take you to do your bit, then go to the next set of units. e.g. 5 minutes becomes 10 hours 1 day becomes 2 weeks 2 weeks becomes 4 months When you write code it's easy to forget the testing, documentation, and process and people overheads of getting your code out of your head and into production.

</comment><comment><USER3> Kirk: "Do you always multiply your repair estimates by a factor of four?" Scotty: "Yes Sir, how else can I keep my reputation as a miracle worker?!"

</comment><comment><USER4> For estimating something (doesn't matter if it's software or what) this is a useful process:

Has something similar been done before?

How long did the previous examples take?

Why do you think this time will be different?

The last question is not to catch you out. Maybe typical splash pages take people a few days but you're really fast at design, or they needed more polish. If I take a week normally to write a blog post and know that this one is longer than usual, maybe I need to add some time. Perhaps you're adding some copy but this time it doesn't need to go through legal. Whatever the difference is, try and start with previous known data and then adjust from there.

You shouldn't predict it'll only take you a day to get this blog post out if it takes you a week every time and you've got to prepare for a talk at the same time.

More detail and an example from Kahneman:

[http://www.mckinsey.com/business-functions/strategy-and- corp...](http://www.mckinsey.com/business-functions/strategy-and-corporate- finance/our-insights/daniel-kahneman-beware-the-inside-view)

<comment><USER5> I find estimates really hard.

For example I'm building mobile apps and often the time frame depends highly on the people involved.

Often the problem isn't the implementation, but everything around it.

Getting the right stakeholders, not everyone who things they have something to say need to be heard.

Getting the right requirements.

Getting the info architecture right.

Getting the design right.

All this can take months.

Then there are things, that sound similar but are completely different.

Getting 30 screens done sounds like a repetition of 30 times, but some of them are simply messages or splash screens and some have crazy interactions with SVG, or API integrations or whatnot.

The last 2 apps I built were completly different.

One was a video/audio streaming app, with some micro blogging service attached.

One had a PDF editor and encrypted data storage.

</comment></comment><comment><USER6> I was always way under with my estimates. One day I was talking to some senior dev at another company and he said that he got better by multiplying his estimates by 3.

So I gave that a go, I'd do my estimates in one column then multiply them by 3 in the next column. At first I thought that those x3 estimates were way too high but 90% of the time they were about right, maybe a little over but it's usually better to be over than under.

After a while I just started landing on those x3 estimates without it being an extra step, I've been not bad on the estimation side of things since doing that little trick.

<comment><USER7> 3 is rather arbitrary, we use Pi as the coefficient instead.

<comment><USER8> Now, this is science!

</comment></comment></comment><comment><USER9> This article may help:

Why Asking Developers for Time Estimates in Software Projects Is a Terrible Idea and How to Bypass It With Scrum: [http://www.romenrg.com/blog/2015/09/28/why-asking- developers...](http://www.romenrg.com/blog/2015/09/28/why-asking-developers- for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass- it-with-scrum/)

</comment><comment><USER10> As a medium level developer (5 years of professional experience), estimations are always the bane of me. No matter how detailed I get, they're always off by enough to concern me.

<comment><USER11> _No matter how detailed I get_

That might be the problem.

A common scenario I've been through more than once is someone asks me for an estimate for some project idea they have. I ponder it for 30-60 seconds and say 6-8 month. They reply can you break that down. So I start breaking it down and breaking it down and then add up all the little pieces and end up at only 3-4 month. Project manager writes down 3-4 months and tell us to get to work. 6-8 month later we deliver and get yelled at for being late.

<comment><USER10> That's really good feedback, thanks. Next time around, I'll try to just leg it broadly and see what happens.

</comment></comment></comment><comment><USER12> Little thin on content or message...

</comment><comment><USER13> Got hung up on the first sentence. I'm on the egg comes first side and I believe evolution proves this point.

Not a chicken -> egg -> not a chicken -> egg -> chicken!

<comment><USER14> Evolution doesn't really deal with where a species splits in two. If anything, species don't exist. Its an abstract grouping of different entities that tend to be able to reproduce together. It only works thanks to in-between links often dying out. If you took a chimp and a human, and made a chain of every ancestor all the way back until you reached a common ancestor, you wouldn't be able to mark when one species becomes another.

We have a few such cases without needing to use time travel. We often refer to them as ring species, but a single ring species would become multiple species if you had one or two areas of the ring wiped out (based on if it is really an unbroken ring or an arc). That the death of one group of animals turns two other groups of animals from being one species into two shows the underlying problem with our classification system.

<comment><USER13> Thanks for your reply, glad to be educated in my limited biology knowledge :D. I think I understand your point. Evolution doesn't classify, we do. But doesn't this validate my point? Isn't the chicken vs egg question the same kind of problem made up by man like what we describe as different species? Apart from specialists there is no need for the majority of the population to classify the extinct variations of a ring species. So I assumed classification occurs vertical up to the common ancestor rather than horizontal by dying out variations of a ring species.

My original statement was simplified, maybe "evolution in conjunction with how mankind classifies species" would be more in line with the point I was making. My reasoning behind this is the following: As far as I know, the most accurate way of comparing species is by comparing genetic structure. And the point at which these genetic changes typically happen (maybe there are exceptions) is at reproduction (that's the evolution aspect of my point). This would also be the "earliest" point we could spot a difference.

</comment></comment></comment><comment><USER15> When my estimates becomes correct, it means, I have a clear view of all the difficulties. Probably, the job becomes repetitive and I should try to find another one.

<comment><USER16> Hear hear... Sometimes I find myself avoiding to complete my pet projects just because I don't want to risk being bored.

</comment></comment><comment><AUTHOR> If you enjoyed the article, you can check out Part 2 on Medium - [https://medium.com/code-runners-blog/how-to-become-better- at...](https://medium.com/code-runners-blog/how-to-become-better-at-software- estimations-part-2-fb286a9d496a)

</comment><comment><USER17> As always, Martin Fowler has something to add on the topic: [https://martinfowler.com//bliki/PurposeOfEstimation.html](https://martinfowler.com//bliki/PurposeOfEstimation.html)

<comment><USER18> Thanks BerislavLopac! Key takeaway from Fowler:

> "Estimation is neither good or bad. If you can work effectively without > estimation, then go ahead and do without it. If you think you need some > estimates, then make sure you understand their role in decision making. If > they are going to affect significant decisions then go ahead and make the > best estimates you can. Above all be wary of anyone who tells you they are > always needed, or never needed. Any arguments about use of estimation always > defer to the agile principle that you should decide what are the right > techniques for your particular context."

</comment></comment><comment><USER19> The best book I have read on software estimation is: [http://www.stevemcconnell.com/est.htm](http://www.stevemcconnell.com/est.htm)

My best short advice would be: always try to make an as detailed as possible list of tasks and estimate them independently - this way it is harder to forget about some details and when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other.

<comment><USER11> _when you estimate the tasks independently you sometimes over-estimate sometimes under-estimate and the errors compensate each other._

Not in my experience. Under-estimate errors are basically always much smaller than over-estimate errors. Unknown factors that can dramatically speed up a projects are much fewer than unknown factors that can dramatically slow down a project.

I mean if nothing else a 4 week task can, at best, be delivered 4 weeks early, but there is no upper limit to how late it can be.

<comment><USER20> This. It strikes me as odd these days when managers and engineers assume symmetrical distribution of time required to complete tasks. This is not only relevant in software development: in my experience, the larger the organisation or set of people/departments involved in any kind of work, the heavier the time distribution is on the "late" side.

<comment><USER21> That was one of the things that burned us once we finally got our task estimates accurate. Most tasks would be finished in about the time estimated, but one would be off by a factor of ten and blow the iteration.

We discovered that for estimates to be accurate overall, most tasks need to be finished early. It's counterintuitive, but it's directly the result of that asymmetric distribution.

</comment></comment></comment></comment><comment><USER22> As a software developer, why would I _want_ to get better at software estimation? At best, it means that I can give a rough comparison of the engineering effort required for different projects, which means that I get projects with a positive ROI (which still takes office politics to translate into actual career success, but it's still helpful). At worst, it yields power and control over my work life for no good benefit.

I'd get good at estimating in a hurry if you flipped the locus of control. Make management generate importance points, give me freedom to choose projects given importance points, and make importance points per engineer-week a Key Performance Indicator.

</comment><comment><USER23> I find it much easier to estimate the time it will take if I take myself out of the picture. When estimating, I always try to think "how much time would it take for my colleagues to plan, execute, test, etc... something"? It is almost impossible to judge your own speed, but with experience you learn how to estimate speed of others quite accurately.

Of course, I also let product managers know that any change _will_ affect the deadline, and almost never in a good way. I do this every time they have another "really simple idea".

</comment><comment> UK-AL This is standard advice for estimates. Yet most estimates are still wrong.

<comment><USER24> Well, they would be, being estimates. If they were right they'd be facts. The problem with estimation is that people view estimates as fact, when (according to Steve McConnell) all estimates should come with a variance of + or - 4.

I like to present my estimates using the cone of uncertainty, which demonstrates their fallibility well.

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

</comment></comment><comment><USER25> The only helpful advice I ever got was to always multiply by π.

<comment><USER26> Yes the pi method was a favourite at my workplace.

<comment><USER27> Also multiplying by π makes it sound like there's a nice pseudoscientific reason why estimates should be off by that specific factor. You don't get that sciencey feeling if you multiply by 3.

(See also: using Fibonacci numbers for story points.)

</comment></comment></comment><comment><USER28> Here at Big Co. we are very Agile. We always write up everything vaguely ahead of time and require estimates from developers which of course become hard deadlines. We are so Agile we always allow product people to request arbitrary major changes which are also estimated, but independently since clearly no changes affect any other, and they can all be done in parallel so the original deadline does not need to be changed. You see, the estimates are the key to successful projects. When the estimates turn out to be wrong we blame the programmers. It's a good system.

</comment><comment> UK-AL The fact that fudging it by 3, is now so popular, just indicates we can't really do estimates very well.

<comment><USER20> Or perhaps it's simply an empirical measure of the typical ratio of known to unknown in software engineering: 1:2. It can be used as a heuristic to accommodate for the fact that we have biases and can't predict everything, but the industry as a whole has found a way around that.

</comment></comment><comment><USER29> Starting point: Often, it's politics, not science or engineering [1]. Approach accordingly.

\----

1) At least, once it comes to providing estimates outside of the assignment/team/project and its own internal thinking.

</comment><comment><AUTHOR> I'm glad to see so many people are interested in the topic and cared enough to comment. I'll be posting Part 2 in the upcoming days.

</comment><comment><USER30> _" Software estimation is a chicken and egg problem. So I will try to solve it from first principles: how long did it take for dinosaurs to evolve into chickens?"_

</comment><comment><USER31> Take your best estimation. Increase the unit by 1 and double the quantity.

Eg. 2 minutes becomes 4 hours. 10 days becomes 20 weeks. 6 months becomes 12 years.

</comment><comment><USER32> Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.</comment>


Ask HN: Is Neuromorphic Computing Promising? - <AUTHOR> I just read  https://arxiv.org/abs/1705.06963. Specifically, the use of organic materials to build robust, low power networks that get past the von Neumann bottleneck and allow us to incorporate new levels of sensing into our environment and lives seems extraordinary. TPUs and chips are obviously interesting for orgs like google, but what about synthetic clusters of neurons integrated into our environment? How significant could that be?<p>Also, what startups are working on this actively? <comment><USER2> koniku.com

<comment><USER2> more fleshed-out response:

Yes. Concepts are useless until proven otherwise, but if we want to summarize a whole field of thought and derivative applications, and if we take a reasonable heuristic that a thing can be promising if it shows potential upside without guarantee of success, I would definitively say yes.

For me the phrase is so cool but it lacks sufficient rigor. What's it really mean to take concepts from the brain and apply them, starting with where do you draw the boundary line around member approaches? Neuroscience and computing can inclusively have a lot of overlap: is any logic 'brain-like'? Do we need to seperate brain and mind and 'intelligent' behavior? Your question also begs for a metric of what would be promising. Let's try economically feasible as a filter. There are clear potential benefits to the tech but it's complex and expensive and mostly early r&d, so you see government initiatives, academic projects, niche startups, and FAANG (IBM, Intel). The article citations for this pretty wide field are thorough but here's some personal highlights:

Koniku, biological neural computation start up | koniku.com

blue brain supercomputer sim project | [https://www.epfl.ch/research/domains/bluebrain/blue- brain/ab...](https://www.epfl.ch/research/domains/bluebrain/blue-brain/about/)

Vicarious neuro-centric robotics startup | [https://www.vicarious.com/research/](https://www.vicarious.com/research/)

Neuropace anti-epileptic tx device | neuropace.com

Spiking net sim frameworks abound while overshadowed by contemporary ML platforms, I'll feature nengo | nengo.ai but there's also brian, neuron, nest, spike… Nengo is primarily maintained by academic startup ABR | appliedbrainresearch.com/about-us/

Strategic endeavors like Allen Institutes for AI and Brain, Janelia Farms neuroscience research campus, things like Brain Initiative in US and Human Brain Project in Europe, DARPA's continued interest, plus a number of dedicated world research institutions and departments generate exponential contributions to the state of the art throughout the abstraction stack. This top down money/effort is part of the fermentation tank for future breakthroughs, a parallel to pharmaceutical drug discovery.

Two projects I find interesting if perhaps a lot to live up to Numenta | Numenta.com OpenCog | [https://wiki.opencog.org/w/The_Open_Cognition_Project](https://wiki.opencog.org/w/The_Open_Cognition_Project)

At the top levels deepmind would define itself as a neuromorphic computing company; youtube interviews with demis hassabis support this. TPU imo is on the spectrum of a neuromorphic computing device. Elon Musk decided he needed to start a neuromorphic interface company, founded an (originally) non profit existential insurance think tank, and aspects of control dynamics and perception for spacex rockets and tesla autonomous cars all arguably fit into the concept of neuromorphic computing.

How far down the rabbit hole do we want to go? Do we need to see direct and immediate impact of r&d or can we value basic research for secondary effects? What's the goal and value prop of any particular research and what side effects might it have? It's conceivable this tech leads to such horrors and wonders as diverse as perfect digital shadows of our consciousness, which we use as back ups or slaves. It could be integral to autonomous killing robots. It could birth the first synthetic consciousness. It could cure your daughter's disability, or your dementia. It could grow you a chicken breast without the attached chicken. It might give rise to something as menial as an ad algorithm that's 5% better or profound as collective consciousness or the end of humanity. At this level of abstraction, tech is a double edged sword that is morally always about how you use it.

Again, promises from people and tech are both often broken, and there's good reasons to be dismissive or pessimistic. I think there's significant chance competing technologies win out for a lot of envisioned use cases. Momentum is behind our massive legacy development ecosystem for information processing, and maybe linear algebra brute force function approximators will prove ever sufficient and cost effective. Commercialization is a high bar. Perhaps the implications and risk is 'too great', and we decide to morally shun this path. Some systems or understandings of cognition could prove indecipherable and yet necessary. Instability renders the organizational complexity and resource investment required outside the scope of human ability.

Inevitably, time will weed out fledgling neuromorphic developments into whatever real-world penetration and impact they achieve, over whatever rate of adoption. Seems unlikely that nothing at all will ever come of any of it.

I need to wrap this comment but there's so many potential applications from immediate domain things like prosthetics and medical devices, bci's up to power efficient and scaling substrate for AGI or 100x improvement in robotics that it's hard for me to not get excited about how promising this discipline is, it's practically a holy grail of disruption. To me many macro trends like Moore's Law, AI renaissance, robotics, Theoretical + Computational + * Neuroscience, better and more medical measuring modalities and data, escalating capability and economic incentive for automation, incentive for medical knowledge and advances, the feedback loop of neuroscience developments advancing computing advancing neuroscience ...plus others… weigh in its favor. Personally this lends a lot credence to a (long term) bullish view for progress. Worth noting, time studying this topic has felt oddly - meditative? Or maybe cosmic is apt. There's an inherent aspect of self discovery in building off of and deepening understanding of the brain mechanistically, both individually as a human research who contains/is a brain and collectively as a planet of them.

To OP, if you expand on what you mean by synthetic, environmentally embedded neuron clusters I'd be happy to associate and speculate with you.</comment></comment>


NEW INFOGRAPHIC: The Anatomy Of A Great Sales Prospecting Email - <AUTHOR> http://www.tropical.io/blog/anatomy-great-prospecting-email-infographic?v=3

<comment><USER2> This is the ?v=3 submission, previously:

[https://news.ycombinator.com/item?id=8000981](https://news.ycombinator.com/item?id=8000981) (?v=2) : 1 point by jbrisebois 1 day ago, 0 comments

[https://news.ycombinator.com/item?id=7999406](https://news.ycombinator.com/item?id=7999406) (?v=1) : 1 point by jbrisebois 1 day ago, 0 comments

[https://news.ycombinator.com/item?id=7998851](https://news.ycombinator.com/item?id=7998851) : 1 point by jbrisebois 1 day ago, 0 comments</comment>


Elon Musk: I will "eat my hat" if a competitor's rocket flies before 2023 - <AUTHOR> https://arstechnica.com/science/2018/02/elon-musk-i-will-eat-my-hat-if-a-competitors-rocket-flies-before-2023 <comment><USER2> I fear it will take longer than anticipated and may not end up being a full sized hat that he eats.</comment>


Paragon submits 27k-line NTFS driver to Linux kernel - <AUTHOR> https://www.theregister.com/2020/08/18/paragon_tries_to_contribute_ntfs/ <comment><USER2> I understand that reviewing 27k LoC is daunting and probably not very fun.

But unlike most patches that draw a similar response it's not a narrowly useful patch that mostly serves the submitter. Proper NTFS support benefits a large proportion of Linux users (the jab from the article that there are more advanced file systems out there seems out of place; there are no signs that windows is about to switch its default FS to something else).

Additionally this code has been used in production for years now (e.g. my 2015 router runs the closed source version of this driver in order to support NTFS formatted external drives) so most likely a lot of quality issues have already been found and addressed.

So I feel it's a bit unreasonable to respond with so much negativity to this contribution.

<comment><USER3> It's also no big deal from either side. Paragon sent in the patch and it's appreciated. There's a few problems to get this in. Reviewers noted the issues and what would need to be done to get this through. The process to get this in is happening.

Split your diff! and Fix your makefile! have to be one of the most benign and common pieces of diff feedback i've seen. I feel that you could make a media story about any submission to the Linux kernel based on there being comments in the review process.

<comment><USER2> Admittedly I didn't actually read the mailing list discussion. It's entirely possible that The Register made up a big drama where there was none.

<comment><USER4> Not sure if this counts as drama per Linux kernel mailing list standards: [https://lore.kernel.org/linux- fsdevel/2911ac5cd20b46e397be50...](https://lore.kernel.org/linux- fsdevel/2911ac5cd20b46e397be506268718d74@paragon- software.com/t/#m34fc84d93a7009caf533ff400f7c763da4cab366)

> So how exactly do you expect someone to review this monstrosity ?

<comment><USER5> It's a legitimate concern - I would not assume malice. How exactly would someone review a 25k loc .patch file?

<comment><USER6> It would be tough, no doubt.

But it's not like splitting the feature into 100 patches of 250 lines each would make it any quicker to review. Or merging code that was known not to work, as it was only a fraction of what was needed for the functionality.

<comment><USER7> > But it's not like splitting the feature into 100 patches of 250 lines each > would make it any quicker to review. Or merging code that was known not to > work, as it was only a fraction of what was needed for the functionality.

That would _also_ be rejected, because the kernel maintainers aren't idiots and their standards aren't the stupid arbitrary rules you construe them to be. They generally want big changes to be broken up into logical, sensible chunks that each leave the tree in a usable state, so that git-bisect still works.

<comment><USER8> How do people merge big new filesystems in practice though? Especially one with years of pre-existing out-of-tree development?

I guess one could start by merging a skeleton of the filesystem which supports mount/unmount but then returns an IO error on every operation? And then a patch to add directory traversal (you can view the files but not their contents), and then a patch to add file reading, and then a patch to add file writing, and then a patch to add mkdir/rmdir, and then a patch to add rename/delete of regular files.

Breaking down an existing filesystem into a sequence of patches like that, no doubt it is doable, but it is going to be a lot of work.

<comment><USER7> My guess is that given the history of this filesystem implementation, most of the review effort will be focused on the interface between this FS and the rest of the kernel. It's typical for all the changes touching communal files or introducing generic helper functions or data structures to be broken out into separate commits. If any of those helpers are a reinvention of stuff that's already in the kernel, there will need to be a justification for why NTFS needs its own special versions. It's _not_ typical for a large patch series adding genuinely new stuff to be broken up into absurdly tiny commits. For the stuff that's truly _internal_ to the filesystem implementation, it looks like one patch per file will be an acceptable granularity.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> It's strange to me that there's no file system with basic features like journaling and support for files larger than a couple of GB, that is supported across all major desktop OSes (MacOS, Windows, Linux, and FreeBSD). All platforms support the same i/o standards like USB or DisplayPort, why did filesystems never make the cut to become a cross-system standard?

Imagine if you could have a backup drive (with reasonable modern data protections) that you could just plug into different systems and save all your files to. Isn't it odd that such a simple thing isn't possible? I guess network attached storage has gotten pretty accessible at this point so there's no need for it?

<comment><USER10> There's a ZFS driver for Linux, macOS, and Windows.

<comment><USER11> ZFS development moves so fast that it is common for my (FreeBSD-based) FreeNAS box to warn me when I upgrade my OS that certain actions will make it incompatible with the prior version of FreeNAS.

That is fine and appropriate for a drive that will be connected to the system for the foreseeable future.

That kind of compatibility concern makes me squeamish about using ZFS for a drive that I want to share between different systems. If it's easy to make it incompatible between two releases for the same system, that smells like a waiting nightmare trying to keep it compatible between Linux, FreeBSD and Windows.

<comment><USER12> Yeah it should stabilize in the next couple of months with the release of OpenZFS 2.0 as that release is supposed to signify the unification of ZFS on Linux and FreeBSD. ZFS on FreeBSD is being rebased onto ZFS on Linux. Theres also been some talk on adding MacOS zfs support OpenZFS but thats still up in the air.

<comment><USER13> This is great news

<comment><USER14> Agreed! I've been running FreeBSD on various computers for very close to a decade now, and still run it on my mail server, but one problem that I faced a couple of years ago when I sold my old laptop, which I was running FreeBSD on, was that my other computer at home at the time was running Linux but I had an external HDD that I'd been using with the laptop and which I was using GELI encryption on.

Since I didn't have money for any more hard drives at the time, I couldn't transfer the data to anything else. So then when I wanted to access that data I'd do so via a FreeBSD VM running in VirtualBox. The performance was... not great.

I took the data that I needed the most, and for the rest of the data I let it sit at rest.

This week I wanted to use the drive again, and in the end because I was doing general cleanup, I decided to install FreeBSD on my desktop temporarily.

I actually love FreeBSD but the reason that I prefer to have my desktop running Linux is in big part because I want software on the computer to be able to take advantage of CUDA with the GTX 1060 6GB graphics card that I have in it, and unfortunately only the Linux driver by Nvidia has CUDA, the FreeBSD driver by Nvidia does not.

I was actually looking at installing VMWare vSphere on the computer instead, so that I could easily jump between running Linux and running FreeBSD with what I understand will probably be good performance compared to VirtualBox at least. But the NIC in my machine is not supported and vSphere would not install. I found some old drivers, messed around with VMWare tooling which required PowerShell, and which turned out not to work with the open source version of PowerShell on any other operating system than Windows. So then I downloaded a VM image of Win 10 from Microsoft [0], and used that to try and make a vSphere installer with drivers for my NIC. No luck at first attempt unfortunately. A decade ago I probably would have kept trying to make that work, but at this point in my life I said ok fine fuck it. I ordered an Intel I350 NIC online second-hand for about $40 shipping included, and the guy I bought it from sent it the next day. It is expected to arrive tomorrow. Meanwhile, I installed FreeBSD on the desktop. When the NIC arrives I will do some benchmarking of vSphere to decide whether to use vSphere on the desktop or to stick to either FreeBSD for a while on that machine or to put it back to just Linux again.

Anyways, that's a whole lot more about my life and the stuff that I spend my spare time on than anyone would probably care to know :p but the point that I was getting to is that, with OpenZFS 2.0 I will be able to use ZFS native encryption instead of GELI and I will be able to read and write to said HDD from both FreeBSD and Linux.

I still need to scrape together money for another drive first before I can switch from GELI + ZFS to ZFS with native encryption though XD

Oh, and one more thing, with the external drive I was having a lot of instability with the USB 3.0 connection on FreeBSD, leading to a bit of pain with transferring data because the drive would disconnect now and then and I'd have to start over. But yesterday I decided to shuck the drive – that is, to remove the enclosure and to connect the drive with SATA like you would any other regular internal drive. It worked out excellently, the WD Essentials enclosure was easier to pry open than I had feared, and a video on YouTube showed me how to do it [1]. As prying tools I used a couple of plastic rulers. As a bonus, it also looks like I/O performance is better with the direct SATA connection than what I was getting with the USB 3.0 connection.

Speaking of that, some people have reported finding that the drives in their WD Essentials external drives were WD Red HDDs. I didn't have the same luck with mine; mine was WD Blue. But idk if WD Red is even common with the capacity that mine has anyways. Mine is "only" 5TB and I think the people that have been talking about finding WD Red drives in theirs has bought 8TB models often. Idk. The main thing for me anyways is just to have my data and someplace to store it ^^

[0]: [https://developer.microsoft.com/en-us/microsoft- edge/tools/v...](https://developer.microsoft.com/en-us/microsoft- edge/tools/vms/)

[1]: [https://youtu.be/QApvLyorr3g](https://youtu.be/QApvLyorr3g)

</comment></comment></comment></comment></comment></comment><comment><USER15> In the meantime v2 of the patch has already been submitted, addressing some of the points mentioned in the article: [https://lore.kernel.org/linux- fsdevel/904d985365a34f0787a451...](https://lore.kernel.org/linux- firstname.lastname@example.com/)

</comment><comment><USER16> This is such an odd article. Perhaps Paragon isn't being entirely altruistic with this move but TR are being quite scathing of someone's work submitting a kernel driver with no direct financial reward - and no real praise for, hopefully, fixing one of the biggest out-of-the-box gripes that Windows / Linux desktop dual-boot environments have. It's no small wonder people often complain about the hardships of writing and maintaining open-source software!

<comment><USER17> I don't get where TheRegister is getting the drama. The thread doesn't seem that scathing to me. [0]

It doesn't build, but the person who pointed it out also supplied a diff to make it happen.

It also fails a few tests, but Paragon are more than happy to see if they can make it a bit more compliant.

UBSan finds a few potential bugs, but again, Paragon are more than happy to fix the problems.

There's some style guide suggestions, which Paragon seem to immediately take on board:

> The patch will be splitted in v2 file-wise. Wasn't clear initially which way > will be more convenient to review.

[0] [https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d7...](https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d74@paragon- software.com/)

<comment><USER18> Yeah, The Register can often be witty and irreverent, and I wouldn't complain about that, but that kind of wit only works if there's an actual point behind it. Jumping on the apparently popular bandwagon of squeezing out "drama" from the Linux kernel mailing list isn't adding anything of value.

It also seems a bit ignorant to call the submission "half-baked" just because it needed to be worked on and because someone pointed that out (also) in a slightly irreverent way.

All of those points you bring up about the feedback they got seem like just business as usual for a larger merge of code to a carefully developed FOSS project.

</comment></comment></comment><comment><USER19> LKML post: [https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d7...](https://lore.kernel.org/lkml/2911ac5cd20b46e397be506268718d74@paragon- software.com/)

Earlier discussion: [https://news.ycombinator.com/item?id=24170001](https://news.ycombinator.com/item?id=24170001)

<comment><USER20> Thanks, maybe it was the expectations set by the tone of The Register article, but the mailing list discussion seemed mostly very reasonable...

</comment></comment><comment><USER21> Possibly a dumb question, but what are the plusses/minuses of something like this as compared to NTFS-3G?

[https://en.wikipedia.org/wiki/NTFS-3G](https://en.wikipedia.org/wiki/NTFS-3G)

<comment><USER22> You'll be able to install Linux on NTFS root now!

<comment><USER4> I wish Linux on NTFS could share metadata with WSL1. That way you could boot it off the same WSL1 files you could access in Windows.

</comment></comment></comment><comment><USER23> I don't think it's completely fair.

Don't look a gift horse in the mouth, especially when you need one.

<comment><USER24> This is like giving someone a litter of puppies as a gift and then walking away.

Hooray, free puppies. Now you just have to care for them for the next 10 years.

<comment><USER25> Paragon stated their intent to maintain and support the code in their initial email, and added themselves to the maintainer files.

There's no drama happening here. Paragon guys are trying to give it "properly", and linux guys want it "properly", and the only thing happening is defining "proper" in this context

<comment><USER26> Intent, promises and reality aren't always aligned. Especially when given a slap dash of tens of thousands of lines of code that didn't meet kernel contribution guidelines.

<comment><USER25> Thats true... but nothing has happened yet. No one has yet failed to hold up their end. All parties seem to want this to work -- it certainly isn't a dead drop.

</comment></comment></comment></comment></comment><comment><USER27> I wonder if the reason for the huge line count is overly verbose code, or if it's just the inherent complexity of NTFS. For contrast, I wrote a FAT32 filesystem driver (read/write) for an embedded system a long time ago, and it was less than 1K lines --- of Asm.

<comment><USER28> NTFS is way more complicated (and feature rich) filesystem than (rather barebones) FAT32.

</comment></comment><comment><USER29> It's just a single data point, but I tried Paragon's ext4 driver (the paid version) for Mac many years ago. It seemed to work, but when the drive was connected back to Linux, there were all kinds of fsck errors. Immediately deleted it.

<comment><USER30> This has also been my exact experience. I used Paragon's NTFS driver (paid) for Mac for my external SSD. After using, when plugging into Windows it would always find "errors" and recommend to Scan and Fix them.

<comment><USER31> Fwiw, I had the same problem with Paragon but have had a lot more success with Tuxera's driver, if you're still looking for a solution.

</comment></comment></comment><comment><USER32> 27k lines isn't _that_ crazy. I've merged larger patches, it just takes a while. This is a very negative view of an open source contribution.

<comment><USER7> > I've merged larger patches,

In what kind of context? The Linux kernel?

Filesystem code is pretty tricky to begin with, and prone to very subtle bugs with very not-subtle consequences. And this isn't greenfield development of a new filesystem, but an implementation that needs to remain highly compatible with Microsoft's version. This FS driver has to be maintained to track changes to _two_ operating systems. So _this_ 27kloc can reasonably be expected to encompass a lot more complexity than your average 27kloc, and it requires a lot more review effort than something like 27kloc of GPU driver register definitions.

<comment><USER32> > In what kind of context? The Linux kernel?

Not the Linux kernel, but a large embedded system.

> Filesystem code is pretty tricky to begin with, and prone

> to very subtle bugs with very not-subtle consequences.

This code has been running in the wild for quite a while now, it has had a trial by fire. And there's no way around testing, subtle ext4 bugs still crop up despite the maturity of the filesystem.

> And this isn't greenfield development of a new filesystem,

> but an implementation that needs to remain highly

> compatible with Microsoft's version.

No amount of code review will stop Microsoft from adapting their version. Also, I doubt Microsoft themselves will change too much about the filesystem given the compatibility they themselves have to maintain with cold storage NTFS drives.

> This FS driver has to be maintained to track changes to

> two operating systems.

You make it sound as if Microsoft have a hand in any of this. Also, have you seen the state of the current NTFS driver? It's a bit flakey (no disrespect to the maintainers).

<comment><USER7> > No amount of code review will stop Microsoft from adapting their version.

Way to miss the point. Code review for the kernel isn't just about verifying that the code currently works. It's also about making sure the code is _maintainable_. Microsoft is relevant here because their actions will increase the maintenance burden of any Linux NTFS driver. Kernel developers rightly need to be concerned about how difficult it will be to extend the NTFS driver to handle new NTFS features that Microsoft introduces.

<comment><USER32> > Way to miss the point.

The point wasn't so clear, but I see what you're saying now. Maintainability is normal code review though.

> It's also about making sure the code is maintainable. [..]

> Kernel developers rightly need to be concerned about how

> difficult it will be to extend the NTFS driver to handle new

> NTFS features that Microsoft introduces.

Maintainability is one thing, extensibility is another. Preparing your code to implement some changes completely outside of your control seems like a waste of time and something that might bite you later on.

</comment></comment></comment></comment></comment><comment><USER33> 27k is 27 kB.

This is 27 kLOC.

</comment><comment><USER34> I solemnly swear never to complain again about the size of PRs given to me for review.

It's going to take months to throughly assess the quality of this.

</comment><comment><USER35> Ouch. That looks really useful, but at the same time possibly their first kernel submission perhaps?

Hope I'm wrong but I think they'll be fighting initial bad impression for a while despite good intention

</comment><comment><USER36> I hope the it's better than their ext2 drivers for macOS. I have had nothing but problems and data loss and their support is the worst.

<comment><USER37> Same on Windows regarding data loss. Terrible and I'll never use their ext2 drivers again.

</comment></comment><comment><USER38> > "It looks as though that with NTFS being surpassed by other more advanced > file-systems,

Is this remotly true?

Will my grandmother not be using NTFS in 10 years?

<comment><USER7> Microsoft has been trying to come up with a replacement for NTFS for a _very_ long time. They've had mixed success with trying to extend NTFS with more advanced features like the now-deprecated TxF. There's little doubt that even its creators see NTFS as something of a dead-end. Whether your grandmother is still using it in 10 years depends primarily on whether Microsoft can get its act together to pick and ship a replacement.

<comment><USER38> > Whether your grandmother is still using it in 10 years depends primarily on > whether Microsoft can get its act together to pick and ship a replacement.

So yes she will I guess.

Then it's vital Linux gets NTFS working well.

My partner is not going to use Linux things if every time they try and transfer the 8k 3D holographic photos of our CRISPR'ed dog learning to spell to my grandmother it doesn't work on her Holovision.

True story, last month I just lost about 1 in 10 of my media files on my Linux Share to NTFS issues. So now I run the box on Windows.

<comment><USER7> > True story, last month I just lost about 1 in 10 of my media files on my > Linux Share to NTFS issues. So now I run the box on Windows.

Were you seriously running a Linux-based NAS with NTFS as the underlying filesystem, or did you mean something very different? I can't imagine why anyone would ever think their choice of disk filesystem on a server—hiding behind a network filesystem—should be influenced by what disk filesystems are supported by client devices.

<comment><USER38> Given my original question about my grandmother has been downvoted it says it all about the judginess of Linux users ;)

My setup was -

Windows and Ubuntu dual boot gaming PC with a NTFS 4G external hard disk, Windows network share. Default boot was to Ubuntu.

Torrents running off wireless laptop to the network share.

Amazon Fire stick with Kodi wireless running to network share.

</comment></comment></comment></comment></comment><comment><USER39> 200loc/h, it's 4-5 weeks of work for a single person

</comment><comment><USER40> Does it need to be included in the Linux Kernel? I understand that NTFS is 27 years old and mostly to support Microsoft file systems. Can't the driver be an external download?

<comment><USER41> In-tree drivers are the standard for Linux kernel modules.

</comment></comment><comment><USER42> As long as it builds as a module, uses only the standard filesystem apis and doesn't have code changes outside that, code review is far less important IMO...

<comment><USER43> I wish you weren't getting downvoted, but what you said is absolutely correct. If it's a module and separate from core, who cares. If it's modifying core kernel or mixed up with kernel space code, then nope.

<comment><USER7> Linux isn't a microkernel; a filesystem accepted into the kernel source tree will run as kernel space code whether or not it's compiled as a loadable module. So all 27k lines need to be audited for security purposes and to ensure they're interfacing with the rest of the kernel only in the approved ways, because there aren't a lot of technological barriers to the filesystem misbehaving.

But more important than that is the maintenance burden. NTFS will be around for a long time, but it's also a moving target because Microsoft hasn't replaced it yet. Kernel developers have to keep in mind how this code will look in a few decades, after all the original developers are retired. If it's written in a very different style from other Linux filesystems, will there be anyone left who both knows enough about the workings of the Linux IO stack 20 years hence, and understands Paragon's code conventions?</comment></comment></comment>


Where can I find projects that are similar to real life programming jobs? - <AUTHOR> Hi HN.
I am teaching myself programming and CS concepts.
Where can I find some projects that are similar to those made in real world programming jobs, such that I can make myself hirable?
I am mostly interested in python at this point. <comment><USER2> Try looking at what people are asking for on freelancing sites. Also look at curricula from coding bootcamps, if available; they tend to be more industry- focused rather than theory-focused.

Finally, look for open source software in the industry that interests you, and read its code (some will be good, some will be bad).

<comment><AUTHOR> Thanks there @nitrogen. I'm taking a look a what kind of jobs people are posting at upwork so I can find projects to study.

</comment></comment><comment><USER3> Pick a stack, then choose an open source project in that stack to contribute to. You can start by contributing docs and tutorials, then try to understand the code base and fix small bugs. Work your way up to bugs and features with the most votes. That guarantees people are using your work, which managers appreciate. It also establishes authority in that software, which can lead to jobs if it's popular enough.

</comment><comment><USER4> i've heard good things about [http://www.freecodecamp.com/](http://www.freecodecamp.com/) \- you learn to program while building things for nonprofits. mostly javascript- rather than python-focused, but worth a look.

</comment><comment><USER5> Big, estabilished open source projects? Real life programming jobs are usually about working on large and old code bases (these kinds of jobs are also the least desirable, so they could be a good entry point for someone looking to get into the industry).</comment>


Cambridge University refuses to censor student's thesis - <AUTHOR> http://www.boingboing.net/2010/12/25/cambridge-university-1.html <comment><USER2> First, he thrusts the knife in, then violently twists it -- "Accordingly I have authorised the thesis to be issued as a Computer Laboratory Technical Report. This will make it easier for people to find and to cite, and will ensure that its presence on our web site is permanent....". Classic.

<comment><USER3> The Brits often have _such_ a way with words. Bless them.

<comment><USER4> The English have a way with ... English!

Fancy that.

</comment></comment></comment><comment><USER5> >Cambridge is the University of Erasmus, of Newton, and of Darwin.

This is a very elegant way of giving them the finger.

<comment><USER6> It's also a surprising _appeal to authority_ logical fallacy. Those people don't work there anymore.

(not that I disagree with them that they shouldn't censor the findings)

<comment><USER7> I don't see the reason for downvoting parent. Full quote is "Cambridge is the University of Erasmus, of Newton, and of Darwin; censoring writings that offend the powerful is offensive to our deepest values", and first part struck me as completely irrelevant to the second part, somewhat unworthy of this otherwise well-convened letter.

In addition to that I don't see it as an "elegant way of giving finger", how mentioning of historic figures conveys the "finger message"?

<comment><USER8> Erasmus, Newton and Darwin all published writings which offended the powerful. Cambridge didn't censor that, and they seem to see that as a winning strategy.

</comment></comment></comment></comment><comment><USER9> Previous post/discussion: <http://news.ycombinator.com/item?id=2039117>

</comment><comment><USER10> Prof. Anderson shows good character.

Let's talk about the other side. Businesses have always acted this way when it comes to computer security (for at least the last 15 years, feel free to cite earlier examples). By now they probably understand that what they're doing is wrong, from a security perspective. They may even understand that issuing takedowns increases publicity. Still, business are sociopathic, they don't care about the legitimacy of their actions. They have a staff of lawyers they're already paying for, and a responsibility to defend trade secrets and protect their product base. So they marshal their lawyers, essentially for free, and maybe they get something out of the effort as a result. If they don't, nothing much was lost, and they generally don't care about their perception in the security community. Same old story. This incident is less about someone standing up to a bully and more about someone weathering another wave coming out of the ocean.

<comment><USER11> I think I see what you are saying, but I don't agree with the contrast you mention in your last sentence.

Consider: being sociopathic, not caring about the legitimacy of their actions, harassing someone when the risk to them is small -- how does this differ from being a bully?

<comment><USER12> Eventually a bully may learn. A true sociopath will continue no matter how many times punished.

<comment><USER11> Interesting point.

But if that's true, then businesses almost never act in a manner we would call sociopathic. And my earlier comment (suitably modified) still stands.

<comment><USER10> Hi ggchapell,

We agree on your point. The company is being a bully. My issue is with the reception of the story. The larger picture is that frivolous takedown notices are issued all the time, and will continue to be issued willfully by companies until there is disincentive to do so.

Prof. Anderson's actions are commendable. I do not wish to detract from them. However, with the candor I hope a security researcher would appreciate, I point out that both parties probably expected this exchange would take place, and both parties understand Prof. Anderson's response is ineffective. (The Internet, however, may not.)

Prof. Anderson has successfully stood up to this organization, but he has only maintained parity. This kind of incident will repeat as long as companies believe they can get something out of it. Someone else will cave or will plain not know any better. The companies' goal is, basically, harassment, and they will continue to do it regardless of anything that's happened so far. So I guess my point is that I would rather see people discussing how to remedy this old situation than remarking on the letter, which while entertaining and well- written, is actually the signifier of a losing battle.

(unfortunately this is the last I can comment on this topic)

</comment></comment></comment></comment></comment><comment><USER13> Brilliant. If only more institutions had a spine like the one displayed here.

<comment><USER14> They're legally required to: <http://news.ycombinator.com/item?id=2039235>

<comment><USER15> They're not legally required to be so badass about it.

</comment></comment></comment><comment><USER8> Link to original letter - oh boy this is a good read: <http://www.cl.cam.ac.uk/~rja14/Papers/ukca.pdf>

<comment><USER16> Nice last paragraph:

Nonetheless, I am delighted to note your firm statement that the attack will no longer work and pleased that the industry has been finally been able to deal with this security issue, albeit some considerable time after the original disclosure back in 2009.

</comment></comment><comment><USER17> To be fair I didn't read this the first time it was on HN - I'm inclined to think that the title of the post is more descriptive than the original, and its deserving front page material, even if it is a duplicate.

<comment><USER9> Agreed, but it is useful/insightful to have the comments/discussion on hand.

</comment></comment><comment><USER18> BBC video on chip & pin findings: <http://www.youtube.com/watch?v=_yyfcHSXZLc>

</comment><comment><USER19> Dupe: <http://news.ycombinator.com/item?id=2039117>

</comment><comment><USER20> He's a good lecturer too. Funny how being a good lecturer and being a badass correlate.

<comment><USER21> "Security! Security! Security!"

Although there were some fantastic lecturers at Cambridge who were somehow very terrible at getting the material across, but whose content/personalities were so enjoyable it was worth turning up anyway. I dare say it's the same everywhere.

</comment></comment><comment><USER22> The thesis - <http://www.cl.cam.ac.uk/~osc22/docs/mphil_acs_osc22.pdf>

</comment><comment><USER23> Intentionally or unintentionally, this has got to be one of the best pieces of marketing for research inclined students and faculty that they could have ever produced.

So much so, that the skeptic in me thinks this was intentionally leaked.

I had always considered possibly applying to the University of Cambridge, and I know they are Ivy League...but this letter, firmly solidifies them as a contender for any higher education I might pursue.

</comment><comment><USER24> > _You complain that ... and indeed to censor it._

The penultimate para in the original letter, wow! A befitting answer to a bully, and how! :)

</comment><comment><USER25> I wonder when Cambridge starts to be blocked by the banks then ... :)

</comment><comment><USER26> I tend to disagree with the banks' assessment that it will undermine public confidence. The research gives the public one more piece of information to judge the risks for placing their money in a financial institution.

The banking sector as participants in a free market who frequently advocate for opening of more sectors of the economy to the free market (and rightly so) should be encouraging such research. The research gives consumers of banking services more accurate information to consider when deciding how accessible their money should be. Additional information allows consumers to make more informed choices regarding the trade offs between security and convenience. Banks could offer insurance to their customers to protect them against the risks while still keeping the benefits of increased convenience.

It's an opportunity for the banks to differentiate their services and cater to the needs of their customers. Yes, not having a PIN is less secure, but it's also more convenient, with proper positioning of their products banks should be able to offer tailored solutions that better address the needs of their customers.

</comment><comment><USER27> For the third time, we get it.

</comment><comment><USER28> Am proud of being in the University of Cambridge.....we don't produce apps.

</comment><comment><USER29> "we have no choice but to back him. That would hold even if we did not agree with the material!"

Reminds me of a Frankin quote: "Sir, I disagree with you, but I will fight to the death for your right to say it."

<comment><USER13> Surely you mean Voltaire?

"I disapprove of what you say, but I will defend to the death your right to say it"

</comment></comment><comment><USER30> Wouldn't it have been far nobler to approach the banks affected by the exploit with these findings rather than publishing schematics for the exploit into the public domain?

<comment><USER31> I believe the article states they notified the banks before publishing the original work.

<comment><USER30> No it doesn't? I'm not taking the side of the banks here, just trying to understand why the author took the approach he did. It's a shame that at times the HN community is one of single-mindedness where opposite views are met with immediate down-votes.

<comment><USER32> > ... because it documented a well-known flaw in the chip-and-PIN system...

The author of the article at least believes that it is a well-known flaw so responsible disclosure isn't really applicable.

<comment><USER30> Well I think you hit the nail on the head, that the disclosure isn't responsible. I'm all for bringing the flaws in chip-and-pin to the public attention, however I find it distasteful that a leading university publishing the schematics of a device that can be used to commit fraud, receives so much applause for this community.

I get the impression that this has captured the public mood of "sticking it to the bankers", when really Cambridge have gone about this one the wrong way.

<comment><USER33> My reading of the whole incident is that the exploit was disclosed (responsibly) to the banks 1 year ago and the banks have done nothing to fix the problem. Since then the professor (along with others) published a paper detailing the exploit. Finally the MPhil student cited the previously published paper in his thesis (it would be a crappy thesis to not reference current similar work)

At no point do I get the indication that the MPhil student was acting in a way that was 'irresponsible' - I don't know how you have come to that conclusion.</comment></comment></comment></comment></comment></comment>