marco_salvatori

I cant speak for any of the people on that list either. But if they are committed to the core values of free software and empowerment for all, then its plausible to me that, rather than words in a joint statement, they should fork the FSF. That is the course of action on which the FSF was founded and would be proof positive of their commitment to the core values they profess. They can then proceed to build a better project, with stronger core values, including universal empowerment. There is no one that has to be judged; there are no joint statements that need to be written. That is the wonderful thing about freedom. One can build, perhaps has the obligation to build, the better world that should exist.

Additionally, but on a slightly different note, I can think of two other common situations where these equivalence validation techniques are useful.

When refactoring or doing performance work, its very helpful to create two variant implementations, for instance the simple, obviously correct version and the new, optimized version. One can then send the output from a property based tester or a fuzzer into both implementations and test: assert forall x . referenceVersion(x) == optimizedVersion(x). A good property based tester or fuzzer will give one high confidence that behavior has been both understood and reproduced. Since changes to legacy code and bug fixes are among the primary causes of defect introduction, these testing techniques usually quickly bring to ones attention how fallible one is.

For non code artifacts like configurations and build systems where output is assembled or generated. The Unix diff utility can be useful. One assembles or generates the artifacts in two directories. One directory is representative of the project before the change and the second directory after the change. Anything that shows up in the directory diff should correspond to exactly to what one expected to see as a change. Since the full actions of package assembly and generation are often opaque, this technique provides assurance in parts of the system development process where there are often few other safety nets.

People who are unfamiliar with WeChat Pay in China, are underestimating the potential for the FB cryptocurrency. The integration of social media and payments by WeChat strongly facilitated consumer adoption of their payment service. Everyone already had phones, everyone had WeChat installed on their phones. When payment services later became available through WeChat, there was a minuscule barrier for customer adoption. As people started using WeChat Pay they quickly found it more convenient for physical and online payments, money transfer between friends, and financial management. Next services like taxi hailing + payment became integrated into the WeChat app, increasing the convenience. The combination of convenience, preinstallation in the dominant social application, and low barrier to entry was a killer combination. In my estimation it turned out to be a stronger combination than Alipay, which started out as a payment service integrated with TaoBao (comparable to the Ebay / Paypal).

Since Facebook has a dominant social app and messaging app position worldwide, their payments service will have worldwide penetration from day one. Since Facebook can do software, the service interface will be more convenient and user friendly that existing services in the first world, and infinitely more so elsewhere. Money can be made here and evidence suggests people want to adopt when there is a no effort road to adoption. There are vested interests to deal with and satisfy on the road to market penetration, existing market players and governments, but American entrepreneurs like Gates and Jobs were able to overcome vested interests in their time and I suspect Mark is equally resourceful when he wants to be.

Traveling extensively the past year I have noticed the following which are probably all coming into our lives soon. (a) In many countries border entry is accompanied by a fingerprint scan which will be either a left and right index finger scan or a scan of the whole left hand. The scans are done at inbound border crossings in conjunction with the passport check. (b) In many countries both border exit and entry are paired with the taking of a photograph. In some places it appears the exit photograph is validated automatically by software. (c) In some cities, the subways have security checks at entry and in those places photographs are taken, non obviously, by the security equipment. I am not sure how effective these systems are at tracking. I guessing ideally governments would like to pair these photos with a passive probe of something carried on the body like a phone or official id, something that could link the photo to an already verified identity. (d) On country entry, purchases like SIM cards for local telephone service or public transportation pass cards can only be acquired if one presents an official id. Manual computer entry usually links the card to the presented id.

And here is a prediction, getting a record of faces and fingerprints, and tracking movement is on the agenda right now. In the future there will be a equally focused agenda to acquire records of peoples DNA. In countries where there is nationalized health service, it will eventually be required. Aquisition will begin when the cost of storing, acquiring, and searching that DNA information becomes cheap enough.

Little in this article meshes with my experience living in large Chinese cities: Beijing, Shanghai, Guangzhou, and Shenzhen. Specifically, I have not observed the social problems mentioned "crime, ... social segregation, and destroyed community and neighborhood life". I believe a good description of the average large, Chinese city experience is: lots of cars and people but mixed development with plenty of shops, schools, markets, eating locations, parks, and public transport in easy walking distance. To me, the article comes across as an opinion piece - it was all bigger than the author would have preferred.

