Cactus for Mac - <AUTHOR> http://cactusformac.com/

<comment><USER2> Really excited about this app. As someone who enjoys casually developing personal sites — I know my way around HTML/CSS but not enough to deploy something like this on my own — I think this looks to be a perfect way to ease into some slightly more advance site building, perhaps a happy medium between the lack of efficiency that comes with rolling a site totally from scratch, and the unnecessary bloat of doing a full Wordpress install to get a simple blog up and running.

Nice, simple documentation that explains the features and benefits of the app quite well. But I do agree with some of the comments about the UI. I don't find it entirely intuitive — for example it was initially unclear to me what the editing workflow is supposed to be, since selecting a project and clicking "edit" brings up a menu to select a text editor. I see the intent is to navigate the project structure within a full-featured editor like Sublime Text that allows such functionality, but before seeing that it's hard to tell whether it's possible to navigate the project from within the Cactus app, or whether it's all external and meant to be done in Finder.

Look forward to testing this out though — I have a couple small projects in mind that I think this will be great for. And a great opportunity to jump into learning basics of SASS, Coffeescript, and Django templating without the intimidation/overhead of setting it up myself.

</comment><comment><USER3> The app is based on the open source [https://github.com/koenbok/Cactus](https://github.com/koenbok/Cactus)

<comment><USER4> I came here to ask this exact same thing. Recently used Cactus to develop a pretty big static website. Plugins made it very fun and easy to build more complex cases. Thanks for the great work!

</comment></comment><comment><USER5> Seems a lot like [http://mixture.io/](http://mixture.io/)

</comment><comment><USER6> It looks really good. You did a great job of explaining the directory structure.

</comment><comment><USER7> Who made this and how did they get an endorsement from Werner Vogels?

</comment><comment><USER8> Why does it look like an iOS app

<comment><USER8> \- and the titlebar font is wrong

\- and the titlebar text doesn't fade correctly when in the background

\- and a 100 other inconsistencies with the rest of my OS

please developers stop rolling your own windows for no reason

<comment><USER9> "omg I'm so afraid of change!"

<comment><USER10> Ok, I'll bite.

Rolling your own GUI should be done when the native OS GUI doesn't meet the expectation or needs of your application. A custom GUI may not play nicely with accessibility and may look increasingly alien with OS updates.

I don't see any advantage to using the iOS look, and it only added to my confusion when downloading. I wasn't sure if it was at first looking at the screen shot an app that required an iOS component.

1) No maximize dot, I wasn't sure if the window was resizable until I moved my mouse to the corner

2) No Resize in icon in upper right hand corner

3) Lack of menus (really, ever action must be found in the gui?)

4) clicking off the app window does not "grey" out the title bar letting me know its not the front window.

5) Close/minimize icons do not highlight on click

6) Settings fields cannot be tabbed between

7) Settings cannot use keyboard controls for the cancel / save like OS native dialogs

These are just the errors I noticed while writing this post. The app looks like it could be a nice MAMP alternative.</comment></comment></comment></comment>


Three large internet services share the same SMS short code - <AUTHOR> I just noticed, as I add SMS 2-factor authentication to my contacts.app to keep them tidy, that 2-factor authentication, which I am using for Facebook ( only on the web, I was tired of their 300 pound app ) and Yahoo!, as well as eBay, all use the same SMS short code for 2-factor authenticating me.
Is this safe?  This is a security feature, so I would assume you would not want other companies using your same short code, unless they were partners, or there was some shared authentication service they are using.  Though I don't believe any of the SMS services out there are running low on short codes.
I am not aware of either of these 3 companies being in any form of an alliance.  I have no idea who to contact about this, any suggestions?
If you are curious, the short code is 732-873, you may want to search your logs and see if that number shows up for even more companies that just the three I have located so far.
Thanks. <comment><USER2> Not uncommon at all.

Chances are the short code is the SMS aggregator or 2FA service they're using. Google turfs up some spam complaints for that number, so it's probably their aggregators standard US shared number. Twilio or whoever.

Most aggregators have a selection of short codes, internationally. Same goes for the more popular SMS enabled services - they'll have a short code shared for all their customers. Now in most countries that 2FA text will have a customer chosen text senderID eg "eBay Authorization" by the service, and short codes saved for when the service needs to handle incoming texts. USA and Canada insist on numeric sender ID so using a short code is more common. Outside the US you never get to know it's a shared aggregator or service, and probably can't reply to it.

Shared codes are common, mainly because of the cost and lack of availability. US is, from memory, somewhere around $1k a month for a random number, potentially quite a bit more if it's a 4 digit or word association. USA and Canada stand out as the difficult/expensive ones globally for SMS.</comment>


The problem isn't that life is unfair – it's that you don't know the rules - <AUTHOR> http://www.businessinsider.com/the-problem-isnt-that-life-is-unfair-2015-11 <comment><USER2> Life is unfair and its disingenuous to say it isn't. Yes, life is competitive but not all successful participation is genuine-- winning by any means necessary is incredibly toxic, especially when it involves 'winners' perpetuating bad heuristics to sustain status quo. If Oliver Emberton came from a different socio-economic background, he would be more aware of how much of a myth meritocracy is.

<comment><USER3> "If Oliver Emberton came from a different socio-economic background, he would be more aware of how much of a myth meritocracy is."

Exactly, although we wouldn't be having this discussion because he wouldn't have had the platform to transmit his thoughts on the matter.

<comment><USER4> Except, he doesn't actually say life is fair or a meritocracy. Rather, he claims that you are competing in an unfair and demand driven world.

My own experience is that people who focus on successes and failures in terms of themselves and how they will deal with the environment next time, do well. Those who focus on how the environment limits them, will not do well relative to how others with less advantages will do.

</comment></comment></comment><comment><USER5> Also a meta-rule: People lie. Or often times, they just omit and hope nobody asks. That's how they manage to cover up what the actual rules are.

If you think that life is unfair, it may be more productive to ask yourself "What am I missing here? What have I been told that doesn't square with how I see people act?" and then update your mental model accordingly. Once you build mental models that derive the rules from what people _do_ and not what they _say_ , you'll often find they can take you surprisingly far.

</comment><comment><USER6> > A cancer researcher is rewarded less than a supermodel. Why? Because those > abilities are rarer and affect more people.

Really? World has more - or even proportionally more - cancer researchers, than it has supermodels? Or, putting it another way, the superstar cancer researchers make something comparable to supermodels?

</comment><comment><USER7> If I were to schedule a football game between the New England Patriots and a good local high school team, one could agree to play it by pro, high school, or NCAA rules, and referees could call all penalties scrupulously. It would then follow the rules. Would it be fair?

</comment><comment><USER8> I don't even understand how you could claim "the problem isn't that life is unfair" with a straight face. That is so nuts.</comment>


Elon Musk Says SpaceX's Falcon Heavy Might Fly in September - <AUTHOR> https://www.geek.com/news/elon-musk-says-spacexs-falcon-heavy-might-fly-in-september-1702837/?source <comment><USER2> Can we expect multiple booster landings in this launch?

<comment><USER3> Yes - the plan calls for the two outer boosters to perform a Return To Launch Site landing (landing at LZ-1, formerly LC-13), and the center booster to land on the droneship at sea.</comment></comment>


Amazon's EC2 Service Suffers Outage - <AUTHOR> http://gigaom.com/2009/06/10/amazons-ec2-service-suffers-outage/ <comment><USER2> IMO this is an example of why AWS is so valuable. Not only has Amazon designed their cloud to allow for redundancy (availability zones), but when something does fail they have smart people working on it immediately. Whenever I have doubts about using AWS in a project I always remind myself that the cost of the instance includes much more than the compute, storage, and bandwidth resources. It's all the other stuff as well: smart people watching over my bits, policies & procedures to ensure proper handling of failures, etc.

</comment><comment><USER3> "Today's incident also shows the fragility of the 'cloud' as it can be knocked out a single lightening strike."

How is this different from any other data center? Note too that on EC2, your instances will be spread randomly throughout the facility - you'd actually be better off having this happen on EC2 vs. in a traditional DC. Furthermore, this was a localized incident inside of a single availability zone - the other four (now five, actually) AZs were completely unaffected.

The author clearly does not know what he is talking about.

I'm glad one commenter on the article had the sense to call him out. Too bad he was followed by the usual set of trolls.

<comment><USER4> From what I've heard, this is EC2's only outage in the past year. Amazon's SLA guarantees 99.95% availability for a region (meaning that if you have 2 instances running in different availability zones, Amazon guarantees that at least one of the instances will be up 99.95% of the time). However, with a 3 hour downtime being their only downtime (so far as I'm aware) in the past year, they're hitting 99.95% uptime _within_ an availability zone.

