amaks

What personal devices, smartphones?

Interesting how much outcry this RMS's page causes. It's his personal opinion, you're free to disagree with him but advocating to take down this link is anti-constitutional.

Please read http://hackingdistributed.com/2016/06/17/thoughts-on-the-dao....

Solidity language makes very hard to write safe code:

Is Ethereum/Solidity Suitable for Secure Smart Contracts? It's clear that writing a robust, secure smart contract requires extreme amounts of diligence. It's more similar to writing code for a nuclear power reactor, than to writing loose web code.

Yet the current Solidity language and underlying EVM seems designed more for the latter. Some misfeatures are:

A good language for writing state machines would ensure that there are no states from which it is impossible to recover. A good language for writing state machines would make it painfully clear when state transitions can and cannot happen. A good language for maintaining state machines would provide features for upgrading the security of a live contract. A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read. The current language does not fulfill any of these commandments, and in fact, the last one, involving implicit recursive calls, is what did The Dao in.

The SlockIt team even had the designer and implementor of Solidity perform a review of their code. If he cannot get something like The DAO to be secure, no one can.

Sorry, but this is bullshit. You sound like Ethereum or SlockIt employee. No one in their sane mind would trust their money a company which can't guarantee security of your funds, let alone good coding practice (the DAO code is shit, sorry -- there are no tests, no comments, no spec, no clear upgrade story etc.). Good attempt, and I can feel for Ethereum folks, but something this important should be rock solid, not "experiment" when you're fucking with people's money. This is not a hacker's playground.

Well perhaps but I read this article (http://vessenes.com/deconstructing-thedao-attack-a-brief-cod...) and it says:

"OK, here we go. _recipient.call.value()() is called without a gas amount. That is easily attackable with an attacking wallet."

> All computations on Ethereum have to be funded with "gas" (transaction fees)

But that's what was wrong with the exploited DAO code - it didn't use gas. The point of the article is that it's very hard or impossible to verify the correctness of the smart contracts.

Here is the analysis:

http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...

The primary criteria where a system language should be judged is the control over the underlying machine code execution. With GC languages you don't have any - the GC will kick in unpredictably. It may not be an issue for UI (although everyone hates when UI stumbles), but for system code like OS, DBMS, etc. it's simply not acceptable. Languages like C and Rust offer this level of control - you simply know exactly what your code is doing at any given time. With JVM, .NET, Go - you don't.

What happened to Scala? Wasn't that the #1 language for JVM?

Any language can compile to the low level C dialect.

Yes, and I never said that Go is a systems language. I said Go has found a niche of networking services. This doesn't make it a systems language.

It's frustrating to see that people advocate to use programming languages in the areas where they don't belong just because those languages are convenient, have nice syntax, popular, etc. Go for example started that way but ultimately went to the niche of writing networking services where it shines. It's weird that languages with unpredictable runtime characteristics such as Java and C# are being advertised as systems programming languages.

The biggest problem I see with the code at https://github.com/slockit/DAO/ is absense of the unit tests. The code looks complex, how the hell can you make sure that it's right?

The Solidity wiki doesn't have a single entry on testing either:

https://github.com/ethereum/wiki/wiki/The-Solidity-Programmi...

Exactly. DAO should have tested the shit out of their "contracts" before starting accepting people's money. Now DAO and Ethereum as result won't have any trust.

I'm curious when their engine will be good enough to start playing against leading human Go players?

Also, Microsoft has been developing ReFS as a replacement for NTFS.

Was it just me, or ability to interact and access personal data on the lock screen on a locked phone seems little insecure?

Digital currency is a cult.

No, they do have sophisticated user mode library but use only public kernel APIs. That user model library also helped them relatively painlessly migrate SQL Server to Linux.

That's exactly right, it looks like Go has found a niche of the network servers. Here is good overview by Andrei Alexandrescu: https://www.quora.com/Which-language-has-the-brightest-futur...

(http://www.escapistmagazine.com/news/view/100652-Facebook-CE...)

Zuckerberg: They "trust me" Zuckerberg: Dumb f*cks.

"Google Circles, a way of organizing social contacts, shamelessly copied from Facebook’s long-ignored Lists feature."

I thought it was the other way around - circles were based on a research by a guy from Google, who left later for Facebook and they built similar feature.

I agree, it looks like the demise of Google+ is direct effect of mismanagement by Vic and integrating everything (YouTube, Gmail etc.), not any kind of Zuck's "genius".

STL is not inherently slow per se, some data structures are just not fast on modern CPUs, so they have to be chosen wisely. Here is good talk: https://www.youtube.com/watch?v=fHNmRkzxHWs.

I wouldn't call Steve Kovach as credible journalist in tech. His articles in businessinsider just prove the point.

It's also very beneficial to the code health as it allows to make global refactoring, e.g. adopting new language features, improving shared libraries, etc.

Now it's employees' fault. It's nice to be able to blame grass roots, not the processes.

Bad article. There is technological constraint that leads to inability to use end-to-end encryption when using bots (note that they are not only Google's but also 3rt party's). Same is true for other messaging platforms that use bots including Facebook Messenger. Individual messages are encrypted inflight. If you need end-to-end encryption then use incognito mode. IMO this looks like a perfect balance of privacy and functionality.

The most disturbing to me is not even favoritism and sexism conditions at work (which is ironic given Sheryl Sandberg's book and official line), but the fact that Facebook: 1. uses humans to pick the trending topics, which are inherently biased in one way or another; 2. the trending sources are very limited and curated (e.g. no Twitter), which is clearly anti-competitive practices.

Vulkan in Android N is huge