Since a full version Mathematica is available on the Raspberry Pi, anyone who is interested has a very inexpensive route to getting a free copy. Mathematica is very functional on the Raspberry Pi and, I think, making the software available as such is very generous of Wolfram. Also for those who cant afford a Raspberry Pi, excellent mathematical functionality is available via the Wolfram Alpha website for free.

Throughout my career, I have never met anyone who used MS tools that did not find them excellent and productivity enhancing. In fact I could probably add to MS any of the language vendors from years ago. I remember using Borlands terminal based C++ environment back in the early 90's. That's about 30 years ago and that environment is better than what I use programming on Linux today.

I have often thought that programmers posture over their tool independence to signal their excellence. Before the current generation of programmers, many programmers would proclaim how they didn't need to use higher level languages to assist them in programming because assembly language was sufficient given their reasoning powers. Today programmers proclaim they don't need types to insure data invariants as their reasoning powers are sufficient. They proclaim they don't get any value from unit testing because they can maintain correctness across all development phases using their reasoning powers alone. They proclaim they don't need automatic garbage collection because they can insure correct memory usage using their reasoning powers. They have no use for IDEs, debuggers, or profilers because they believe none of these tools could augment their reasoning powers.

Excellent programmers can indeed compensate for poor tooling through their reasoning powers alone. But if history is a guide, people who don't use the best tools, practices and technologies to produce the best work, at some point, wont produce the best work.

Yes. When a client hires a developer, he cares that he receives a proper delivery and he cares that all of the decisions related to that delivery were made in his best interests. Technology choices are an important part of building a technical vision for a company and planning for software maintenance. People may not seem to care much, but that's only because they are trusting the people they hire to care and to know better than they do. When there are any questions on technology, clients appreciate and value unbiased discussion on those choices, in the context of their business. An important part of having clients, perhaps the most important, is establishing trust and one does that with success, but also a record of transparent, appropriate project decisions.

Just building on the who and why idea ... as a technical manager an important aspect of your job is use your technical aptitude to help your non technical peers clarify business ideas related to, possibly, technical problems. Once problems are clarified, it should be clear whether they are technical or not. At that point you then need to advise at the proper level of abstraction on cost, timelines, possible solution benefits and shortcomings.

Lets think about clarifying business ideas. Non technical people are familiar with issues in their business areas, but they may not be able to clearly describe the issue or identify root causes. Your job as a managerial level engineer may be to interpret a vague understanding that something is not as they want, into statement that can be evaluated as a engineering problem. You may in that interpretation process find that the problem at hand is not a technical problem or that there may be effective non technical means to solve it. Remember that people you are dealing with have developed very different skills to address issues in their businesses areas, and engineering style problem definition is likely not one of those skills. For example, a typical sales manager might deal with sales issues by getting a lot of people in a room, generating visibility, enthusiasm and consensus. He may see that as the way to solve engineering issues as well. Just as you may not have developed the skills to generate institutional momentum and enthusiasm, others may not have the developed the skills to approach problems with engineering perspective. Your value comes from doing that transformation for them and then communicating it to them in terms of their skill set.

Take an example, suppose a peer tells you that it is a problem that you do not "talk like a leader". What does he mean by a leader? I have heard hundreds of definitions of what a leader should be over the years. He is trying to express a mismatch between your managerial execution and his ideal, but I'm not sure if leader is the exact word he wants to express that mismatch. Which of my hundreds of "leader" definitions would most closely match his primary complaint about your execution style? Lets go a step backwards to "dont talk like an engineer". I suspect this statement is getting to the source of his primary complaint so lets investigate this statement.

I mentioned above that you need to advise at the proper level of abstraction and in terms of other peoples skill sets. If you are in a managerial meeting about a new product X and you start talking about Ruby on Rails vs Django or using C++ vs Rust, then you are talking at the wrong level of abstraction. The business does not care if X is Ruby on Rails or Django. They care about whether its a good technical idea. Should they put resources into X? How much will X cost? How long will X take to create? And most importantly how well X might or might not solve the well defined problem you clearly communicate? If you have ever talked technical details in a meeting, then you are talking like an engineer, and your talk is irrelevant to their concerns. Conversely, if you are ever in a meeting, and a peer manager suggests they really need a Y implemented to solve their problem Z, then your job is not to give them cost and timeline information on Y. Your job is to understand that your peer manager might, himself, be operating at the wrong level of abstraction. Y might the the solution to his problem, but maybe he would be better off with a different technical solution. Or maybe he needs to see the problem in a slightly different light.