It should be noted that the 365 Main datacenter that hosts (hosted?) Craigslist, Six Apart, Technorati, and a number of high profile web companies had a total failure a while back ([http://radar.oreilly.com/archives/2007/07/365-main- datace.ht...](http://radar.oreilly.com/archives/2007/07/365-main- datace.html)). Similarly, Rackspace (whose business is not having to worry about your servers) had 3 outages in 2 days ([http://gawker.com/tech/followup/rackspace-outage-was- third-i...](http://gawker.com/tech/followup/rackspace-outage-was-third-in-two- days-321909.php)).

So, Amazon's 3 hour outage that affected a minority of their customers doesn't seem that outrageous. You're totally right. The author was probably writing a bit of link-bait to get read. No one reads "Amazon EC2 has minor outage that compares favorably against their competitors and affected a minority of their customers." That's just business-as-usual talk. However, if you question the entire viability of cloud computing because of a 3 hour outage, well, that deserves reading.

</comment></comment><comment><USER5> Lightning storm FTL.

Once power was back, however, so were our instances, which was a pleasant surprise.

</comment><comment><USER6> So, let me make sure I understand... If I had deployed my app on EC2 in two or more availability zones AND had tested it to ensure that it would continue to work if one zone became unavailable, then my users woudn't have noticed, right?

If this is the case, I'd interpret this outage as a testament to how good AWS is!

</comment><comment><USER7> It is nice that they availability zones so you can get around these kinds of problems if you have the money, their outage report confirms the problem was isolated to one zone.

The report also states it was a problem isolated to a group of racks, a failing power distribution unit which I take it was on the "wrong side" of the UPS. A lightning storm affected something on the "inside" of the UPS, but nothing else in the datacenter? I'm curious how that would even happen (and shouldn't a lightning rod be in use?).

Also, it seems like Google's per-motherboard UPS system would have been the setup to have in order to avoid this problem in the first place.

</comment><comment><USER8> If you're building a mission-critical service, always make sure you have servers in multiple availability zones (regardless of whether you use EC2). If you're service is too small to rent multiple servers, consider a shared approach like Azure or GAE.

</comment><comment><USER9> Does anyone know which availability zone was affected?

<comment><USER4> Short answer: no.

Long answer: there's no way to know. The names that Amazon gives a specific location aren't something you can rely on. So, your us-east-1a might be a different availability zone from my us-east-1a. I'm guessing Amazon did this to avoid everyone "going with the default" and launching instances in us- east-1a and having way more instances wanted to be launched there than their other availability zones. But it does mean that there is no way of identifying by name what the availability zone was that went down since the only names we have identify different places depending on our account.</comment></comment>


Saudi Arabia threatens to ditch dollar oil trades to stop 'NOPEC' - <AUTHOR> https://www.reuters.com/article/us-saudi-usa-oil-exclusive/exclusive-saudi-arabia-threatens-to-ditch-dollar-oil-trades-to-stop-nopec-sources-idUSKCN1RH008 <comment><USER3> MBS would find himself on the receiving end of a cruise missile. It's not as if he would be missed by the rest of the al-Saud family he sidelined.

The US also has long-standing contingency plans to support Shia secessionism in the oil-rich Eastern provinces should the al-Saud stop doing as they are told. No invasion needed.

<comment><USER4> Of course that's absolutely what would happen, like Cuba, Iran, Iraq, Syria, Venezuela, Nicaragua, Panama. On reflection regime change hasn't been successful without significant troops on the ground

<comment><USER5> Regime change often isn't necessary for the US to accomplish its goals. In this thread premise, Syria would be regarded as a success, because there's nothing left of the country. They no longer pose a threat to Israel and they're a small fraction of the military power they used to be (a net drag on Russia rather than a benefit). It'll take them decades to rebuild.

The average income in Cuba is $20 per month. Without regime change they were heavily neutralized as an influence in Latin America. Cuba's military could hardly be less of a concern. Once Raul Castro is gone, that's the formal end.

Venezuela is a failed state. The Bolivarian Revolution is over there. There won't be another Chavez any time soon. And if there is, there are no resources to be used to fund such a regime's agenda. The US didn't have to do anything in that case, Venezuela destroyed itself through typical Statist mismanagement. Ironically Chavez will have ended up helping to benefit the US considerably, by destroying what should have been one of the world's largest oil producers. It removed vast potential supply from the global oil market for decades, helping to an extent to make way for the US boom, keeping prices high enough to spur on the Permian shale build-out. If Venezuela were producing like it should be, that'd be ~4m more barrels per day the US producers would have to contend with on the global market, dragging on prices. Instead the US has a solid runway from here to 16m barrels per day of production in the coming decade.

The US is now a big oil competitor with Iran. So keeping them boxed in - <USER2> regime change needed - is a large win economically. The US can pretend it's for all sorts of reasons, while actually serving the purpose of furthering US oil production and exports. The US is 'convincing' South Korea to abandon Iranian oil right now, in favor of US oil. All the US has to do is keep Iran boxed in for two decades until oil demand begins to contract, then it's over (two decades merely being the time from here to 9/11). Iran's theocratic system will collapse in on itself as oil demand fades, they don't have enough of an alternative economy.

<comment><USER6> That's why I'm happy about the US being an oil producer: less arab/persian oil money to sponsor terrorism. Syria is also screwed. Too bad they scewed Gaddafi, a hopeless romantic who wasn't sponsoring terrorism when the US made everybody think he was, but it was in fact Hafez al-Assad who did.

<comment><USER4> No idea where you'd get that from. I am sure when the US and UK are building a coalition to invade and remove Assad a lot of things will turn up, nuclear programs, chemical weapons, training camps, cocaine, ivory trade. Lots and lots of stories will be made up. No need to get the ball rolling

</comment></comment></comment></comment></comment><comment> ainar-g This might be simply Russian state propaganda working, but wouldn't the diversification of the world's currencies be a good thing? Remember how everyone were afraid of the collapse of the US Dollar back in 2008, and then the similar predictions about the Euro? (And we're hearing a lot about the Great Britain's Pound these days.)

<comment><USER7> > wouldn't the diversification of the world's currencies be a good thing?

It is not that simple. If an economy has a surplus, e.g. China, where does that surplus go? This is why we have a default world currency whether that be silver, gold or petro dollars.

When you work through it a bit more the more you realise a basket of currencies won't work, unless every currency is essentially the same. Capital is like water, it flows.

I would like to see discussion on how we can move on from the currencies we have to a measure of energy. Everything can be measured in energy terms, why not cut out the abstractions?

<comment> ainar-g I used to play with an idea of a science fiction novel, where the united Earth's currency is essentially kcal/kJ. The problem is that if you have a flammable and radioactive material, do you count the energy you get from it by burning it, or the energy from throwing it into a nuclear fission reactor, or the energy of throwing it into a black hole in a particular angle[1]?

[1]: [https://www.youtube.com/watch?v=ulCdoCfw- bY](https://www.youtube.com/watch?v=ulCdoCfw-bY)

</comment></comment></comment><comment><USER8> It sounds like this NOPEC thing must look like kind of a nuclear option to Saudi Arabia, otherwise why would they threaten something so drastic?

Given that, is the NOPEC thing serious, and if so, why would people propose it knowing how critical the Saudi relationship is?

<comment><USER9> The US-Saudi relationship is much less critical to the US now than it was 15 years ago.

Since the US shale oil revolution, the US is essentially energy independent.

Basically all that is left is that Iran is more poisonous in US politics than Saudi Arabia for reasons that relate to the Iranian revolution and the - moderately reasonable - fears that Israel has of Iran.

<comment><USER8> According to CNN the US imports 7.9 million barrels a day from Saudi Arabia. According to Wikipedia the US uses 19.8 million barrels per day. That means approximately 40% of the oil comes from Saudi Arabia.

[https://edition.cnn.com/2018/10/15/investing/saudi-arabia- oi...](https://edition.cnn.com/2018/10/15/investing/saudi-arabia-oil-imports- united-states/index.html)

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

<comment><USER10> You are misunderstanding the oil market -- the US is one of the leading exporters of both crude oil and refined oil products. A large percentage of US production and importation is not for the US market but for foreign markets.

The US exports 3.6 million barrels of crude oil per day for other countries to blend with lower grade crude, making it easier to refine. The US happens to have some of the best crude oil for this purpose.

The US is also the world's largest refiner of petroleum, and the world's largest exporter of refined petroleum products. Many countries do not have the capacity necessary to refine crude oil. The US buys foreign crude oil, refines it, and then exports the refined products back to those and other countries.

You can't just look at crude oil imports in isolation to determine if the US is a net importer or not. In fact, the US has been a net exporter of total petroleum products for several years now due to both its increased production and critical role in global crude oil refining.

<comment><USER11> We're particularly good at refining heavier, sour crude, but the sharp declines in Mexican and Venezuelan oil production and exports, and pipeline capacity from Canada maxing out has left us with overcapacity for those grades of crude. I wasn't able to confirm this with a few minutes of searching, but as I recall heavier Saudi crude has become attractive for this reason, plus Saudi Aramco fully owns Port Arthur, our big refinery, as of 2017.

</comment></comment></comment></comment></comment><comment><USER12> Both the NOPEC passing and the Sauds ditching the dollar would be great, but as the article says "The chances of the U.S. bill known as NOPEC coming into force are slim and Saudi Arabia would be unlikely to follow through(...)"

</comment><comment><USER13> I'm okay with this.

Maybe we can go off the oil addiction. Plus Saudi Arabis is very unsavory especially what they did to Jamal Khashoggi.

<comment><USER8> People keep making comments like that. I really wish someone would explain to me how that attitude makes any sense at all, given that the US imports 40% of its oil from Saudi Arabia (see my comment with links below), and has core military operations based in that country.

<comment><USER14> > I really wish someone would explain to me how that attitude makes any sense > at all,

The regime resorts to political assassinations on foreign soil even in petty issues that are insignificant at state-level. Do you have a problem understanding how that affects international relations?

</comment></comment></comment><comment><USER15> Last time I checked a lot of that Saudi wealth sits in dollar denominated assets. Good luck with the devaution!

<comment><USER16> Not only that the US are big fans of "freedom" and regime change for the sake of "freedom" when people want to ditch the dollar.

<comment><USER17> You kill two birds with one stone but I soubt they will invade SA anytime soon. It would be huge mistake...and for what?

<comment><USER16> Yes or you dress up genocide and usurping people's resources and pretend as if that's the case.

<comment><USER17> Let's face it: who likes dictatorships? To overthrone a regime there is a price to be paid and nobody will pay that price unless there is something to gain(i.e economically or geo-political). I'm ok with that as long as it's done right(which was not case with Iraq) but let's not pretend that it's moral to let these pesky dictators die by natural causes.

<comment><USER18> Sometimes we have not developed the methods yet to remove the cancer without seriously hurting the patient. (The country.)

That's just life. There should be a Hippocratic oath for geopolitical intervention.

<comment><USER19> In a country's case "the cancer" always has to be replaced with something. The US definitely has no working recipe for that, as several decades have shown.

<comment><USER14> Venezuela and Cuba demonstrate thay letting the cancer fester is not a good solution either.

<comment><USER19> Let's not kid ourselves, the US doesn't pour hundreds of billions of dollars _every year_ into the war effort because they want to fix "the cancer" and the locals' problems. They do it for political and economical reasons (power/influence/money).

Which is why all such regime changes bring no measurable increase in the quality of life of the local people. So then, from the perspective of the local Venezuelan or Cuban, what exactly is the difference between a festering cancer and a replacement cancer beyond looking at other countries getting richer / more powerful by extending their influence into yet another country?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Two others who wanted to stop selling oil for dollars were Sadam Hussein and Momar Gadahfi. In power for decades, then they announce they will sell oil for euros or a gold backed currency. Only a few years later from their announcement each one was dead.

</comment><comment><USER21> about to be a net exporter of glass

</comment><comment><USER22> Innocent children in Yemen who wouldn't burn to death from USA munitions might appreciate such a development...

</comment><comment><USER23> OPEC is a cartel we can get behind, simply because without them price of oil would be 3 USD / barrel.

We would be at 500 ppm if not for the irrational boycott of the West by King Faisal.

</comment><comment><USER24> > _Saudi Arabia is threatening to sell its oil in currencies other than the > dollar_

Dumb threat. Streisand effect, too—this bill just went, for me, from something I didn't know about to something that's on my radar.

Go ahead, sell in other currencies. Your buyers will bake in the swap costs to hard currency. It isn't like Mexican oil isn't sold for pesos or North Sea oil for pounds sterling or kroner. The petrodollar hypothesis is a myth. The United States, now [EDIT: nearly] a net oil exporter, does not depend on Saudi oil.

<comment><USER25> Why shouldn't europe then buy oil directly in euros? How does it make sense to first buy dollars and then buy oil if it is not mandatory? The saudis would happily take hard euros I suppose.

<comment><USER24> > _Why shouldn 't europe then buy oil directly in euros?_

Until recently, the Euro electronic transmission system was far slower, and less immutable, than the Fedwire system. This has recently changed. Otherwise, the superior investment environment in the U.S. ( _i.e._ higher yields) and broader international acceptance of dollars would be marginal issues. At this point, Saudi Arabia selling all its oil in dollars is a bit of an anachronism.</comment></comment></comment>


JSCert: Certified JavaScript - <AUTHOR> http://jscert.org/ <comment><USER3> You can't talk about JavaScript formal analysis for security without mentioning Mark Miller's amazing work here: [http://www-cs- students.stanford.edu/~ataly/Papers/sp11.pdf](http://www-cs- students.stanford.edu/~ataly/Papers/sp11.pdf)

Here, not only does he built a secure subset of JavaScript and _prove_ it's tamper safe using formal logic, Mark also finds exploits with the same method in high end tamper filters like Yahoo's.

Definitely impressive use of formal logic in language analysis.

<comment><USER4> Nice paper. Thanks for it.

</comment></comment><comment><USER4> Excellent work as usual in practical, formal methods by INRIA. Much of the formal work in academia amount to just screwing around or redoing the same stuff. INRIA is awesome because their work is often useful to the rest of us: robust languages, compilers, parsers, protocols, static analysis tools, WCET estimation, easier-to-use provers... list goes on.

INRIA and especially Xavier Leroy's people rock! That simple. :)

</comment><comment><USER3> It's probably a good idea to link to the presentation directly as it explains the point and methodology more clearly IMO: [http://jscert.org/popl14/?full#1](http://jscert.org/popl14/?full#1)

</comment><comment><USER5> I applaud every effort to improve Javascript as it all takes eons to download over my dialup but commonly does not actually work.

A favorite contribution is called something like "You Don't Really Need jQuery". I will dig it up,in a little bit.

Of most serious concern is how to convince the working JS coder to actually avail themselves of better javascript? Most dont read HN. I find it is of no use to point out the errors of their ways.

<comment><USER6> This isn't for that. This work is to create a formal model of Javascript - <USER2> definition of what a perfect Javascript runtime should do. The next step (potentially) is then that you can reason about Javascript programs in a useful manner - you could prove that your security-critical script does the right thing, for example.

Generally, such work does not lead to many updates to the state of the art - but is useful in its own way.

<comment><USER5>
       "I'm not really bad; I'm just drawn that way."
        -- Jessica Rabbit

I see your point, but my concern that the coder who implements a security- critical script doesn't know he should use tools like this one.

Lots of those who use other languages like to gripe about the many faults of PHP. While I agree that PHP has its problems I've used lots of languages that were far, far worse. My take is not that PHP is a bad language but that those who use it are often bad programmers.

Take Bill at [http://www.radioparadise.com/](http://www.radioparadise.com/) He at first built the sight with phpNuke, but rewrote it from scratch in the best of just a few days after "some boys from Brazil" overran it. Radio Paradise is still built on PHP, the difference is that Bill is an excellent engineer.

<comment><USER6> They shouldn't use tools like this one, though. This is purely a research project and not industrially usable. In any case, the purpose is to specify what Javascript is _supposed_ to do, and not what Javascript engines actually do.

The interpreter was as easily as not an afternoon project; they probably got one for free.

There's been some interesting discussion about this for the C language - useful yet undefined behaviours that are relied upon by many pieces of software, where a formal semantics such as this project may fall flat and lead to being overly restrictive.

[https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-...](https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey- discussion.html)

<comment><USER5> It would be a valuable contribution to publish the difference between what your tool says JS should do, and what production interpreters really do with that same JS source.

I expect there is an open source test suite available.

While at Apple in 1995 I came across a common in our system software that said "MacDraw needs this". Apple had a lending library with every third-party product that had ever been published, but for QA and bug isolation only.

My job was mostly to isolate crashes that were stimulated by third party code. About half the time it was their fault; to the extent we possibly could we isolated it anyway by reverse-engineering their binaries. Apple Developer Tech Support would work with the developers to help them fix it.

Sometimes its OK to depend on undocumented behavior, sometimes its not. Embedded systems for example might never receive new firmware so if the release firmware complies with specification then that undocumented behavior is completely cool.</comment></comment></comment></comment></comment>


This is how graphics in games matter - <AUTHOR> http://www.pocketnext.com/stories/why-graphics-are-important/

<comment><USER2> I wonder if it's really about the graphics though, or if it's more about the mystery of what's possible. Let's imagine something called the "possibility space", which is just roughly the set of things you can do in the game. Minecraft has a really large possibility space (build stuff, mine, survive, etc), Quake has a much smaller one (shoot things, navigate). Gameplay is largely about discovering what's possible, and then using that knowledge to achieve mastery over the system.

When you're young and you see a vista like that in ninja gaiden, you're intrigued by the possibility of what could be out there and what you can do with it. As you play, you discover the system, and in doing so, you also discover the limits of the system, and eventually as the space of possibilities becomes sharply defined, it eventually becomes uninteresting.

When you see a new game with prettier graphics, what the graphics imply is a new possibility space; a sense that more can happen here and the universe of possibilities is expanded.

The thing is, the graphics are secondary to what they imply about expanded gameplay. Graphics are feedback. Feedback is essential to gameplay, but it has to be evaluated in terms of a larger system.

I think this is largely why modern games seem a bit less magical than the old ones. They imply a lot of possibilities, but they rarely deliver; in fact, to support that level of graphics and polish they have to sharply reduce the space of what's possible. To display beautiful lighting you have to prerender a lot of it, or to show a greatly scripted cutscene you have to ensure that the player can't do something that would make that scene no longer make sense. But all of that reduces what the player can do, and how the world can respond to it.

<comment><USER3> What was the golden age of video games? 12.

</comment></comment><comment><USER4> It's not only the graphics. I am a few years older than the original poster and I very vividly remember the game that blew me away when I was (about) the same age: Thanatos.

<http://www.youtube.com/watch?v=zVSSxwXkPjE>

This game was simply a masterpiece, in every way. For a 12 year old, it was an unbelievable experience. The graphics were amazing, the animation free-flowing and beautiful, the stage where the drama was unfolding an almost infinite, dark world and the music so much unlike anything else that my trusty Amstrad's little speaker has ever sounded. The whole game had an eerie atmosphere, like a dream. Even the gameplay had original elements: your dragon did not seem to have hit points or an energy bar. Instead, the faster its heart was beating, the closer it was to death. Yet, you never knew exactly how close. Just like real life, that was the point. Being Greek, even the name had an impressive, majestic quality to me: Thanatos (the dragon's name) means Death.

Thanatos managed to create a completely immersive experience (at least to a 12 year old) through graphics, animation, sound, story, atmosphere _and_ gameplay elements.

</comment><comment><USER5> > _If a game is actually trying to create a breathtaking sense of presence, of > "being really there," then more believable graphics are certainly going to > help._

Minecraft, DwarfFortress, any of the Roguelikes are counter examples.

Graphics are important. Really awful graphics could kill a game. But amazing graphics on a rubbish game ("Rise of the Robots") don't help.

<comment><USER6> Yeah, I would say a certain internal consistency is more important than "realism" per se. Cartoons can be quite immersive, but I haven't seen a cartoony look in games pulled off at the level that animated films have reached.

<comment><USER7> Okami did; it was immersive and beautiful. Search for "okami screen shots" on Google images (the URL is longer than this sentence, including this parenthetical statement).

<comment><USER8> [http://www.google.com/search?tbm=isch&q=okami+screen+sho...](http://www.google.com/search?tbm=isch&q=okami+screen+shots)

You can trim a lot of the URL generated by Goggle. Just remember to look for the "tbm=isch" and "q=" parts.</comment></comment></comment></comment>


Dutch Scientist claims Neutrino aren't faster than the speed of light - <AUTHOR> http://www.pcmag.com/article2/0,2817,2394747,00.asp#fbid=eGNKoSY3C70

<comment><USER2> Speed of gps satellite 3,9 km/s Estimated speed of neutrino compared to light speed 7,5 km/s. Why twice the speed of satellite provided that it is a fault created by relative movement?</comment>


Databases always have a schema (2018) - <AUTHOR> https://utcc.utoronto.ca/~cks/space/blog/programming/DatabasesAlwaysSchemas <comment><USER2> At a high level there are names for what the author attempts to describe in computer science:

1) Schema on write

The schema is enforced by the storage layer when data is persistet, optimized for defined use cases and fast. ACID. Typical RDBMS systems.

2) Schema on read

This is was big data query processing and data lakes are about. Data is not interpreted or given meaning until it is read from the store and put into context.

Just thought that might add value to the discussion.

<comment><USER3> Thanks, I almost posted the same. One of the things that makes our field so great is the ability to learn independently, be productive and accomplish cool things without needing formal study. But it's also one of it problems where people can be great engineers but as aren't necessarily familiar with long discusses concepts or ideas. Even CS education frequently won't cover them because they aren't practical nor the main focus of theory.

90 percent of us on here have an intuitive understanding of these concepts but not having formal language, definitions and knowledge of really causes less efficient communication and the frequent re-invent the wheel syndrome.

Maybe the answer is software engineering becoming a more popular major separate fom CS, or maybe its introducing more classes on it. Or maybe it's a separate major or learning track on data modeling, programming languages, applying them problem solving, validation, data communication.

As a random example, half the debates on static vs dynamic typing - is muddied by explicit vs more implicit (ala Haskell) typing.

Heck most of us probably couldn't really give an authoritative definition of a schema, but we know it when we see it.

Examples for something to be a schema does it have to be in a separate document or in code. Does it have to be explicit or can it be implicit? Does it have to be statically checkable or do run time semantic checks count? Is there a complexity bound on validating against a schema (syntactic vs semantic checking may take very different run times)? Can a schema be defined as "whatever data structure and content is need to make this program X over here run"? Why? Why not?

Not having rigorous definitions here makes conversations in this spaces usually end up as people reusing the same word with different interpretations / meanings and disagreeing without realizing why.

I don't know how we do better. And absolutely acknowledge I suffer from doing it just as much as anyone else.

</comment></comment><comment><USER4> I would definitely prefer an approach where schema is explicit and defined in a minimum number of places. RDBMS/SQL schema do let you define schemas, however an important aspect of how SQL handles schemas which links back to their inflexibility is how they're defined at the level of a table, meaning a (possibly ordered) set of attributes.

A more flexible approach as taken by Datomic is to define schemas at the level of attributes, meaning an entity (table) does not have a schema, only attributes do. This requires attribute names to be within namespaces which can certainly be seen as equivalent to table names, but they don't have to, namespaces could also refer to an entire domain/subdomain/org/whatever.

Defining schema at the level of attributes provides a greater level of flexibility because client only declare/specify/depend-on a partial schema that only lists the attributes it needs. It also helps avoiding the "place oriented programming" approach of result sets, whereby attributes must be in a certain order, and if one does not have a value, you have to introduce NULL values.

<comment><USER5> Some domains or projects require or work better with "soft" schemas, at least initially. I always wanted "dynamic relational" where columns are optional and "create on write" (except for "ID", which is needed for row uniqueness guarantee). If you query for a column that doesn't exist, instead of an error, you get a blank for that column (or null, depending on design decisions or settings).

But, one can gradually add rules as the requirements solidify. You can later add a rule that all rows of the Employee table must have a non-blank "last_name" column. You can have a rule/constraint that requires it for new rows, and perhaps have a "cleaning mode" to check existing rows. With enough rules/constraints, it acts pretty much like the current crop of RDBMS.

Dynamic relational could still use SQL, with some minor modifications to clarify intended compare types. (SQL has warts, but nothing better has arrived yet that's sufficiently better to justify tossing an established standard.)

It's not SQL versus No-SQL, it should be strong-typed SQL versus "soft" SQL. That way one _doesn 't_ have to toss all their SQL/RDBMS knowledge to get a dynamic RDBMS. The current dichotomy of choice is _unnecessarily_ stark: it's either an RDBMS with SQL, or something very foreign. The No-SQL movement was driven by hardware & scaling needs, not query language needs.

If anyone is interested in starting up a dynamic relational company, I'd be glad to supply you with a draft spec for free.

<comment><USER6> You may have heard of it already, but if you haven't, I would recommend taking a look at RethinkDb: [https://www.rethinkdb.com/docs/architecture/](https://www.rethinkdb.com/docs/architecture/)

It is a NoSQL Db, but has a lot of the features you're talking about. It doesn't have any form of "schema", but does allow for SQL style relational data. It definitely supports your "dynamic relational" data idea as stated above. The only issue is that any sort of data constraints need to be addressed at the outside of the Db itself.

<comment><USER5> Interesting, but the "outside" constraint processor issue could be a show- stopper. The "gradual tightening" of the DB is a key selling point of dynamic relational. Parts of it could be borrowed to make DR. And it's not clear how one queries it with SQL (or something very close). A translator layer would probably be needed.

</comment></comment></comment></comment><comment><USER7> I don't necessarily buy the two schema argument brought up in the article.

If you generate your model/domain based on the underlying database schema then you effectively have a single view of the world, one that will ideally blow up at compile time (if your language is statically typed) when the database schema changes.

It's not perfect, if someone changes the schema in production then you're SOL, but at least it brings some sanity to the table vs. NoSQL where you simply have no idea what the state of the world is until you run your program.

F# Type Providers are probably the gold standard wrt to binding schema to application code, but any code generation library will provide similar benefit.

<comment><USER8> Correction: you have a single _authoritative_ view of the world, plus a secondary _cached_ view of the world in a different language which probably doesn't perfectly map to the original one. Many people choose this approach, but it isn't without its own issues.

<comment><USER9> > you have a single authoritative view of the world, plus a secondary cached > view of the world in a different language

Yes. OTOH, with NoSQL you have _no authoritative_ schema; your code may allow for multiple different schemas, and your records may have multiple different schemas, and they could agree or disagree to any extent.

<comment><USER8> You can still have an authoritative schema, it just doesn't live in the DB itself. It would have to be defined in the code, generally.

<comment><USER9> I would argue that it's not authoritative. Nothing guarantees that the records in the db match that schema; the closest you get to a guarantee is your diligence to 1) run a job mutating all records every time you change your in- code schema and 2) ensure that nothing but your latest application code can write to the db.

OTOH, `\d users` in PostgreSQL is authoritative; there cannot be a row that does not conform to the fields, types, and constraints listed there.

<comment><USER10> > I would argue that it's not authoritative.

I think the word you're looking for is "enforced". Where there are multiple schemas, one can certainly be the "authority", even if it's not enforced across all data.

<comment><USER9> Whatever terminology you use, every place you loop through records doing stuff with them, you'll either have to decide what to do with oddly-shaped records or implicitly decide to let exceptions occur at that point. Whereas if PostgreSQL tells you that `user` has a `email character varying(255) NOT NULL`, you can be sure that every `user` does. The only place you need a conditional related to that is when trying to insert an invalid record.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> The distinction between "database schema" and "data type" is the same impedance mismatch problem we've had for decades. You end up making an arbitrary transformation somewhere between your operational code and the persistence layer, at which time you have two different formats to represent your data. Any time you represent something twice, at least one of them is wrong, sooner or later.

The "schema" is the persistence-layer discussion of the contracts that programmers use to keep separate parts of the program consistent (even when they're divided up among developers, or with yourself over time). The persistence layer may use that information to provide additional services that it can't provide on a blob, like indexing. It's "natural" to do that for performance reasons: you want to lay stuff out on the disk, and limit network traffic. But in terms of code maintenance, that's optimization, and the root of all evil.

Few programming environments really take seriously the idea of eliminating that distinction. What I want is a language that pushes up notions like transactions and persistence right into the language itself, and let the compiler/VM take care of whether a piece of data is persistent or not. Ideally, I'd love a programming environment that could just be shut off at any moment and restore itself transparently, including unwinding that had become out of date. I gather that Inferno took that approach, but I haven't had a chance to use it.

The relevant bit of that is that it would eliminate the arbitrary distinction between "database schema" and the rest of your program. You'd use the same data specification for both, without a translator (or rather, with the translator completely hidden in the operating environment).

<comment><USER12> Hard to understand what you're proposing... A language with a type system that brings its own serialization format (so you don't have to deal with the fact that SQL and friends have no good way to represent polymorphic data types such as enums or interfaces)? Or a language with a runtime that uses disk as main memory (this seems to be the implication from 'program can be terminated and resumed transparently')?

<comment><USER13> Postgres has enums.

<comment><USER12> Postgres has a feature called "enums", but they are not polymorphic--all values for a given Postgres enum must have the same type.

</comment></comment></comment></comment><comment><USER14> Now, this is just my opinion but I hate ORMs for several reasons. Highest on the list is that I fundamentally disagree with their reason for existence. They're designed to help manage the code schema vs db schema "problem" stated in the article.

The database schema is for the integrity and performance of data storage. The code schema is for the integrity of the business logic and api. Forcing both schema to solve both problems is a huge and IMO unnecessary pain. ORMs attempt to be all things to all use cases and you often end up with a lot of hoop jumping.

They're not totally disjoint, of course. Its the same data so it will naturally be in a similar format and how code and db interact will often inform how the schemas are designed. The take away is, use the best schema for the current use case and solve the mapping along the intersections.

My sense is that this is where a lot of the passion for NoSQL came from although its a bit misplaced.

<comment><USER15> I agree although I think the biggest problem with ORMs is they're super hard to debug and reason about. You get all kinds of awful SQL out of them you might not expect

<comment><USER16> This is a tired point and in a decade of using ORMs this hasn't been the case, ever.

<comment><USER14> Why do you think the comment is so common if it was never the case?

<comment><USER17> Missing knowledge / lack of documentation. Django for example has a couple ways to see the SQL, but the most useful one (generating it from a specific QuerySet) I can't find in the documentation - I only know about it from an answer on StackOverflow.

</comment></comment></comment></comment></comment><comment><USER18> In my current case I have highly unstructured data stored as a jsonb in postgres with some basic fields for indexing. So the database doesn't have a schema and making many tables for each variation of the data would take an enormous amount of time.

<comment><USER19> > So the database doesn't have a schema

What you described _IS_ the schema of the database.

Schema doesn't imply rigidness.

A schema can precisely define a wild lack of structure.

The reason it's important to have it is because it keeps you in the control seat.

<comment><USER20> Another way of looking at it is that you have a schema whether you like it or not.

If I write some code to sum up account balances, it's going to expect a series of account objects, and they need to have some `.balance` field.

And those fields need to be decimals, because addition will choke if they're not.

Your code implicitly defines a schema, and it's utterly rigid because it will crash if the data structure is incorrect.

Or worse.

Imagine if some of the "balances" are actually some irrelevant field that happens to be a number, or some are missing because some of the JSON misspelled the field name and you skipped those records. Now the result you're processing is silently wrong, and who knows how far the corrupt data gets before someone catches it?

All schemas are enforced rigidly because that's how computers work. The difference is whether you want the DBMS to nag you while you're coding, or whether you'd rather be woken in the middle of the night by an angry customer or boss.

<comment><USER21> For many use cases we don't know the schema up front.

So it's irrelevant whether it exists or not because we don't know it.

<comment><USER20> That's a great point, but I think the real issue there is that typical SQL DBMS's make it very hard to adjust the schema iteratively as you code. After all, if you're writing in a language like Java, you don't know what your classes look like to start with, but coders manage that by adjusting and refactoring them as they work.

</comment></comment></comment></comment></comment><comment><USER22> Pretty interesting that the author was upset someone said SQL = Schema and NoSQL = No Schema. It's usually pretty clear that the no schema part is usually in reference to no certainty in the schema of the data. Or I guess one could model it as a spectrum of certainty.

Actually now mulling over it some more, I see their point. It's just that their consideration of schema is more holistic than typical. I find people tend to use "schema" to refer to what's in the database, while in code people refer to it as a "model", and that a schema is just an implementation detail of a model.

</comment><comment><USER8> This is a good take. I've been offended by this aspect of NoSQL for some time now, always using something like Mongoose to add schemas on top of it, but I'm starting to think that what I was really offended by was the lack of types inherent to plain JavaScript. It now occurs to me that a type system could be used to define the canonical form of a given DB schema.

I spent a year and a half at an enterprise Java shop, and there was a ton of work there put into maintaining and syncing the Java types and the SQL schema, even though that Java application was the only thing that would ever use that database.

I wonder what it would look like to have a schema definition system that was equally understood by the DB and the code, so you didn't have to pick one or the other or both.

<comment><USER23> > that Java application was the only thing that would ever use that database

It's a mistake to make this assumption unless you've taken extreme measures to lock down and audit all access. It's pretty common for the entire dev team to have read access, and someone has inevitably built some ad hoc thing taking advantage of that.

<comment><USER8> Perhaps I should've said "the only _piece of infrastructure_ that would ever use that database". DB browsing software and even ad-hoc scripts don't need a perfect schema; you can usually just grok it by visual inspection

<comment><USER23> That's a problem when we break something ad hoc the founder wrote to reconcile the books once per month. Data attracts surprising and important uses.

</comment></comment></comment></comment><comment><USER24> Very interesting. FWIW Martin Fowler, Pramod Sadalge et al have spoken about the implicit schema for NOSQL dbs from a design pattern perspective for quite a while now. Here is an early 2013 slide from him which is very informational - [https://martinfowler.com/articles/schemaless/](https://martinfowler.com/articles/schemaless/)

</comment><comment><USER25> He's correct that there's always a version of the schema in one's code — he's also correct that it's also nice to have a version of the schema in SQL, where certain properties can be checked & verified.

Wouldn't it be nice to have a schema DSL which enabled one to declare the schema _in code_ , and have it checked at compile time? Sounds to me like that'd be the best of both worlds.

And client programs could just import that package as a library, so every would be on the same page …

<comment><USER26> Isn't this what, for example, Django models are? Or even js simpleschema?

<comment><USER27> As far as I know, those only check at runtime (or when generating code), not at compile time.

<comment><USER26> What you mean by compile time, when we're talking Django and nodejs?

<comment><USER27> Yeah, that's part of my point. JS and Python can't even do what we're talking about here.

</comment></comment></comment></comment></comment><comment><USER28> In the context of this conversation, I assume we're talking about a single data store for all of an apps data needs. However, I'd argue in more modern application (newer) that one would design with a couple different data stores. using NoSQL for true data that can't be definied by a schema, and then the traditional RDMS when both ACID and schemas are needed. And then, there's several other types of data stores in between.

</comment><comment><USER9> > your stored data always has a schema, unless your code neither reads nor > writes it as anything except an opaque blob.

This is well-put. I'd go further: if there's no schema, you don't have data at all. A row with labelled email and name fields is data; a string of free-form input in which the user describe him/herself is not data. You might possibly be able to extract data from it, but if you do, you'll be building a set of labelled fields.

> You can tell that your code's implicit schema exists even with an SQL > database, even if your code auto-reads the SQL schemas, by asking what > happens if the DBAs decide to rename a bunch of tables and a bunch of fields > in those tables, maybe dropping some and adding others

Maybe a quibble, but I'd say your code has _partial knowledge_ of the relational db's schema, not that it _duplicates_ the schema, just as it may have knowledge of the file system structure, the domain names of various servers, etc, and depend on that knowledge being accurate, without duplicating them entirely.

> In some ways NoSQL is more honest than SQL, because it tells you straight up > that it's entirely up to your code to have and maintain a schema.

With a relational db it's _not_ entirely up to your code to have and maintain a schema. Eg, your code can assume that every "user" record has an "email" field and that it's NOT NULL and always a string and always unique, assuming the db is set up to guarantee that. The part of your code that reads records can be sure of that, even if the part of your code that writes records is lax about checking (and therefore blows up a lot). With a NoSQL database, it's possible that some records have blank emails, or numeric emails, or don't have that field at all, or have that field named something different. Those things will happen unless you're very careful to ensure in your code that they don't, and also unless you're careful to never to let anything write to the database except your code.

I think a differentiating question is "what is it that guarantees all your records of type X have the same schema?" If you use a SQL database, the answer can be "the db". With NoSQL it might be "a combination of app logic, background jobs and manual intervention for weird cases" or "nothing".

In cases where you want to store JSON blobs, an RDBMS like PostgreSQL lets you have a JSON column. This is useful (eg) for cases where you need to capture some input now, and might get around to parsing it out into real data later - eg "we got these records from the legacy system and don't yet know if / whether we can import them".

Finally, although I wouldn't advocate moving complex application logic to the database, there are some validations that can only be reliably done by the database itself or by leaning on the database. Specifically, any validation that relies on the _current contents of the database_ , such as "don't allow duplicate user names" (unique constraint) or "don't allow creating a comment for a post that was deleted" (foreign keys) or "don't allow overlapping reservations" (PostgreSQL exclusion constraint). Application code can do a read, check, and insert, but two threads may have a race condition and insert conflicting data. Application code can ask the db to lock while it does this, but that's leaning on the db. Or the database schema itself can guarantee this in a safe and performant way. But only if the database has a real schema.

</comment><comment><USER29> This blog sort of makes the definition of schema so broad that it ceases to have any real meaning. And it's a stupid argument to have anyway--whether or not something qualifies as being called schema. The point is how it functions, not what you want to call it.

I like to think of model code and sql schema as two branches of government in your data democracy. Where your code is roughly congress and your SQL schema is the supreme court. In a well-designed system, your code can do a lot of different things without running afoul of the courts. Code has quite a lot of freedom to operate on existing data and store what it needs for the future. But when there's a conflict, your SQL schema pops up and says, "No. You can't do that. That's in direct conflict of the stated goals of what this data is supposed to mean. Either don't do that, or go back and explicitly change what you mean."

Regardless of whether you want to call it schema or not, NoSQL is an extremely weak court of final appeal when it comes to deciding whether the code is obeying the intention of the data design. That is sometimes a problem and sometimes not.

In general, if you are dealing with data, you need type checking somewhere. Regardless of your opinion about programming languages, if you care about data integrity at all, it has to be checked for type correctness. Strong SQL schemas are far more important when the access layer is via dynamically typed or weakly typed languages. You can feel a lot better about a weaker schema if your language is statically typed. Sure, it's weaker and violates a certain separation of powers and flips the power dynamic to the code being final arbiter, but it's not always completely awful.

On the other hand, if your application code is written in javascript and your database has no enforced schematic constraints, your data is already corrupt. You just don't know it yet.

While theoretically we can account for weaker schemata in NoSQL data stores, the reality is that every useful dataset will eventually be accessed and written to by a client you didn't originally plan for. And that client isn't going to be aware of or play by the rules you intended to enforce in your code. So once again, your data is, in reality, already corrupt if you don't/can't enforce schema in your data store.

This isn't always a killer problem. There are a lot of cases where your data isn't all that important and this is an okay trade off. But pretending that application code is schema because you want to call it schema and it sort of does some of the same things so therefore schema is an energy field created by all living code that surrounds us, penetrates us, and binds our data together is just kind of bonkers.</comment>


Oliver Sacks's Twins and Prime Numbers (2012) - <AUTHOR> http://www.pepijnvanerp.nl/articles/oliver-sackss-twins-and-prime-numbers/ <comment><USER2> This is quite interesting and if in 1966 Sacks was encountering this unusual case of prime numbers in his patients, then this undoubtedly led to his life- long fascination with prime numbers, I suspect. He is well-known to have enjoyed a book on prime numbers published nearly 50 years later, The Music of the Primes: Searching to Solve the Greatest Mystery in Mathematics, saying "I could not put it down once I had started." I like to think that two autistic twins inspired in Sacks a life-long enjoyment of this area of mathematics; that random encounters that can shape your thoughts for decades.

<comment><USER3> It doesn't sound like Sacks had a "life-long enjoyment of this area of mathematics" from the article:

> Sacks mentions another algorithm to test numbers for > primeness. But his > description only shows that he has no > real mathematical knowledge that > matters in this case.

<comment><USER4> Enjoyment is different from understanding. Sachs career was all about studying (psychiatric) mysteries that were incomprehensible. It possibly gave him or fed his magical thinking, which can fly under the radar in psychiatry, but can't survive educated scrutiny in mathematics. He probably did love prime numbers, and discussed it with nonmathematicians who didn't see his mistskes.

</comment></comment></comment><comment><USER4> Sachs's popular books consistently embellished reality to make a better popular read, and never really got called out on it by the scientific community , perhaps because psychiatry was rather unscientific --or rather pseudodcientific -- thought the early decades of Zach's career. Sachs wasn't exremely harmful in this respect (relative to the horrors of pre-21st century psychiatry, including the folder it gave to the rise of Scientology to prey on The mentally ill), but still provided more infotainment than education.

It is interesting that the author claims that getting a 37% guess correct a few times consecutively, in one measured attempt, is unsurprising.</comment>


The Multi-Project Programmer - <AUTHOR> http://www.codersnotes.com/notes/multi-project-programmer/ <comment><USER2> From my perspective it's the threshold effect: in every endeavor there is a threshold which is hard to reach, but it gets easier for one to replicate similar things after passing it.

It is hard to find an important problem and create a viable mass market solution for it. By accomplishing this once, you get important skills such as time and project management, marketing and engineering skills etc. Acquiring those skills are hard work, but once you master them, you can apply those to everything you do. So naturally it gets easier to create new solutions.

There might be a network effect too. Creating a great project might enlarge your network with other people who are creating important solutions. I think this would set you in an interesting position; people would come to you with their most important problems they wanted to see solved since you have a proven track record. Ideas breed ideas. This might help with finding another important problem worth solving.

The most common thing about those creating great things time after time, is their production/consumption ratio. Humans tend to lean on consumption side and since the world is full of distraction we are wasting most of our valuable time on consuming info-junk. The over achievers I had a chance to meet were always skewed towards the production side. They almost always learned new things with a purpose. Also the threshold effect might be the cause of this high production/consumption ratio. Creating one great project might have created an emotional and hormonal concoction, a high, that motivates people to focus on creating things.

Accomplishing one great task, those people has the confidence and swag that they can achieve another one. People around them would cheer them up instead of hindering their motivation by reminding them how hard that task is. They would not remind them that they might be wasting their time by tackling that huge problem. They would find eager help and funding when they need.

Those are the first few things that came to my mind when I think about what factors might create multi-project programmers.</comment>


BLACK SWAN: "pictures" as we know will change if they start to speak - <AUTHOR> http://www.voxweb.rocks/share

<comment><USER2> Just wanted to say that the linked concept video that autoplays doesn't really convey the idea you were trying to get at, and the page itself doesn't really counterbalance that. You shouldn't need to describe your aspiration here in a comment! :P

Also, your tagline/logo (the red paint line) reminded me of an old ad for Memorex in a 1991 computer magazine, which used the same concept (to black print out as part of the ad) - I would never think, either naively or with my existing bias, that this logo is related to audio.

Just my 2¢.

<comment><AUTHOR> Interpretation of logo is subjective, this social networking app is about both pic and audio so it was never an intention to related logo with voice.

Regarding the video, all it wants to say is that the orange line is an indicator that the pic can speak.

On my comment, let's go by the merit of the argument rather than getting distracted by our team's aspiration. I repeat "speaking orange line pics" have the best of both pic and video and none of limitations of those 2 media.

</comment></comment><comment><AUTHOR> A "speaking pic" is something which is between a pic and a video - it has benefits of both and none of the limitations of those 2 mediums.

Moreover, nothing captures a moment better than a speaking pic - Before: concert selfie; Now: concert selfie which if touched can tell the live music being played.

</comment><comment><USER3> Looks good, can reinvent pictures category and make them exotic

</comment><comment><USER4> Superb proposition

<comment><AUTHOR> It's not an idea anymore. the real product has just gone live!

</comment></comment><comment><USER5> Great</comment>


Lessons learnt while saving my Pet (projects) : Hint - "Fake it" - <AUTHOR> http://planetunknown.blogspot.com/2010/10/lessons-learnt-while-saving-my-pet.html

<comment><USER2> About faking the deadlines - this has never worked for me. Honestly, how do you expect to fool yourself? I've tried to find a bunch of reasons to convince myself that keeping the fake deadline is important but the other half of me just knows that it isn't. How do you convince yourself?

<comment><AUTHOR> Seems the question remained on my mind for a while. I think the problem is "Convincing" the mind. You don't have to, I don't. I just "say" : "We have 10 mins. and then we have more interesting things to achieve, lets get this over with". Does it make sense ?

The book in the blog talks a lot about how we talk to ourselves. At times, just barking commands to the brain works, we just don't try it 8-)</comment></comment>


Open Iconic, a free and open icon set - <AUTHOR> https://useiconic.com/open/ <comment><USER2> So, OpenIconic seems to have none of the interesting features that Iconic Pro does (responsiveness, CSS styling, etc.). How is it better than other existing open icon sets such as FontAwesome, then?

I mean, I get that this is a 'freemium' version designed to entice designers to upgrade to 'pro', but if I have no intention of upgrading, the purely open options seem preferable.

<comment><USER3> > How is it better than other existing open icon sets such as FontAwesome, > then?

(From the homepage) I suppose it'd be these 2 aspects:

      - [...] designed to be legible down to 8 pixels
      - Our icon font WOFF is 11.1Kb (roughly 4 times smaller than Font Awesome).

<comment><USER2> Hmm. I'd like to see a demo of the first claim.

The 2nd claim is nice, I suppose, but FA also has 369 glyphs compared to 218 in OI, so the per-glyph file size advantage isn't actually that dramatic.</comment></comment></comment>


Telescope design promises to revolutionize amateur astronomy - <AUTHOR> https://phys.org/news/2017-07-telescope-revolutionize-amateur-astronomy.html <comment><USER2> As someone who has built his own telescope and been somewhat involved in amateur astronomy, this sounds like marketing bullshit to me. It reads like a press release. The first bullet point is especially damning; it's pure marketing speak devoid of any substance. Aperture diameter _matters_ \-- that's the total amount of light available. It's why when you want a better telescope, you go bigger. There's no way around that.

Bullet point #2 is nothing special; it's just using GPS for location and a clock to automatically point your telescope at a specific object. This has been around for a long time.

Bullet #3 appears to be talking about image-stacking, which, again, is a technique already commonly employed -- put your telescope on a computer- controlled equatorial mount, take many 30 second exposures (typically the max allowed by a DSLR) over the course of hours, and combine them in software. And I seriously doubt that you can get much utility out of stacking images taken by different telescopes in different viewing conditions.

<comment><USER3> > Aperture diameter matters -- that's the total amount of light available.

I think the point is the implied 'at that instant' which can be appended to your statement. Aperture matters in the context of a specific shutter speed.

You allude to that 'aperture is everything' loophole in your comment on bullet point #3, about image stacking.

<comment><USER2> It also matters for resolving power though. You can take photos using a 1 m telescope with a one second exposure that you could _never_ take using a 10 cm telescope at any exposure length. Keep stacking the photos for years, you're still not going to get the same detail.

This is why the latest generation of land-based optical telescopes have truly mind-boggling apertures. Bigger is better in astrophotography, full stop. [https://en.wikipedia.org/wiki/Extremely_Large_Telescope](https://en.wikipedia.org/wiki/Extremely_Large_Telescope)

<comment><USER3> Are you suggesting astrophotography has physical constraints that non-astro photography does not?

More specifically, to your example, if a 1m (diameter?) telescope takes a photo with a 1s exposure -- you're suggesting that it will resolve more detail than one taken on a 10cm lens for 100 seconds?

<comment><USER4> >Are you suggesting astrophotography has physical constraints that non-astro photography does not?

No, he's saying the diameter of a lens affects its resolving power. This is due to the diffraction of light bouncing off the lens. Larger scopes have less diffraction due to the laws of physics.

<comment><USER2> Lenses aren't used in "real" telescopes -- they're made out of mirrors only. Does your explanation still work?

<comment><USER4> The mirrors in telescopes are still lenses. You're probably thinking of refracting lenses as being "real" lenses. But the parabolic mirrors used in telescopes accomplish the same task. And, yes, diffraction is still just as much of an issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> > Enhanced Vision produces extremely sharp, detailed images of even faint > astronomical objects by accumulating their light and projecting it into the > telescope's eyepiece.

So... it pretty much works the same way every other telescope works? I read the whole article, but couldn't find a single detail about how it can actually resolve better than other telescopes of its size.

The video shows an augmented reality overlay. If that's what it's all about, then I'm really not impressed (if I wanted to see images other people have taken, I wouldn't be using a telescope). Let's hope that's not what they're referring to when they say "Our compact 4.5-inch telescope allows observers to see objects fainter than Pluto."

<comment><USER6> I read it as image stacking and an electronic viewfinder. Presumably B&W only.

<comment><USER5> Ah, that does make more sense, though you'd think they could mention it if that's what they're doing :)

<comment><USER7> It doesn't sound as magical if they say how.

</comment></comment></comment></comment><comment><USER8> I've spent the last several months building a platform to solve problems #2 and #3 with a (mostly) software-based approach. The controller is built on a Raspberry Pi, and it can control any servo-controlled mount or camera that is supported by OSS tools like Open Sky Imager, PHD Guider, etc.

I think this is preferable to a pure hardware approach because people can use their existing equipment, and they don't have to make a major upfront investment in something proprietary. The initial cost (for the controller) should be under $100.

My goal is to make astronomy more accessible to folks without deep pockets or STEM backgrounds, and to increase the pace at which we make discoveries in outer space. If anybody's interested in contributing to this project, or participating in the beta, please drop me a line (@freerobby on Twitter, or email@example.com).

More about my thinking, motivations, and plan can be found here: [http://astroswarm.com/2017/02/12/making-space-easy-to- study....](http://astroswarm.com/2017/02/12/making-space-easy-to-study.html)

</comment><comment><USER9> Alright so according to many comments high end telescopes costing thousands of dollars already have such features, or it possible to combine different products and systems to do the same thing. Fine.

The article isn't claiming anything unique, other than providing this as a single integrated product at an unprecedentedly affordable price. Is that wrong? I honestly don't know. The way I read all the negging I'd assume there are already products just like this at similar prices. Are there?

I honestly don't know. Just asking.

<comment><USER10> Quick search on Amazon seems to reveal some results.

I am the target market for this. I recently rented a cabin that had a standard telescope and although I knew exactly where Jupiter was it still took me 20-30 minutes to line it up just right. 5 minutes later a cloud moved over it. No one else got to enjoy it.

I need something pre-assembled, easy to use, and at or below $1k. Although I could deal with some assembly, this is not something I want to have to troubleshoot when the sky is clear and the urge to stargaze strikes)

<comment><USER11> There are plenty of options. Here's one: [https://www.amazon.com/Celestron- Nexstar-Schmidt-Cassegrain-...](https://www.amazon.com/Celestron-Nexstar- Schmidt-Cassegrain-Telescope-Case/dp/B00KWFFUS0/)

<comment><USER10> Thanks for the suggestion. After poking around a bit I realized I probably need to factor in weight as well. Good news for me since lighter is cheaper.

</comment></comment></comment></comment><comment><USER12> Here is a FAQ:

Q: isn't this physically impossible? Surely it has to be based on EVF with Stacking/Long exposure?

A: well _of course_.

</comment><comment><USER13> This is an ad. What's it doing here?

</comment><comment><USER14> Slightly more information: [http://www.unistellaroptics.com/en/product](http://www.unistellaroptics.com/en/product)

</comment><comment><USER15> > Enhanced Vision produces extremely sharp, detailed images of even faint > astronomical objects by accumulating their light and projecting it into the > telescope's eyepiece. Enhanced Vision technology mimics the light gathering > capability of significantly larger reflector telescopes

> Our compact 4.5-inch telescope allows observers to see objects fainter than > Pluto and achieve sensitivity equivalent to a one-meter telescope!

These claims are impossible for a direct-view optical telescope. But do they imply that they are accumulating photons on an image sensor and showing the image to the observer electronically - basically long exposure photography?

On a side note, the web page hijacks clipboard copying and inserts a source URL.

<comment><USER16> Yes, looks like it's long exposure photography but with the resulting photos displayed in real time:

"Turn Light Amplification on and the system will use its low-light sensor to accumulate light through a series of short exposures. The resulting image is projected into the eyepiece as the accumulation occurs, which means that once you start Light Amplification, you'll see something, but the object will keep improving with time."

Pretty neat idea.

<comment><USER2> That doesn't seem particularly revolutionary to me though. You can already do this with existing software used for image-stacking, though not directly through a viewfinder (though the "viewfinder" on a real telescope designed for astrophotography should be a computer display anyway).

<comment><USER16> That's a very good point.

I think what's revolutionary about it is the speed and simplicity. Sure, you can do this already with image stacking software, if you already know what you're doing or want to spend 600+ minutes learning how to do it. But this promises to just point and shoot and see almost equivalent results in near real time, a speedup of ~100x. So a two order magnitude speed improvement for the novice is a big deal, imo.

<comment><USER2> Yes, that does seem nifty. And it'll be good for pure stargazing scenarios, in which you're not attempting to record an image. For astrophotgraphy, however, it'll be a wash, as all you need a viewfinder for in those situations is to ensure that you're pointed at the desired object; the final output is always going to be best viewed on a proper display.

I suppose what this is really doing is bringing the benefits of some common astrophotography techniques into casual stargazing, which is cool. Too bad the press release doesn't explain it properly.

<comment><USER16> > Too bad the press release doesn't explain it properly.

Agreed.

Wasn't until I read the actual site ([http://www.unistellaroptics.com/en/product](http://www.unistellaroptics.com/en/product)) that I got excited.

<comment><USER2> Yeah, that's way better, and is actually something that might excite people who are into astronomy. The original article was written by someone who simply didn't know what they were talking about at all, and used copious marketing speak to try to make up for it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> A few years ago I saw a project to 3d print high end telescopes using smart phones to process the image at a maker faire. It was an open source design, I think this one

[http://www.openspaceagency.com/ultrascope/](http://www.openspaceagency.com/ultrascope/)

For myself although I'm not an amateur astronomer I think I would be more interested in something I could make/tinker with myself.

</comment><comment><USER18> Real-time image stacking can also subtract out light pollution. Imagine seeing the full width of Andromeda, 6 moon widths across, above suburban school grounds even on moonlit evenings. This will be an exciting way for kids to encounter astronomy.

</comment><comment><USER19> Soo... anything about price or ETA?

<comment><USER20> Right in the article. Crowd-funding starts this Fall, for "less than $1000".

</comment></comment><comment> barns-n-moguls Advertisement for a toy, accidentally posted on wrong website.</comment>


Being rich will kill your startup - <AUTHOR> http://www.whattofix.com/blog/archives/2012/02/being-rich-will.php

<comment><USER2> So close, and yet so far.

I like to the tell the story that a poor nerd can go into Fry's (electronics store) and get all the parts to build themselves a pretty decent computer, a rich nerd can go into Fry's and not buy anything. The difference is that the rich nerd _could by_ anything, and that choice freeze them. The poor nerd has a budget and has to work within it, so they have already done the work to maximize their value given their budget. Since the rich nerd has no budget they would have to analyze every possible system they could build out of Fry's parts to have the same confidence in their buying decision as the poor nerd has, and frankly there isn't enough time for that. Stalemate.

In the startup world there is an interesting and dangerous place called the 'self funded' or 'privately funded' startup. Those places have a hard time because there is nobody to call their baby ugly and question their assumptions. If your money isn't asking you questions about your existence then you won't ask yourself those questions.

I interviewed at one such and asked how they expected to make money. "Advertising" they said, their CEO was adamant that they had a unique position with respect to their customers which would allow them to advertise more effectively to them. And I asked "So why would people who are already spending their ad budget with Google advertise with you?" and the answer was "We are bringing new people to the Internet, people who have never advertised on this scale before, we're growing the market." And that was when I thought 'Oh really?' Now you could test that theory, you could survey your users and look at their advertising budgets and you could talk to ad agencies and look to see if they were trying to find new channels. But if you did all of that, it would dispel the illusion that the advertising market was growing, its actually shrinking in terms of total dollars (yes the Internet is disruptive again).

So Markham concludes that 'rich' startups failing because they spend all of their money buying products. The counter being that a 'poor' or 'lean' startup would be forced to husband their cash more carefully and build their own tools. The effect is there, but I believe the conclusion is not. One of the things that the poor startup is being forced to do, is develop a competency in being a company. Its not a state that everyone is familiar with.

Lots of people know how to be employees, but not how to be a company. Initially, those new to startups, aren't thinking so much about how long they have to live (as a company) as how much cool stuff they can do with that fat wad of cash. Perhaps they haven't experienced the pain of trying to raise money while working 12 hr days, or had a product they depend on go bad, mid- development cycle, and scrambled to replace it. There are lots of things like that which can, and do, bite you.

It isn't rich vs poor, its disciplined cash management vs undisciplined cash management. Doesn't matter where you start from if you don't respect the cost of capital you will fail.

</comment><comment><USER3> Honestly, this is completely absurd.

The majority of startups fail, period. If you analyze the people who execute successful startups, the amount of money or wealth they have is a non-negative factor -- in most cases having money helps. This is why people who are super successful with startups have many repeats.

<comment><USER4> I think you are taking the title literally. The OP is making an analogy of being rich - will try to throw money at every problem. If someone is short of money, he will deal with whatever he can get for cheap.

<comment><USER3> This has nothing to do with how much money a person has! This is yet another reason why many CEOs fail -- throwing VC's money at areas they shouldnt!

The original point in its entirely is absurd. Most are destined to fail, period. They come in all shapes and sizes, states of wealth, and food allergies.

</comment></comment></comment><comment><USER5> _Startups are about creating narratives, not consuming them._

What he seems to miss here is that some of the best businesses produce a consumable product after experiencing a problem first-hand and then deciding to go build a solution. If the narrative is clear from the beginning, then the part where "it actually starts working" will come much sooner.

<comment><AUTHOR> Remember that only part of the narrative, the end, is known by folks who are in the fix-my-own-pain game. The part about finding the business, the experience of using the service, etc -- all of that is yet to be invented. And the front-end of the business, the marketing/sales/delivery channel, is usually the hardest. Businesses are not simply products. (Although many certainly start from them.)

</comment></comment><comment><USER6> Having money is helpful for start-ups as it allows them to focus on a problem and solve it. The opposite side of the coin could be that when looking for solutions with lots of money their maybe less efficiency.

</comment><comment><USER7> For anyone interested, the book "Dreaming in Code" (<http://en.wikipedia.org/wiki/Dreaming_in_Code>) had this sort of idea as a central thread--one of the main failures of the Chandler project seemed to be that, armed with adequate funding, development lost track of reality and sprawled into some degree of failure.

Contrast with, say, "Masters of Doom" (<http://en.wikipedia.org/wiki/Masters_of_Doom>) where the early id software team was so pressed for cash that they would "borrow" their employer's workstations during evenings to write their code. That's what I would consider "scrappy".

<comment><AUTHOR> Even more to the point, and I should add this to the article, there are guys out there who have already spent 10, 20, 30K or more -- and can't even empirically demonstrate making something _one_ person wants. (And I'm sticking to off-the-shelf, low-end products that most of the HN crowd might be tempted by. Let's not even start in on the custom, high-end marketing plans and such. Very painful.)

But they can tell you a lot of stories about how all the stuff they bought is going to help them bring in millions.</comment></comment>


QIT: Find and listen to podcasts by topic - <AUTHOR> https://github.com/codingblocks/podcast-app <comment><AUTHOR> Someone posted this project on a Coding Blocks'[0] slack channel I think the idea is really cool and would like to contribute but don't have time so maybe someone of you find it cool to and find the time to help them. [0] [https://www.codingblocks.net/](https://www.codingblocks.net/)

<comment><USER2> Oh hey, thanks!!

</comment></comment><comment><USER2> Hello, author here. The app is still taking shape, but hopefully the gist is clear enough.

Podcast apps are typically organized around subscribing to shows, but I wanted something where I could focus in on particular topics. For example, I listened to most of the "PWA" episodes while working on this prototype.

edit: typo</comment>


Show HN: Transient – A tool for creating VMs for testing and development - <AUTHOR> https://github.com/alschwalm/transient <comment><USER2> I am not very experienced with VMs and containers.

Is this like Docker?

<comment><USER3> Sounds like a very barebones alternative to vagrant.

<comment><AUTHOR> We were actually previously using vagrant (-libvirt) for our CI, but moved away from it to this because vagrant does not seems to work very reliably when run in parallel. For example image downloading doesn't seem to have a filesystem lock, so one would succeed and the others failed.

In general, we wanted to be able to spin up our test VMs under docker containers to eliminate issues with differences between our CI shell-runners. Using libvirt based tooling makes that pretty hard. Calling to qemu directly, on the other hand, makes this easy.

There are some other benefits as well such as having direct console access which is not provided by vagrant, but can be very useful for kernel tests.</comment></comment></comment>