I cant be sure, but I suspect that you dont have to change perspective and become a leader. Your perspective probably has a great deal of value to your company but you are just not presenting that perspective in a way your peers find maximally useful.

My take away was that researchers produced evidence that the shape of bird eggs is optimized, around physical characteristics of the parent. I am open to the idea and sceptical. In the context of humans it would be like saying the shape of children is optimized around the physical characteristics of a womans body, as opposed the the supposition that a womans body is optimized around the physical characteristics of children it will have to give birth to.

At the risk of being too opinionated, PlusCal is a needless and unproductive diversion. The TLA language and source file structure is mostly standard mathematical notation, using ascii characters. Most people will be familiar already with that mathematical notation before any exposure to TLA. And I wouldn't be able to recommend that people learn just another novel representation for something already known. Learning PlusCal to reason about logical propositions strikes me as comparable to learning an XML notation for manipulating formulas in differential calculus. Yes, we are developers; yes, we are used to XML and, still, ... I don't see how it improves upon writing math.

Mathematical notation is a concise, time tested language for enhancing thought. People should use that to their advantage. As an added advantage, unlike PlusCal, facility in the language of propositional logic generalizes widely to other tools used in formal methods, as well as other technical fields.

Doing the comparison TLA vs Rust as programming languages is a misunderstanding. It's exactly equivalent to the misunderstanding in a comparison like "what's the advantage of SQL over Rust, that as far as I know is designed specifically for this kind of problems". Now, one could believe, perhaps, that Rust is "designed specifically" for the implementation of database "kind of problems". But the conclusion that there is therefore no "overwhelming advantage" to databases would not follow from that belief.

TLA and the TLA tools form a model checker. The TLA language is not used to do computations,but, rather, is used to describe properties and behavior of complex systems. The TLA tools then machine validate the descriptions to assure that the evolution of a system with the given behaviors will satisfy expected correctness properties. A TLA specification tells you that if your system is implemented (in a computer language, like say Rust) according to the description then the systems operation will satisfy the validated correctness properties.

TLA is about answering the question "Do I properly understand my problem and will my solution logic satisfy problem needs?". Rust doesn't help answer that question.

You might create a TLA model during the initial specification process to assist you in thinking through your problem. You would then update the model going forward as your understanding of the domain improved and as system requirements changed. However, you could write a specification for an existing system as well. Any processing where the complexity seems greater than ones reasoning ability or that needs assurance guarantees, could signal the need for a high level description to guide engineering efforts.

An initial model might take 4 hours to put in place. The time would be spent thinking through how best to abstract the modeled process and its logical properties, slowly building up a more and more complete set of events, and checking the model by running it as one goes. With an initial model, additional hours would probably be spent here and there adding enhancements and finding ways to do things better, just like one would do with regular code. The model would effectively exist over the lifetime of a corresponding code artifact and guide work on the artifact.

For a standard web application that mostly does reads and writes to a database, there usually wouldn't be any need for a tool like TLA to help you reason. A general use case for TLA is describing systems where there are multiple processes or threads coordinating on some sort of shared state.There would be indeterminacy in the order in which events happen. There could be the possibility of failure and the need to handle it gracefully.

Yes, strict separation will probably be the norm where there are sovereignty issues. And it will be enforced both ways. So for example,I will make the claim that if Alipay expanded into the US it would own the entire payments market in one year. Alipay is just that much better than anything else available in the US. Plausible or not, Alipay will never operate successfully in the US because the US will not cede sovereignty over part of its financial infrastructure to China.

I can not say if that is smart or not. That question is outside of my technical sphere of competence. But I believe it's an accurate evaluation of how states will operate, as soon as these systems start being used to project power.

My suspicion is that its very unlikely that Google and FB are going to be able to establish the government relationships that would allow them to operate successfully in China.Google collects massive amounts of citizen data and it has close relations with the US military / security institutions. The combination means Google will never be a trusted operator in China. Facebook is in a worse position. In addition to being a data collection platform with US government connections, it is a communications platform not under the direct control of China, located in the US.And these US communications platforms have a history now of being associated with movements of anti-government dissent around the world.

More generally, I dont see how US tech companies are going to be able to have it both ways -- be both willing partners in US government policy and also non threatening to Chinese sovereignty.

On a more general note, where ones work violates ones values either because one feels ones work can enable unwarrented agression, transgressions against human liberties, or violaations of human rights. The most influential thing one can do is walk away. A core set of experineced, capable engineers is required for the success of many projects beyond standard levels of complexity. Engineers now, but more in the future, will influence aysmetrically the type of systems that get built, just by refusing to work on projects that can server intrests that they are at odds with.

As a second point, engineers somewhere, perhaps readers of hackernews, have built systems that enabled illegality and overreach -- and they maintain them. I understand that people want to provide for their families and futures, but at some level introspection, unfortuntely, seems to have fallen short. Taking the idea a step further, what expections should we have of our peers?

People really can help create the future through what they choose to work on.

The employee reaction is natural. They feel their privacy has been violated

> if the NSA is going to spy on us, wouldn't you like that to be as secure as possible?

If I was an American, I would deny the premis. If the NSA is going to spy on you, wouldnt you like your fellow country men to refuse to work for them.

One can also download the TLA+ book and the TLA+ hyperbook from Leslie Lamport' TLA home page

https://lamport.azurewebsites.net/tla/tla.html

Both are very useful resources and for those interested in learning I would recommend going through both together letting the book fill in the detail where the hyperbook leaves you wanting more information. The hyperbook concetrates on PlusCal, which is a higher level interface to the TLA language, while the TLA book is all in the TLA language itself. I find,in practice,that the TLA language is what I am more comfortable writing specifications in. I find it clearer and as essentially standard mathematical notation its one less thing to learn. I believe Leslie encourages engineers to use PlusCal as being more user friendly.

Once one has worked though the specification course in the hyperbook, one should be able to apply TLA to real problems in any event driven system. (Sequential problems can also be modeled though). The primary hurdle in getting to applications will probably be coming to the understanding that modeling work happens at a much higher level of abstraction than programming, and that ones insticts as programmers, to get into detail, are not correct.

The benefits are two fold. Modeling a system before it's built forces one to abstract, clarify and simplify ones approach. The second benefit is that the model checker will find all the corner cases and complexity that one missed in the design. If one does a good translation from the model to code from there, then to a first approximation the code is bug free. As a bonus, later, when one goes back to code that has a spec, the spec is a nice summary of what has been coded (becase you forgot) and one can modify, and verify the spec before one updates the code.

Though this work may seem exciting, there is an existing, respected body of work available on how to mathematically structure a search over a large parameter space and how to mathematically interpret experimental responses. That body of work is a subset of applied statistics called design of experiments. It helps scientists avoid the common failures that result from doing exactly what was done here, random space exploration and non rigourous evaluation of results.

For this to be exciting I would expect some indication as to how this method extends and enhances the existing science of experimental methods and the trade offs involved with using their method. I dont see that.

The police state that is China doesnt care about summit attendees, it cares about social harmony. Summit attendees should have a passport and a visa if needed. Otherwise they should act in a harmonius manner. If they can do that, then they will be disappointed to find out that the officials simply dont care about them. No one is going to ask friendly, personal questions in customs; no one is going to ask for an inventory of what is being carried in; no one is going to ask how much money you have with you; no one is interested in seeing and opening your electonics; no one is going to pay the least attention to your baggage. Relax, have a good time, and prep a vpn if you are set on working. Then, on the way back, contrast the experience to the police state that you are from.

For testing comparison testing should probably be the preferred means of testing (solves the oracle problem). A combinatoric tester of the quickcheck variety can be invaluable here,and can be used from the unit test level all the way to external service level tests. Copy the preferably small sections of code that are the fix or functionality target, compare the old and copied paths with the combinatoric tester, modify the copied path, understand any differences, remove the old code path (keep the combinatoric test asserting any invariant or properties).

Some other important points:

- Inst. and Logging: And also add an assert() function that throws or terminates in development and testing, but logs in production. Sprinkle it around when your working on the code base. If the assert asserts assumptions were wrong and now you know a bit more about what the code does. Also the asserts are your documentation and nothing says correct documentation like a silent assert

Fix bugs - Yes, and fix bugs causing errors first. Make it a priority every morning to review the logs, and fix the cause of error messages until the application runs quiet. Once its established that the app does not generate errors unless something is wrong, it will be very obvious when code starts being edited and mistakes start being made.

One thing at a time - And minimal fixes only. Before staring a fix ask what is the minimal change that will accomplish the objective. Once in midst of a code tragedy many other things will call out to be fixed. Ignore the other things. Accomplish the minimal goal. Minimal changes are easy to validate for correctness. Rabbit holes run deep and deepness is hard to validate.

Release - Also almost the first thing to do on a poorly done project is validate build and release scripts (if they exist). Validate generated build artifacts against a copy of the build artifact on the production machine. Use the Unix diff utility to match for files and content or you will miss something small but important. For deployment, make sure you have a rollback scheme in place or % staged rollout scheme because, at some point, mistakes will be made. Release often because the smaller the deploy the less change and the less that can go wrong.

Last time I played a bit with Signal, about a year ago, the app was a bit fussy but functioned without extra measures. And I believe it was the sign up procedure that was a bit fussy. Regarless, though, Chinese communications controls are constantly improving, and what works one day will not necessarily work the next.

The are 1 billion people in China who have easy access to Android phones which do not have Google Play Services installed and provide no access the Play store. There are potentially more than 10 people out of those 1 billion that could have a use for Signal.

I generally advise nice, ethical people who want to benefit society to avoid working for morally ambiguous organizations, as it can have a degradating effect on their character. Still, some people find their principles in unexpected places. And for someone who is an expert on fighting abuse, there is an rare opportunity for outstanding service to their country and the principles that made it great by applying such skills to the situation at Guantanamo.

For those interested in security engineering in the financial industry a good reading source is the banking section of: http://www.cl.cam.ac.uk/~rja14/book.html One interesting and relevant take away (of many) -- The greatest fraud threat to a financial firm are insiders. About 1% of staff across the industry is fired every year due to fraud. Within the fraud incidents, the most damaging fraud is perpetrated by senior and trusted individuals.

I didn't feel this article was clearly thought out. If just manufacturing things, whatever things are, were important then possibly replacing (magically) the industrial sectors in the US with those from China would be a good thing. If that came about then of course the US would be much poorer, possibly as poor as China. Its also not sufficient to say manufacturing is a source of good paying jobs. Highly skilled manufacturing sectors provides good wages and benefits (say, semiconductor manufacturing), piece work in say the garment industry provides sub subsistence level wages. A better title would be - "it matters what an advanced economy produces". I used to work in manufacturing (all over the world) and here a few impressions based on my experience. In the factories, today, where people in advanced economies would want their children to work, there are more robots than people. The ratio of automation will increase over the next 10 years as the machines become smarter. In advanced countries it is more and more common for manufacturing facilities to require the skills of people with PhD's, Masters degrees and highly trained vocational workers to function. There are going to be very few jobs in 10 years for people who can just contribute muscle power. Even in the far east, manufacturing is going to be a sector of falling employment (like agriculture in the past) and at the same time of rising output (like agriculture). And lastly, here is a thought, based on my experience running a business. There is lots of competition out there in the world. One cant make a good living producing any "Thing". One has to find a product that is differentiated, valuable to others, and not easily reproduced by thousands of other businesses all over the world. And then one has to sell it. That's turns out to be a difficult job -- much more complicated than a slogan like "manufacturing".

  "Prof. Mazières’s research indicated some risk that consensus could fail, though we were nor certain if the required circumstances for such a failure were realistic."

I'm surprised to see the above statement in a press release; maybe it was not worded quite right. At the scale of 100s of thousands, or a millions of transactions a day, "some risk" will manifest itself on operation timescales itself. So when one is "not certain" it's always best to assume that problems will show up and it will take less time than expected.

  "We are still investigating the triggers for this consensus failure, but believe it is caused by the innate weaknesses of the Ripple/Stellar consensus system outlined above compounded by the number of accounts in the network."

Also not great wording. Saying the system had "innate weaknesses" and we "believe" kind of implies engineers are still guessing on the trigger. Your building a financial corporation and if you lose you loose everything

Any experienced engineer who tackles even a moderately complex coding problem and decides beforehand to think through that problem with a machine checked specification (say with Lamports TLA) will very likely discover that

1. His first 4, 5 attempts at the specification are not even close to being correct and his human mind was ill equipped to spot obvious problems without help.

2. The process of thinking through a such a spec focuses the mind precisely on what problem has to be solved and how to most economically address that problem -- neither of which he got right at the start.

3. The confidence in the implementation that follows the specification is far higher than the confidence he achieves through other typical methods (unit, human testing)

Thinking with a tool to help out may not be appropriate for every coding problem, but it does bring one to a very clear realization of how incredibly fallible one is in the face of complexity and the importance of thinking. And will cure you of statements like "having to think before you code isn't Agile" forever.

Has anyone out there used LightTable on production project. What are your impressions of its usability? How has it affected you productivity? How does well does it integrate with other tools for your platform? Other...?