By the Bluebook implementation of Smalltalk-80 - <AUTHOR> https://github.com/dbanay/Smalltalk <comment><USER2> This is awesome!

I had the honor of first learning Smalltalk (and C++ and a bit of object databases) in a class taught by Bob Beck from Sequent. We actually had many students running Smalltalk on X terminals hanging off a Sequent server. [https://en.wikipedia.org/wiki/Sequent_Computer_Systems](https://en.wikipedia.org/wiki/Sequent_Computer_Systems)

Smalltalk was a crazy-productive programming environment in the '90s, and easy to love. (A bit like Lisp, in that regard, but also very different.)

What's even more amazing than that PARC was doing this in the 1970s, was that what we know as Smalltalk was only one part or step towards grand goals they were heading towards, not the end product. [http://worrydream.com/EarlyHistoryOfSmalltalk/](http://worrydream.com/EarlyHistoryOfSmalltalk/)

When we find ourselves strutting around about how smart we are, how we'll change the world, as we move fast and break things (with what power we can seize and exercise over our users, with our app)... a needed dose of humility comes from seeing that the Smalltalk (and other) people, of decades earlier, seem a thousand years ahead of where we are now, in thinking.

<comment><USER3> Which is why I was only impressed by UNIX until I started digging into Xerox PARC work, and its influences on Apple Lisa/Mac and ETHZ Oberon derived OSes.

The few UNIX variants that I actually still find interesting was the NeWS approach, NeXTSTEP and its descendants.

<comment><USER4> ETH Oberon was _not_ derived from Smalltalk. I implemented both systems, see [https://github.com/rochus-keller/Smalltalk](https://github.com/rochus- keller/Smalltalk) and [https://github.com/rochus- keller/Oberon](https://github.com/rochus-keller/Oberon) and can say for sure they have very little in common.

Wirth was inspired by the Alto, Dorado and the Mesa and Cedar programming systems. The Alto OS (the first GUI desktop and WYSIWYG word processor and DTP applications Bravo and Gypsy) was implemented in BCPL (precursor of C), not in Smalltalk. Many people seem not to know, but you can look at all the source code at the Computer History Museum.

<comment><USER5> There were common style elements across all the Xerox PARC software systems, the one not mentioned so far is Interlisp-D. I don't think you can claim that Wirth was only influenced by the BCPL and Mesa group.

<comment><USER3> In fact, Mesa and Mesa/Cedar developers explicitly refer to their goal to replicate Smalltalk and Interlisp-D developer experiences on XDE and Cedar, across their papers.

<comment><USER4> That only applies to the Cedar programming environment. Show me the references otherwise pls.

And it was even more remarkable that Xerox did not use Smalltalk for its GUI applications and the systems after Alto.

<comment><USER3> You are the one wanting, for whatever reason to relate Smalltalk to Modula-2/Oberon, when everyone has replied to you about Xerox PARC "work".

The references are in bitsavers, Xerox PARC section.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Congratulations!! I started a ST-80 on my TRS-80 w/an external gfx board in Z-80 asm, then tried to continue on my first PC in C, swapping floppies for each C compiler pass while temp files went to a RAM drive -- between the pitiful state of the "dev environment" and the difficultly in getting the ST VM image in the correct "magic" state for startup (and my inexperience) I never finished the thing. (I should have gone more the route of "A Little Smalltalk".) The experience makes me appreciate your work and the orig. impl. even more!

<comment><USER7> Did you ever see the system called "Methods" which was a TUI version of Smalltalk on the PC? I think it was by Digitalk.

<comment><USER8> It was a part of Digitalk Smalltalk/V for DOS. It can still be found at: [https://winworldpc.com/product/digital- smalltalk/12-dos](https://winworldpc.com/product/digital-smalltalk/12-dos) It does run under FreeDOS.

<comment><USER7> Thanks for the pointer! Very cool. As I understand it, it was the proof of concept for Smalltalk/V. Unfortunately, Smalltalk/V trashes the screen under DosBox with EGAColor, so I'll have to look into making it work better.

<comment><USER8> It doesn't play well with the current largish screen sizes. I got it to run on an eeePC 701, which has a 800x480 LCD Display.

</comment></comment></comment></comment></comment><comment><USER9> The Smalltalk books were a big influence on me when they came out, so I was happy when a company I was working for sublet space from Xerox PARC and we had meetings there. :)

Is anybody familiar with the various Smalltalk releases today and willing to do an overview of what's available?

<comment><USER10> ParcPlace spun off from Xerox to sell the original Smalltalk in 1988 but they sold that to Cincom in the late 1990s: [http://www.cincomsmalltalk.com/main/products/visualworks/](http://www.cincomsmalltalk.com/main/products/visualworks/)

Cincom had previously tested the waters by buying another Smalltalk called Object Studio.

IBM sold its VisualAge Smalltalk to Instanciations: [https://www.instantiations.com/products/vasmalltalk/index.ht...](https://www.instantiations.com/products/vasmalltalk/index.html)

Apple had the original PARC Smalltalk but never did anything with it until it evolved into Squeak in 1996, which was Apple's very first open source product. Later two forks went in different directions: Cuis and Pharo. [https://squeak.org/](https://squeak.org/) [https://cuis- smalltalk.org/](https://cuis-smalltalk.org/) [https://pharo.org/](https://pharo.org/)

Forking Little Smalltalk (an early open source text based Smalltalk) is a rather popular thing to do, so I won't give all the links. A bit more sophisticated is GNU Smalltalk: [https://www.gnu.org/software/smalltalk/](https://www.gnu.org/software/smalltalk/)

I consider Self to be Smalltalk, though not Smalltalk-80: [https://selflanguage.org/](https://selflanguage.org/)

There are Smalltalks based on Javascript, as well as an alternative VM for Squeak and friends: [https://www.amber-lang.net/](https://www.amber-lang.net/) [https://squeak.js.org/](https://squeak.js.org/) [http://u8.smalltalking.net/](http://u8.smalltalking.net/)

There are probably a few that I missed that are still in use.

<comment><USER11> Are there any quality implementations for Java or .NET VMs? One would think that this is the easiest way to get a high-quality GC today. And both ecosystems have some special sauce in them for dynamically typed languages - DLR in .NET, and I'm not sure if there's a single brand for that in Java land, but they've been busy adding features for the likes of JRuby for a while now.

<comment><USER10> Not having used them myself, I can't comment on the quality of the JVM based Smalltalks:

[http://www.redline.st/](http://www.redline.st/)

[https://github.com/hpi-swa/trufflesqueak](https://github.com/hpi- swa/trufflesqueak)

Another project that I watched without trying myself was for .NET:

[https://refactory.com/sharp-smalltalk/](https://refactory.com/sharp- smalltalk/)

There was also Essence# but it doesn't seem active.

</comment></comment></comment></comment><comment><USER12> This is so incredebly cool. Hat's off to you sir.

I've dreamed with doing the same. Now if you could make it compile in WASM and available from the browser window.

You might be able to bring smalltalk back to the forefront where it belongs.

<comment><USER8> There is actually a Squeak VM in Javascript ([http://squeak.js.org](http://squeak.js.org)) and there is at least Amber Smalltalk implemented in JS. [http://amber-lang.net](http://amber-lang.net). No need for WASM.

</comment></comment><comment><USER13> There is a Smalltalk books website out there somewhere with copies of all the old classics. I think Stefan Duccasse (Pharo professor) hosts it.

<comment><USER14> [http://stephane.ducasse.free.fr/FreeBooks.html](http://stephane.ducasse.free.fr/FreeBooks.html)

<comment><USER15> This is a good resource and includes my favorite Smalltalk book SmalltalkDesignPatternCompanion. This book made the classic GangOf4 patterns much easier to understand because it uses Smalltalk meaning much easier syntax focused solely on OOP which those patterns are much about. Design patterns are simple(r) when expressed in syntactically simple pure OOP.

Unfortunately it seems that something is missing here there is no chapter for the Visitor pattern which I remember as especially insightful. I had that book but it got burned when the house I lived in burned.

</comment></comment></comment><comment><USER16> Cool! I have a copy of the Bluebook sitting next to me on my bookshelf here, for many years, have often pondered doing the same. I had a similar reaction back in the 80s reading about Smalltalk. I had a set of encylopedias that included a page about Smalltalk with a couple tiny screenshots that blew my mind.

Thing is once I finally got to play with Smalltalk-80 in the 90s with Squeak, it just didn't click with me. I love and understand the language, I just don't find myself expressive in it.

</comment><comment><USER17> Well done. My first experience was with Smalltalk/V. I still have my well worn copy of the blue book.

</comment><comment><USER18> Looks very interesting and have always been interested in this era of optimistic computing. Does anyone know a tutorial or quickstart guide on how to get started using it? I don't really have a clue what I'm doing after opening it

<comment><USER19> You can try to follow these videos, but the commentaries are not in English. It shows:

\- basic windows management

\- expressions evaluation

\- code browsing

\- "explain" command

\- profiler

\- debugger usage, resumable exceptions

\- system modification in the debugger

\- objects inspection

\- system reflection (objects enumeration)

\- objects identity swapping

\- system navigation (senders/implementors)

\- all on system with only decompiled sources

[https://www.youtube.com/watch?v=JyaQavN9rVA](https://www.youtube.com/watch?v=JyaQavN9rVA)

[https://www.youtube.com/watch?v=cpjOd5ge2MA](https://www.youtube.com/watch?v=cpjOd5ge2MA)

</comment></comment><comment><USER20> This is the most hands-on exciting post I've seen on HN this year. Congrats!

</comment><comment><USER21> Phenomenal! Thank you for helping to preserve this piece of history.

</comment><comment><USER22> Can somebody elaborate on what the bluebook or greenbook is? I tried googling but nothing useful turned up. At least nothing related to programming.

<comment><USER10> In 1978 the Smalltalk group at Xerox tried to build a computer that people could buy. The Notetaker used several 8086 processors in a sewing machine form factor (like the later Osborn I) so you could carry around a computer with floppy disks, a mouse and windows. An executive came from the headquarters specifically to kill the project because Xerox didn't want to sell microcomputers.

Frustrated, the group got permission to license the language to run on other people's computers. All the other companies would have to do would be to implement their own version of the virtual machine and the rest of the system would just work. They made a deal with Apple, HP, Tektronix and DEC where these companies would get the language in exchange for having a small team help Xerox clean up the system and the draft of a book about the system by trying to do their own implementations.

This was eventually published with the title "Smalltalk-80: The Language and its Implementation" and became known as the blue book since that was the main color on the cover. It had four parts: 1) an explanation about the language and its concepts 2) a reference for all the classes and methods in the system 3) a large example in the form of a discreet event simulator 4) the definition of the virtual machine in the form of explanations and Smalltalk-80 code written in a style that could easily be translated to Pascal or C

Years later a version without the fourth part was released with a purple cover.

Before the book came out, a series of articles about Smalltalk-80 were published in the August 1981 issue of Byte magazine.

Another book was "Smalltalk-80: The Interactive Programming Environment" about the GUI. It became known as the orange book. There was another book that was planned but never released.

As part of the efforts of the implementation groups (now 5 since DEC shared its license with Berkeley) they had some mini conferences to share experiences and decided it would be great to make that into a book as well. "Smalltalk-80: Bits of History, Words of Advice" was the result and became known as the green book.

<comment><USER4> > Before the book came out, a series of articles about Smalltalk-80 were > published in the August 1981 issue of Byte magazine.

Smalltalk-76 was the first version that mostly (besides "one metaclass per class" and "blocks with arguments") corresponds to what we understand by Smalltalk today. It was developed by Ingalls and published already in 1978, see [https://dl.acm.org/doi/abs/10.1145/512760.512762](https://dl.acm.org/doi/abs/10.1145/512760.512762). This was the earliest publication about Smalltalk as far as I know.

<comment><USER10> There was an article in 1975 and two in 1977, but they were about Smalltalk-72 and didn't have too many details.

[http://www.vpri.org/pdf/hc_ACK_Pisa_1975.pdf](http://www.vpri.org/pdf/hc_ACK_Pisa_1975.pdf)

[http://www.vpri.org/pdf/m1977001_dynamedia.pdf](http://www.vpri.org/pdf/m1977001_dynamedia.pdf)

[http://dreammachin.es/Kay_SciAm_77.pdf](http://dreammachin.es/Kay_SciAm_77.pdf)

<comment><USER4> Interesting, thanks. Smalltalk-72 was a rather different system, i.e. didn't have much in common with Smalltalk-80 (in contrast with Smalltalk-76 which was almost there). I already have the Smalltalk-72 instruction manual from 1976, but I will gladly read the referenced articles too.

</comment></comment></comment></comment></comment><comment><USER23> Some of the most intelligent and thoughtful comments I've read on are on this thread. Sometimes the most vivid dreams are the early ones, before people adjust to the possible. There are a whole host of ideas of days passed that deserve revisiting. I wrote a little about them here: [https://blog.eutopian.io/the-next-big-thing-go-back-to- the-f...](https://blog.eutopian.io/the-next-big-thing-go-back-to-the-future./)

</comment><comment><USER24> Amazing work!</comment>


From 0 to 60: Our stats since we launched. - <AUTHOR> http://blog.twitalbums.com/two-months-in-the-making

<comment><USER2> This is more like from 0 to 2. You've spent zero dollars on marketing and... you have zero dollars in revenue, and not even a way for hypothetical heavy users who fall in love with your site to buy credits if they use up the 50 free credits that come with each new account.

Giving raw user numbers, or albums created, is a meaningless metric. You can always get people to sign up and try something once. How many users have created multiple albums? How many were active two weeks after signing up? How many would be willing to pay for credits?

I'm all for valedictory posts (and self-promotion!) but this is not much to look at yet. I would suggest you make your first priority giving people who actually want to pay you money the opportunity to do so.

<comment><AUTHOR> Actually there is a way to buy credits. Is located in the up-loader (inside any album). We are in the process of making it more visible.

I completely agree with you on giving people who actually want to pay money the opportunity to do so. I really like how you do it in <http://pinboard.in> by the way :)

<comment><USER2> Ah, I see - I was looking at the FAQ entry on <http://twitalbums.com/learnmore.html>.

I appreciate the compliment! But all credit should go to joshu for that pricing model.

For what it's worth, I think payments are one of the most painful parts of an app to work on. Any bugs catch people at their grouchiest moment (handing over money), and the available payment options all suck in various ways.

Best of luck to you guys!

<comment><AUTHOR> Thanks!

</comment></comment></comment></comment><comment><USER3> I think you should add a link directed to your service from your blog. For those who are lazy enough to type the link, here it is: <http://twitalbums.com>

<comment><AUTHOR> Thank you!

</comment></comment><comment><USER4> spanish speaker? you have "mayor" instead of "major" (que tengan buena suerte....)

<comment><AUTHOR> Gracias :)</comment></comment>


Why Vue (Not React) Is the New jQuery - <AUTHOR> http://anyonecanlearntocode.com/blog_posts/why-vue-not-react-is-the-new-jquery <comment><USER2> Trying to compare these new Javascript solutions to creating "apps" as the "new jQuery" does a great disservice to jQuery.

jQuery answered a great deal of the problems of the day in a way that abstracted away all the stupid stuff of the browsers we had to deal with. It didn't just make it easier to work with the DOM, it also made it easier to work with the browsers.

These new Javascript frameworks and libraries address different problems than jQuery. Some provide solutions looking for a problem, in my opinion, but many provide solutions that jQuery doesn't even begin to address and should not. In a way, this comparison to jQuery also does a disservice to these other projects. None of them are the next jQuery, they are their own thing and should be treated as such.

<comment><USER3> The point he was making at the start is that it didn't matter that jQuery solved those browser incompatability problems (so did umpteen other libraries), it succeeded because it was easy to get started and build on. The problem being solved is not the matter at hand.

<comment><USER2> I see the problem here. My main point isn't the problem that they solved, it's the impact they had on the industry. I say none of these new projects are having the impact that jQuery did. It's not a proper comparison that's beneficial to either side.

</comment></comment></comment><comment><USER4> Vue is really nice with simple examples. It does everything how you'd expect, quickly, and with little code. When you start building more advanced things you'll need to completely buy into the framework and that's when Vue gets a lot less pretty. I think React and Angular 2 are far better framework to learn and commit to.

So yes Vue is the new jQuery in that you can built smalls things nicely but good luck wiring up a large app.

<comment><USER5> Could you provide some examples to issues related to application scale?

<comment><USER4> I'm not saying it has problems at scale. I just don't enjoy building large scale things with it. It feels like a hacked jQuery lib with Redux and Angular packed into it.

</comment></comment></comment><comment><USER6> The arguments provided by the author are rather poor:

1\. setting up babel, webpack etc - you don't have to do the setup yourself, just use the cli ([https://github.com/facebookincubator/create-react- app](https://github.com/facebookincubator/create-react-app))

2\. learning es6 syntax - that's not a framework-specific problem, you could run into that w any framework (personally, I don't think it's a problem to begin with, since es6 is actually a lot nicer to work with)

It would've been a lot better if he showed what specific features of Vue make it easier to build apps w it.

<comment><AUTHOR> Fair points. I haven't played around with create-react-app much - it seems like a great tool, but it's important to note that a) it's pretty new, and b) it was created to address the very issues of what makes React hard to learn. What I'm not sure about is if the abstraction it provides will come back to haunt a beginner. It seems like the developers are anticipating a point where the basic setup is no longer suitable for a project with the "eject" feature, which means at some point you'll have to understand the underlying tool chain. This isn't a bad thing, but again, the learning path isn't clear.

As far as ES2015 syntax, it's not specific to a framework, but it is an extra thing that a beginner has to learn. Nearly every React tutorial I've come across takes heavy advantage of its features. And don't get me wrong - I love the new features and use them in my own code. But it's hard to tell the best way to teach a newcomer nowadays. Skip ES5 and only learn ES2015? That seems like trouble, you won't be able to read many existing codebases. Learn ES5 first, then ES2015? That seems like reasonable, but again, it's hard to get into React right away since you'll have to learn ES5 first. Again, these aren't problems for experienced developers, but it's daunting for a beginner to get started.

You do have a good point about showing specific features of Vue, this post was only trying to show the ease of getting started. I may follow up with a post to show some more specific features of building a larger app.

</comment></comment><comment><USER7> Vue is really nice, but React having React Native is a massive advantage. It isn't as beginner-friendly, but it's a massive ecosystem and I don't think Vue is ever going to topple it for the top framework.

</comment><comment><USER8> Has anyone built a large app with vue.js and compare it to React?

To me it seems more well-suited for small elements inside a regular page.

Single file components are awesome though, I'd love to have that in React (not a big fan of JSX).

<comment><USER9> I built some "medium" sized vue applications, ie a client ui for an upcoming multiplayer modification. the vue components play nicely together but your global store tends to get a little hard to read. sure, you can split it into even more files but that might just make it even more confusing. especially always adding mutations to the store is a pain in the ass. I also didn't find a proper way for built-in events and using this.$parent.$broadcast and co. feel like a hack. I eventually built my own event system for that. Other than that, I really like vue and would not pick anything else for my projects right now. I am excited for the upcoming changes in vue 2, iirc my complaint about Vuex will be solved too, then.

</comment></comment><comment><USER10> great. another addition to the javascript clusterfuck

<comment><USER11> React was released in March 2013. VueJS was started in Jul 6, 2014. It's not new.

We've had we've had both alternative existing concurrently for almost 2 years now.

<comment><USER10> okay

</comment></comment></comment><comment><USER12> Was digging around GitLab's source code yesterday to be very pleasantly surprised to see that they're using Vue in some places.</comment>


Deep Speech: Scaling up end-to-end speech recognition - <AUTHOR> http://arxiv.org/abs/1412.5567 <comment><USER2> I'll kick things off by linking to the comments from the last time this was posted: [https://news.ycombinator.com/item?id=8769067](https://news.ycombinator.com/item?id=8769067).

</comment><comment><USER3> >16.0% error on the full test set

Does anyone know, what was the error rate with previous approaches these days?

<comment><USER4> Look at Table 3 in the paper. Also, 16.5% error ;)

<comment><USER3> Oh thanks, and, wow!

</comment></comment></comment><comment><USER5> Github repo that I can compile and try?

<comment><USER4> Providing the source would be a step to improve transparency and reproducibility (the text does not provide sufficient detail for even someone working in the field to reproduce what they did so that he would arrive at the same results); however, the more crucial thing is the data. Switchboard, Fisher, and WSJ are available (provided you have a few grand to spend), but they say they collected 5000 h of read speech from 9600 speakers.. That's a huge effort!

<comment><USER6> An alternative source of data that you can contribute to:

[http://www.voxforge.org/](http://www.voxforge.org/)

</comment></comment></comment><comment><USER7> woo!</comment>


Toys from Trash - the-mitr http://arvindguptatoys.com/ <comment><AUTHOR> This takes me back quite a few years. Arvind Gupta[1] is the same guy who used to host a kids program in the early 90's called Tarang which was broadcast on national television (Doordarshan), teaching how to make toys from easily found household items. Watching this show was the highlight of my day as my family couldn't afford cable (we could barely afford electricity haha).

I remember quite a few of my summer vacations involved watching this show in the morning and spending the rest of the day trying to find the materials for building what he had built. He had quite an impression on me when I was young, I largely attribute the maker enthusiasm I had to him.

Just googled him, seems like he has an YouTube[2] channel now.

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

[2]: [https://www.youtube.com/user/arvindguptatoys](https://www.youtube.com/user/arvindguptatoys)

<comment><USER2> "His popular TED Talk: Turning Trash into Toys for learning gives an insight into his work and philosophy. This talk was among the 10 best TED talks compiled by Sir Ken Robinson and Sugata Mitra's 5 favorite education talks." (Wikipedia)

It's worth directly linking to. [http://www.ted.com/talks/arvind_gupta_turning_trash_into_toy...](http://www.ted.com/talks/arvind_gupta_turning_trash_into_toys_for_learning.html) [https://www.youtube.com/watch?v=KnCqR2yUXoU](https://www.youtube.com/watch?v=KnCqR2yUXoU)

He shows some amazing toy demos like (small spoilers) a drawing tool for blind children and a ¢5 electric motor.

</comment></comment><comment> a-ve Related (somewhat) :

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

Nek Chand Saini, a government official who started the garden secretly in his spare time in 1957. Today it is spread over an area of 40 acres (16 ha). It is completely built from industrial and home waste and discarded items.

</comment><comment><USER3> Really cool. Super interesting projects and really fun for kids.

If I can add something, I would maybe rebrand the "toys from trash" to "low tech toys" or something similar, that does not have the negative context of "trash". That's just my opinion.

Nice job anyway

<comment><USER4> I dunno, I like the title, it has a nice ring to it. But that also might be because the "trash" part reminds me more of Toy Story 4 than anything negative.

</comment></comment><comment><USER5> VERY cool! Kids love when you create fun toys from seemingly nothing. The accompanying Android app seems to be free with tons of instructional videos.

</comment><comment><USER6> I'm looking to make kids toys from United States recycling products since they are being moved to landfills. Almost no progress so far, my 400 level polymer chemistry book only has 2 paragraphs on recycling.

So far I'm trying to figure out mechanical solutions. Thinking lots of boxes so kids can make forts.

Hard website to use, unfortunate.

<comment><USER7> Have you had a look at the scientific literature? Something like this? [https://dacemirror.sci-hub.tw/journal- article/fdab0294ddc3bd...](https://dacemirror.sci-hub.tw/journal- article/fdab0294ddc3bdafaccddf645e8d4ceb/singh2016.pdf)

</comment></comment><comment><USER8> Contains the "Zen Mind, Beginner's Mind" book, which is an excellent book by Soto Zen teacher Shunryu Suzuki. I remebered his name from where I had found the book online.

</comment><comment><USER9> And then there's stuff that you can make out of trashy toys:

circuit bending...

[https://www.youtube.com/watch?v=KHDL9iGxDPM](https://www.youtube.com/watch?v=KHDL9iGxDPM)

[https://www.youtube.com/watch?v=K2Q9Ij7oUHM](https://www.youtube.com/watch?v=K2Q9Ij7oUHM)

</comment><comment><USER10> Lately, I've been recycling gummy tins into magnetic portable board games.

<comment><USER11> Show these, please.

<comment><USER10> Still on the early prototype phase. Step 1: sand off the painted labelling Step 2: repaint with game board (since prototype, draw on with sharpie) Step 3: make game pieces out of magnetic tape and "resource cubes"

The irony of this project is that I am in the US, and I'm taking covid lockdown seriously, ergo, I don't need portable anything.

Due to the small size of the tins, small board games are preferable: Bobail, small board capture Go, Alquerque, Fanorona, etc. Fortunately, many of these games have common boards and pieces.

<comment><USER12> Wow, that's a really good idea. Please post back here like GP said with pictures if you could!</comment></comment></comment></comment>


Ask HN: What's the next big tech hype? - <AUTHOR> So we currently have a front-page story about blockchain hype being over (https://news.ycombinator.com/item?id=18795274), and Ars Technica wrote about the autonomous-driving hype falling apart.
With two hypes now entering the Trough of Disillusionment, I wonder what's going to be the next buzzword.
Please don't suggest AI/ML. Only future hypes, or beginning hypes. <comment><USER2> XR. AR and VR already have the stench of death, people have no idea what MR is, but business executives might think they need an XR strategy or they will miss out.

5G. Carriers would be happy to sell you 100x more data, but you would have to pay 100x as much.

<comment><USER3> Otoh- military just placed 500m dollar order for hololens.

I think hololens will have a monopoly in ar and the rest will go away.

</comment></comment><comment><USER4> a-Deep generative/adversarial networks. b-Inverse reinforcement learning c-Translational robotics d-Brain-inspired buzzword computing

Sorry for a and b but they are in the beginning phase.

</comment><comment><USER5> Back to basics - indieweb stuff (indieweb.org)

<comment><AUTHOR> Sorry, but no. There is no way this will attract VCs and bullshit espousing evangelists.

<comment><USER5> Blockchain RSS. Checkmate.</comment></comment></comment>


Ask HN: Review my Startup - The New Social Times - <AUTHOR>

Hi everyone,
I'm looking for some feedback from the HN community. To give a little background information, a friend and I, both non-technical, decided to work on a startup last year and applied to YC Summer 2011. We weren't accepted and eventually pivoted our idea into something else around June.
The New Social Times is essentially a TweetDeck for news. A way for users to find top news stories across the web via social media, displaying results on a single page. We launched in Washington, DC a couple days ago. At the moment we're focused on gaining early adopters/serious traction; there's been good movement so far!
I'd really love to get some feedback from the HN community. Any comments would be greatly appreciated!
Check out the site at: http://www.thenstimes.com <comment><USER2> Heh, I wanted to make something similar! Good job.

You might have me login with twitter or something and give me a more customized news stream based on my interests (I really don't care about justin bieber for example). And maybe make a more common view pattern (that full screen thing is annoying me).

</comment><comment><AUTHOR> Is there any insight anyone else can offer? My partner and I would appreciate any kind of feedback, good or bad.

</comment><comment><USER3> <http://www.thenstimes.com>

<comment><AUTHOR> Thanks man. I meant to include a link.</comment></comment>


Safe Autonomy: Ensuring the Safety of On-Road Self-Driving Car Testing - <AUTHOR> https://safeautonomy.blogspot.com/2018/04/ensuring-safety-of-on-road-self-driving.html <comment><USER2> Some great points. Philip Koopman was also recently interviewed on the Smart Cars podcast.

[https://medium.com/smart-cars-a-podcast-about-autonomous- veh...](https://medium.com/smart-cars-a-podcast-about-autonomous- vehicles/smarter-cars-podcast-8ada58317b7c)</comment>


How we built Dojo Learning - Planning and designing new features - <AUTHOR> http://www.dojolearning.com/siteblog-post-action/id.36/title.how-we-built-dojo-learning-part-5

<comment><AUTHOR> This is the fifth part of a six-part blog post I wrote talking about how we built our startup, Dojo Learning, from my perspective as co-founder/lead developer.

This post talks about how we plan and design new features of our software.</comment>


Ultra fast highway charging network for electric vehicles - <AUTHOR> https://arena.gov.au/news/ultra-fast-highway-charging-network-for-electric-vehicles/ <comment><USER2> > Each of the 42 sites be able to charge two cars concurrently and will enable > the typical EV available in Australia to charge 100 kilometres within 15 > minutes using Tritium chargers

Went to a gas station yesterday that had 12 concurrent "chargers" and filled up 800 km in 5 minutes. Way more convenient.</comment>


Closed Source Engines Are a Big Risk - <AUTHOR> http://stephaniehurlburt.com/blog/2016/9/16/closed-source-engines-are-a-big-risk <comment><USER2> I fully agree with the author about the risk of Unity as a closed source engine.

Unity isn't just closed source, but your main access to the engine is through an ancient Mono .NET environment that hasn't been updated in years due to licensing issues. The latest re-licensing of Xamarin should help here, but as with many other features Unity will be afraid to make upgrades for fear of braking compatibility.

This means that most of the Unity game code that will set your game apart has to be written in C# 3.0, and your memory use and performance is heavily taxed, unless you resort to platform specific native plugins. As a game developer this scales down your ambition down to mostly casual games. The type of AAA games that Unity advertises are mostly distinguished by large amount of content, but nothing innovative in gameplay or technology besides what the engine provides. I can't imagine anyone starting a No Man's Sky or even a next Minecraft in Unity.

This is sad, because about 5 years ago I was cheering for Unity and having a lot of fun with some prototypes. They know they are a mill for casual clone games too, since they are shifting their business focus to online developer services like advertising and multiplayer hosting with per-player fees.

<comment><USER3> Microsoft really ought to buy Unity. Selfishly, it might prod them along to expand their .Net Core (or whatever they are calling it this week) offerings further.

XNA used to sit in this space, and it was a pretty nifty little game development platform for C#. Monogame has carried on, and expanded the target platforms nicely, but hasn't really made many other improvements, from what I've seen, getting back into it after a few years away.

<comment><USER4> It's unfortunate but Unity is a prime example of what technical debt can do to a product it seems.

[https://feedback.unity3d.com/suggestions/change-font-size- in...](https://feedback.unity3d.com/suggestions/change-font-size-in-unity- editor)

[http://forum.unity3d.com/threads/when-will-unity-support- hig...](http://forum.unity3d.com/threads/when-will-unity-support-high-dpi-on- windows.424958/)

<comment><USER5> I'm not quite sure how those two threads indicate technical debt. Could you elaborate?

<comment> loup-vaillant First thread is asking for a simple fix ("change font size" feature), that would really improve the usability of the editor. It has not been done for 7 years, which suggests that it's not an easy fix at all. It should be.

Second threads ask for support for high DPI. It's a simple scale issue, but somehow hard to do it on Windows.

Stuff that should be easy but isn't is a strong indicator of technical debt.

<comment><USER6> > Stuff that should be easy but isn't is a strong indicator of technical debt.

It can also be an indicator that there is noone working on it. It's common to have fix which are relatively easy but noone to implement them.

<comment> loup-vaillant Doesn't apply to obvious wins such as variable font sizes or high DPI. Those items are necessarily high priority, because of their low hanging fruit nature.

Or, they just get their priorities wrong, meaning, they're being stupid. Not a safe assumption in my opinion.

<comment><USER6> font sizes and high DPI are far from trivial changes.

> Or, they just get their priorities wrong

Most open source projects have very few or no people working at all. It's common to find bug reports opened for years that were never fixed. They don't have to be complex, just non-trivial.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> They are, and it's why I've vowed never to use them again.

I've contributed to Gang Garrison 2 (GG2), an open-source 2D multiplayer shooter (a "demake" of Team Fortress 2) for several years.

GG2 is built with Game Maker 8.0, an obsolete commercial game engine/RAD IDE product. Why? Because Game Maker 8.1 is buggy and broke things we needed, and its successor, GameMaker: Studio, broke even more (and is also much more expensive). We did try to move to GM8.1, but we had to give up on it.

This is unfortunate, because Game Maker 8.0, being now completely unsupported, does not even have working DRM servers. We literally have to pirate the product in order to continue development.

Game Maker 8.0 also produces executables that crash on recent versions of Windows when too many sounds are played simultaneously. This is probably fixed in newer versions, but we can't use them. So we have to work around it.

And "black box" bugs? This is a consistent theme of development with Game Maker. It's filled with them. There are lots of workarounds in our source code for such bugs. And there are some bugs we have never been able to work around, so sometimes the game crashes with inexplicable (i.e. incorrect) error messages.

Because of these experiences, any game I make in future will use an open- source engine. Proprietary engines are just too much of a risk.

<comment><USER6> > [Proprietary] engines are just too much of a risk.

ALL software are at risk of being poorly maintained and abandoned.

open-source VS free VS closed-source VS paid is not directly relevant to the direction and the future of a software.

What you need to do is a proper risk analysis before you pick an engine (or any important dependency for the matter).

<comment><USER8> But OS means you can fix the problem yourself instead of being at the mercy of the maintainer. We can use the parent post as an example:

> Game Maker 8.0 also produces executables that crash on recent versions of > Windows when too many sounds are played simultaneously.

If GameMaker were open-source, they could fix this. They could probably even backport a fix from 8.1 or Studio.

</comment></comment></comment><comment><USER9> This has been my experience with Unity as well. You can spin something up super fast but actually tightening the screws and getting every little last bug out and getting all the little interactions between gameobjects working just right takes a really long time simply due to quirks and bugs that require odd workarounds.

Unity is a wonderful prototyping tool but using it for production can be painful. That said I build engines for work so in my free time I like to just make games and using Unity for that purpose is refreshing and fun because the games I make in my spare time are simple enough that they rarely hit any limitations of the engine.

</comment><comment><USER10> The focus of a lot of engine dev is shifting away from AAA. For the AAA model, everything was about heavily optimizing the runtime performance of mostly- static scenes towards large teams delivering complex assets. The engineering team has skills and depth - enough to support every release with custom technology work. But new projects are often much smaller in scope, and that has a consequence for all the technology.

With smaller projects, pressure moves back towards development cost, ease of deployment and maintenance, which is a lot more like the model for small-site webdev. The necessary optimization for the runtime is more often at the level of just using correct algorithms, good-enough memory management, and feeding the GPU correctly. In turn, this is going to have a commodifying effect on engine runtimes - if your scene is already easily hitting its quality target at 144hz or whatever the high end is today, your concerns are just going to shift towards how fast you can iterate and debug, add and tune new assets, create one-off behaviors, and run off final builds for external use. You can hire for design rather than coding talent.

This favors a "game creation system" model like Ren'Py or Puzzlescript, where the underlying formats and protocols still allow a substantial degree of customization, including the possibility of moving the data to a different runtime altogether, but the developer's interface works on abstractions all tuned around that particular type of game. This path follows what's happened to audio with the development of synthesizers; after the early modular synthesizers proved the concept, a commercial market arose for delivering "complete instruments" that are less flexible in abstract, but are more portable, and offer an easier mix of performance and programmability, through presets and limited customization parameters. And today, for every popular genre, you can get started by "buying the sound" in the form of sample loops and synth presets, and then build out your own work by hanging off customizations. New genres appear simultaneously with the successful commercialization of new technologies - e.g. drum machines, or Autotune. There's no reason why games won't go in the same direction, given enough time.

</comment><comment><USER11> More generally, not having access to the source of the components most critical to your business as a tech company is always a giant risk and should be avoided as much as possible, if not at all costs.

</comment><comment><USER12> If you're using an engine you should be negotiating source access. I've never worked on any title where we didn't have complete source for both the editor and runtime.

Also when you evaluate engines what is there _today_ is what you'll ship with, don't plan on features down the road. A lot of studios learned that one the hard way with UE3 and PS3.

Lastly two devs seems like a really small number for even more than the most simple of indie games. For a lot of the reasons that seem implied in the article. Every game I've worked on needed to retrofit a different engine in significant ways unless it was a direct clone of the platform/genre it came from.

</comment><comment><USER13> I'm a bit confused about this article. One one hand Unity is criticized because it's a black box. The project was complicated, early days of VR and so on. "It was not fun. It was well worth the high rates we charged. It didn't help that we're still in the early days of VR, I'm sure."

On the other hand they did a very small project that was simple and for that they built their own engine and that was a lot of fun. "Building our own actually turned out to be a joyful experience. It was a simple app, didn't require a lot of features. It was an unexpected, fun breath of fresh air."

While I see how building something small and simple can really be a joyful experience, building something huge and complex for a client and supporting VR in this day and age is probably far from that.

Am I reading it wrong or is this apples and oranges?

And while I agree that having the source for the game engine is always preferable, often reading the comments (usually on facebook groups) makes it sound like EVERYONE has 20 years of experience in C++ and could actually fix everything as long as the source was provided.

<comment><USER14> Engines tend to orchestrate the flow of control. This breaks your app into small pieces that are easy to reason about. When things don't work however you are helpless as there is a black box in the center of your application with black internal state.

Having the sources is often useful as it helps you to * partition the black box * observe the internal state * observe critical control flows * maybe not 100% diagnose and fix but mitigate an issue

Generally engines and frameworks are bigger than needed. They may be well tested but the sheer volume means there are a lot of corner case defects of holes left. Frameworks are particularly risky as they are supposed to be adapted to new situations and as a rule writing software for future requirements is fraught with problems.

Special purpose frameworks often beat general frameworks hands down in size, performance and cost. Going with a large established framework from a "commercial" vendor is often seen as a safe choice by management and as the article shows it is not. Then on the other hand there have been plenty of teams going down naively the road of custom engines and finding that they did not have to re-invent the wheel but build an advanced gasoline engine and were failing at that. As always understanding your requirements, options and capabilities priceless.

<comment><USER13> My point was actually something else. On one hand it seems they've been struggling with Unity on a big project (where source might have helped) and on the other she said how they made this little app with their own little engine.

If you're building something simple and small It's easy-ish to build everything yourself. While if you're doing something big, the cost/benefit of doing it from scratch might be something else entirely.

My point was that for the second little project Unity might have worked brilliantly anyway. Or godot, or maybe any little 3D engine. While doing the first thing for a client, with VR support and God knows what might have been really really difficult.

Not sure if I made my point any clearer at this point really :D

<comment> loup-vaillant So, you need a more relevant example, right?

I think _The Witness_ might do it: it's a relatively big game, build with a custom engine. And it's quite clear it couldn't have been build with a classic engine such as Unity though telling why would be a bit spoiley. Likewise, Braid couldn't have been made with a generic 2D engine: its time mechanics are just too alien.

Another reason why Jonathan Blow chose not to use any 3rd party engine is, he wants his games to last. He wants the ability to port them to new platforms, and that ultimately means owning the code —if only to separate clearly the platform dependent parts from the rest. (I hope he'll release the code at some point, so others can continue that work.)

Being able to fix issues was also a reason. When you not only have the source code, but also have _written_ the damn engine, you can fix anything.

<comment><USER13> No, you missed my point. I'm perfectly clear why Jonathan Blow made it's own engine and why anyone who's capable of that would want the same thing. I was talking about the article and about some members of the game community and for that I have two criticisms

First: in the article she says that they struggled on one very complex project while using Unity. And then she says (or that's my understanding) that she made a completely different project on her own engine. That's why I said apples and oranges. I can't build unity, u4 or frostibe from scratch but if you want Pong or a simple platformer, sure, I can do that from nothing. That would be me saying: "well I had serious problems recreating the Witness in Unity but look at my space invaders which i made in Elm for browser without an engine".

The second problem I have is with some members of the gamedev community. Feel like a lot of people are ready to jump on the "I wish the source was available" train while very few of them (or at least that's my perception) know what to do with the engine source. Actually I could extend this point to a lot of advocate of the open source community. There is this false perception that anyone can fix anything that's broken because the source is available and yet a lot of those apps are sadly still very much broken and sometimes the authors of those apps have difficulties in finding people who might help them. But if you read any post about it online it's usually "closed source sucks and open source is brilliant cause we can always fix that anytime".

Sorry, this is a lot of generalization and obviously not everyone is like that but I tried to make point clearer this time 'this all.

<comment> loup-vaillant Okay.

About the second problem, I think it is one of control. Source code access at least gives you a fighting chance.

That said, I have used Qt a couple times, and never dared to delve in its source code, it's just too big. If I have a problem, I just work around it. If you want control over your engine/framework, you pretty much have to have written it in the first place.

<comment><USER13> Here I agree very much with you. With stuff so complex I can't imagine going through all that code. That's why I don't get people saying "if only I had the this or that source code".

<comment> loup-vaillant Well, there _is_ a middle ground: when you haven't written that big framework/engine, but _could_ have, delving into the source code in an as- needed basis may sound like a decent option.

Of course, you're hoping your framework is fit enough for your purpose, so that you rarely have to inspect it —if at all.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Well, that's why Unreal is starting to get back into it. It's also why id should be licensing their engines, and open sourcing them.

Bethesda/id/Zenimax, are you just afraid of money, success, graditude, and forming long-lived communities around your games that can mod and hack them, to keep the games feeling fresh, and thus people buying them, decades into the future?

<comment><USER16> This comment comes up often in the gaming community. My guess: they've done the math and the business gains do not outweigh the inputs. Between the codebase sanitation and the licensing issues with third-party products, that would be a pretty massive headache. There's the intellectual property argument to make as well.

For modding specifically, that also dictates how your game is built and requires extra work to do it right. Not every game needs it. The reality also is that it's easier to sell people games on a shorter cycle when the previous one doesn't have legs. I imagine the vast majority of the gaming population don't think twice about modability - they're happy playing a focused game and eventually leaving it behind.

<comment><USER4> To be honest I'm not sure that the game engines market isn't already saturated, raising the bar even further for a big AAA newcomer.

Like others have said it isn't just about 'opening your engine' and leaving it at that. All of a sudden you have to polish up your editor for external consumption (ooops.... the editor is crashing on this PC config that we've never had in the office?), write documentation and tutorials, putting out really good examples, engaging with this new type of community, etc.

Is there honestly room in the market for an engine without a clear niche these days? I mean you seem to have Unity and UE4 at the top tiers, then engines carving out a niche (Godot comes to mind), your lower-level stuff (how's OGRE doing these days?). There's a few random ones on Steam even (Leadwerks, GameMaker Studio, RPG Maker, etc) for other use-cases.

I think of CryEngine 3 -- that's the most recent move by a big player into the engines-for-everyone space. How is it doing these days? My impression is that it's struggling to get mindshare, but it has been awhile since I've looked. I'd be wary of bringing a new engine into the space after watching how that's going for them.

<comment><USER17> > I think of CryEngine 3 -- that's the most recent move by a big player into > the engines-for-everyone space.

There's also Lumberyard, Amazon's new entry into the game engine market: [https://aws.amazon.com/lumberyard/](https://aws.amazon.com/lumberyard/)

It's not Open Source, but you do get the engine and all the source for free. It's built on technology from CryEngine, Double Helix, AWS, Twitch, with a significant number of bugfixes, improvements, and features.

I'm genuinely excited to see where it goes, but, in full disclosure, I work for Amazon Games Studios (though not on Lumberyard).

<comment><USER18> "Q. Is Lumberyard "open source"? No. We make the source code available to enable you to fully customize your game, but your rights are limited by the Lumberyard Service Terms. For example, you may not publicly release the Lumberyard engine source code, or use it to release your own game engine."

[https://aws.amazon.com/lumberyard/faq/](https://aws.amazon.com/lumberyard/faq/)

</comment></comment></comment></comment></comment><comment><USER19> [https://godotengine.org](https://godotengine.org) anyone?

<comment><USER20> Been using this recently. It doesn't seem as incredibly simple as it sounds using Unity is, from how people talk (never used it myself), but it's pretty fun and has a lot of potential. I'm kinda hoping it will eventually manage to replace unity as the go to indie game engine.

</comment></comment><comment><USER21> I thought it was about ECUs, automotive systems, and that other sort of engine. The title is equally suitable.

With regards to debugging software, I think being able to do so effectively even without source is an important and rather rare skill. And sometimes, even with the source, the compiler can introduce its own issues. Being able to read Asm and follow along with what the CPU is actually doing is exceptionally useful, especially when working with lower-level languages like C/C++. One of my friends has a saying along the lines of "if you can read Asm, software has no barriers to understanding."

<comment><USER22> There is "reading asm" and there is "debugging millions LOC compiled with an optimizing compiler". The later is possible but the time requirements would be just impractical for game development. Even having the source without the ability to modify is almost useless.

<comment><USER23> If he confused the definition of "engine," he's likely coming from the auto world, where things are (_mostly_, not everyone drives $100k Elon Musk mobiles) still microcontrollers with kilobytes of flash and RtOSes. There, it's still entirely possible to debug execution interleavings and the like by just staring at the ASM.

<comment><USER24> I think your information is a bit behind.

My old car, a 2002 BMW 325i, fits that description with a 25 MHz 16 bit Infineon C167 processor and 512kb of flash in its Siemens MS43 ECU. That's properly a microcontroller in my mind.

My new car, a 2015 Ford Fiesta ST, has a 133MHz 32 bit Infineon TriCore processor and 4MB of flash in its Bosch MED17 ECU. That's more than many PCs had until the late 90s, so while it's definitely running a RTOS I have trouble calling it a microcontroller.

That's not even a new ECU either, a friend's '09 VW GTI had basically the same unit. Anything with direct injection almost definitely has a 32 bit ECU, especially if a turbo is involved. I'd imagine a higher end car these days has something more potent (or just doubles them up, like BMW used to do on V12s).

</comment></comment></comment></comment><comment><USER25> What is the current situation with Unreal and CryEngine? (both are at least state-of-the-art)

</comment><comment><USER26> Yeees.... but, in Unity's defence, for an indie dev I can see the appeal because it allows you to target all of the platforms (not actually an exaggeration).

DISCLAIMER: I _don 't_ use Unity because, at the time I started getting back into game dev, I think you still needed a plugin to run in browser whereas I wanted to target purely HTML5, JavaScript and CSS for maximum device compatibility (hah!). That may no longer be true.

The thing is, I could make the same point as this post but about developing cross-browser games with standardised web technologies. You can waste days at a time fixing behavioural quirks that appear in only one particular browser - I've done exactly that fixing bugs in iOS Safari, whereas I don't even bother supporting Edge in Windows 10 Phone (yet) because very few people use it.

I've had a full screen bug in iOS appear multiple times in both of the games I'm currently working on - a "nearly done" version of Star Castle ([https://arcade.ly/games/starcastle/](https://arcade.ly/games/starcastle/)), and a very alpha-ish take on Asteroids ([https://arcade.ly/games/asteroids/](https://arcade.ly/games/asteroids/) \- takes a while to load due to graphics pre-generation, which I need to sort out) - due to very minor changes in markup and CSS. They largely share both an engine, along with many front-end components, so issues like that tend to affect both games.

Actually, my "engine" really isn't an engine at all: more an assorted set of libraries of useful functionality that can be bolted together to help build games of a certain type.

Back to the point, some browsers are open source but it really doesn't help because I can't (easily) change what's deployed on millions of peoples' computers around the world. Having access to the source _might_ make it quicker/easier for me to come up with a workaround. I doubt it though because, for example, Firefox has a _lot_ of source code, which it would take weeks to understand before you could figure out why it was behaving oddly in a particular case. It would just be easier to create a workaround. (Of course, it's fragile - the next release of FF might break your workaround, and then you have to have a workaround for the workaround for that release and later.)

I could make the same points about building on top of any platform, open source or otherwise. I've spent a lot of years professionally doing .NET and Java development. With .NET I spent years building desktop tools for developers and DBAs, and we couldn't redistribute a custom runtime so, again, you have to put in workarounds sometimes.

I'd still say the leg up these platforms gave us was worth the hassle of having to deal with some bizarre pieces of behaviour (and we did occasionally encounter some really nasty issues, like race conditions involving database connections, and suchlike).

With web development on an OSS platform and framework I can see it might be different. You have complete control over your deployment environment, so you can put the fix directly in the Fx and submit a patch, if that's the best way to deal with it.

Likewise, if you're distributing the runtime yourself you have control and can apply the fix in its code rather than a workaround in yours. But whilst it's easy to say that the reality probably wouldn't be, and it might cause headaches in the future.

The costs of building your own engine are pretty clear:

\- You start from nothing, so it's harder to make progress initially,

\- If you want to hire people well, there's a pool of Unity developers, but nobody with experience of your engine,

\- Say you start developing for PC but want to release a PS4 version of your game: adding support for more platforms is going to be a _lot_ of work (I don't just mean dev: Unity is tested across all platforms they support, but now _you_ have to do that for your engine),

\- When your game engine gets large and complex it's going to start exhibiting hard to debug behavioural quirks, just like everybody else's; you might be able to figure out why more easily, because you have the source, but that doesn't mean the fixes will always be easy.

So, yeah, closed source game engines are a risk, but then so are open source engines, as well as engines you create yourself: they're just a different set of risks. Which you choose should be defined by the objectives of your project(s).

<comment><USER27> Unity's WebGL support has, in my experience, largely been in name only. It's just such a horrifically bad experience that I just can't imagine anyone taking it seriously.

<comment><USER28> Especially if you want to support mobile: [http://blog.playcanvas.com/playcanvas-versus-unity- webgl/](http://blog.playcanvas.com/playcanvas-versus-unity-webgl/)

<comment><USER26> That result doesn't surprise me too much - it's another reason I chose not to go with unity. The total JS payload for Star Citadel is still <100K, which makes a huge difference when you're talking about hitting the site from a 3G connection. The total page size runs into the megabytes but this can be attributed to two factors:

\- Music and sound effects, which are queued up and loaded in the background (it's even possible to play the game with missing music and SFX, and you'll start to hear them once they've loaded).

\- Google Adsense content. This ticks me off because some of the ads are _very_ poorly behaved. Some load relatively large amounts of content, and can often block page loading. I've therefore pushed the Adsense script itself right to the bottom of the page so it doesn't result in other requests from the game being blocked. I'd vastly prefer it if Adsense restricted ads to plain text or simple images, banning active content and Flash (which, at least up until recently, was still appearing). The reason for the ads is I need to cover the costs of the site, never mind actually earn a living, but I want to do so in a way that doesn't detract from the player experience.

<comment><USER27> Stripe integration for a few dollars "support the developer if you can" is really easy to setup and I've gotten a lot more money out of it (tens of dollars) then I've ever gotten out of advertisements.

<comment><USER26> Interesting - thanks, I'll have a look.

</comment></comment></comment></comment></comment></comment><comment><USER29> Closed source is organized syndicate;

</comment><comment><USER30> The Pro subscription from Unity gives you source code access.

<comment><USER31> No it does not, at least not to the full engine and editor. Source access is separate and the price is unlisted, although rumours are that it's six figures:

[https://store.unity.com/products/unity- pro](https://store.unity.com/products/unity-pro)

<comment><USER32> Source is $40k up to 50 seats, and then it jumps to $100k. It's pretty obscene. The worst is that Unity will fight you if you say you need the source, like it's a crazy request.

<comment><USER6> Think how much are the salaries to fill 50 seats => $40k is a drop in the sea.

I can understand that this pricing model doesn't appeal to amateurs and micro teams working in their free time. I can also understand that Unity doesn't care about this [non] customer base.

</comment></comment></comment></comment><comment><USER33> Shipping a game with Unity is hard/risky? News flash: shipping any game is hard/risky.

Source: shipped games, all had last minute hard to find problems. In-house engines every time.</comment>


GitHub is down - <AUTHOR> https://github.com

<comment><USER2> Is it?! It's working like a charm for me.</comment>


Ruth Bader Ginsburg Assigned a Supreme Court Majority Opinion for the First Time - <AUTHOR> https://www.bustle.com/p/ruth-bader-ginsburg-assigned-a-supreme-court-majority-opinion-for-the-first-time-in-her-career-8848135 <comment><USER2> Duplicate [https://news.ycombinator.com/item?id=16889760](https://news.ycombinator.com/item?id=16889760)</comment>


Fingerprinting Firefox users with cached intermediate CA certificates - <AUTHOR> https://shiftordie.de/blog/2017/02/21/fingerprinting-firefox-users-with-cached-intermediate-ca-certificates-fiprinca/ <comment><USER2> This is brilliant, especially the idea of loading content from correctly configured sites to set bits, loading incorrectly configured sites to test bits, and using an error-correcting code in case the user happens to visit some of the correctly configured sites before returning.

The right fix would be to either always fail a site load that doesn't serve the right intermediate certificate, or do what Chrome and IE do and always find and load the intermediate certificate.

<comment><USER3> Always failing the load seems like the right approach to me, it would also have the advantage that it makes it easier to see if your site is correctly configured or not.

<comment><USER2> Agreed, but if a significant number of websites would suddenly start failing (and only in Firefox), that could break things for too many users. Might require a more gradual transition.

<comment><USER3> Those sites already fail for Firefox users though, right? Just randomly, depending on what other sites they've visited first.

<comment><USER2> Not if, for instance, they're domains associated with some main site, such that people have always visited the main site first.

Someone looking to make such a change would need some data on whether any such cases exist on prominent sites.

</comment></comment></comment></comment></comment><comment><USER4> It reminds me of the HSTS Super Cookie [https://github.com/ben174/hsts- cookie](https://github.com/ben174/hsts-cookie)

<comment><USER5> Looks pretty bad. Isn't this the first ever cross-device super cookie?

"Safari - Especially scary - since the HSTS information is actually persisted to your iCloud account and is therefore retained across devices."

</comment></comment><comment><USER6> Is there a way to clean up cached (intermediate) certs without having to nuke your entire firefox profile?

<comment><AUTHOR> I believe removing cert8.db from your profile directory will do trick. (Beware that this will probably remove other certificates, too.)

</comment></comment><comment><USER7> Is there any impact on the tor browser bundle which uses Firefox?

<comment><AUTHOR> From [https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c18](https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c18) :

 _Tor Browser 's current defense against cached certificate-based tracking is to set "security.nocertdb" to true_

<comment><USER7> Thank you for your reply, I appreciate it.

</comment></comment></comment><comment><USER8> How many uncomfortable side effects need to arise from the CA system before we decide to do key verification in a different way?

<comment><USER9> Is there even a viable and scalable alternative? Genuine question.

<comment><USER10> By using the existing domain allocation system. Sign all delegations of domains, and use this assertion to build TLS trust.

As long as TLS certificates sign domain names you trust that delegation, so having an alternate trust root is stupid (and having 391 of them is beyond stupid).

<comment><USER9> I don't see how that would be a _significant_ improvement though.

Firstly, given how many domain registries and registrars there are, there still would be a ton of trust roots (probably way more than 391). Secondly, this would significantly increase the difficulty of managing a domain registrar, and would probably lead to decreased competition in the space (more expensive domains?). And thirdly, the client would still need to manage trusted certificates locally, so client-side complexity is unchanged.

Most importantly, the benefits of a new system must vastly outweigh the cost of migrating to it.

<comment><USER10> The registry/registrar system may not be perfect, but that's what we have (and there is an appeals process). It's not as bad as you make it seem. You can not redelegate google.com for example, even if you work at a registrar. Whereas any CA could generate a new certificate, today.

As long as domains are what you generate certificates for you might as well assert that delegation in a cryptographically secure way. It may also be a good basis to make domain transfers more secure.

</comment></comment></comment></comment></comment><comment><USER11> I've been asking browsers to provide per tab security isolation for a long time. Would make many of the attacks much less efficient. Each new tab should be clean as well as closed tabs should get destroyed.

</comment><comment><USER12> Most browsers will still connect if the leaf certificate has certificate authority information access extensions, the browser can use them to download intermediate CAs, and then construct a valid chain back to a trusted root. Does Firefox not do this?

<comment><AUTHOR> From [https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11](https://bugzilla.mozilla.org/show_bug.cgi?id=1334485#c11) :

 _Another approach to this problem is to do AIA chasing (that is, fetch the URI in each certificate to attempt to find an issuer). Firefox currently does not do this for performance and privacy reasons. Doing each fetch is slow (you would probably want a cache anyway, and so would still be vulnerable to this attack). Also, a CA (or even an untrusted party, since you can 't verify the trustworthiness of the AIA field until after you've already fetched data from it) can use this to track users._</comment></comment>


Ask HN: Just bought Ipad 3, please suggest free ebooks to read on kindle app - <AUTHOR>

I am interested in any kind of free ebook that deals with inspiration, attitude, efficiency, startup, real estate, learning etc. <comment><USER2> Kindle Nation Daily: [http://kindlenationdaily.com/kindle-nation-daily-free- and-ba...](http://kindlenationdaily.com/kindle-nation-daily-free-and-bargain- book-listings/)

100 Zeroes: <http://hundredzeros.com/></comment>


FDA and NIH let clinical trial sponsors keep results secret and break the law - barry-cotter https://www.sciencemag.org/news/2020/01/fda-and-nih-let-clinical-trial-sponsors-keep-results-secret-and-break-law <comment><AUTHOR> I just listened to the book Bad Pharma, by Ben Goldacre, which deals with this problem. The author works as a doctor and so has a bit of an inside view of how the industry does 'science' and how this affects doctors and patients.

The lack of published negative results isn't a problem unique to pharma but the drive for profits and the actual life and death outcomes makes it particular severe in this area of science, I think.

I highly recommend the book, it was both hilarious and terrifying.

<comment><USER2> I must note that according to the linked article, "pharma's record has been markedly better than that of academia and the federal government". It's academia that is not reporting results, not industry.

<comment><USER3> That's an illogical conclusion.

Both don't always report results. Academia is worse. That doesn't make the industry good in any way.

<comment><USER4> I don't know what problem that would solve. Academia rarely does trials that end up killing people. Unlike the whole CAR-T cell therapy. Companies like Juno killed almost 50% of their patient, before the FDA halted their trial, which was allowed to resume later, and kill more people. Granted they where going to die anyway. Still the like of Hans Bishop who us held as a hero in the industry because he sold his company for billions, while the product will never be approved. Even if were to be, it would sit on a shelf because it's too expensive. So much for transparency...

(Edited some typos)

<comment><USER5> I'm standing right now near the window on the 20th floor of a cancer center, typing this on my phone while my wife sleeps 10 feet from me.

This is high stakes medicine, yet the current environment has the docs on this floor terrified of doing anything that isn't in the standard of care runbook. My wife has had elevated blood glucose levels for six months, which is not good when you're fighting cancer, yet i can't get anyone to treat it because there's no clinical evidence that managing glucose levels for her specific type of cancer has any benefit.

Guess what. Nobody's doing that trial any time soon. Meanwhile there are thousands of diabetics managing their blood glucose while fighting cancer and there is endless material available demonstrating that cancer cells thrive in hyperglycemic environments.

So, i don't know anything about Juno, they could be sociopaths. But i have no issues with high risk attempts as long as the patients are informed and there are ethical standards for transparency. At least they are trying.

<comment><USER6> I sympathise with your wife's predicament. Good or sub-par treatment, doctors still get paid.

If you're not opposed to eschewing professional recommendations to not complicate treatment, there are two things that may be worth looking into:

1). Metformin: Helps control blood glucose by significantly increasing sensitivity of insulin receptors, i.e more glucose is shuttled out of the blood stream per insulin molecule. Not scheduled and very cheap. Also trials are being done on it for cancer prevention -- exactly because of Warburg's phenomenon (cancer cells and glucose)

2). Ketosis: Hit or miss. By abstaining from carbohydrate consumption, the result should be drastically reduced blood glucose levels. However, in some people (e.g type 2 diabetics) it may _elevate_ blood glucose due to metabolic disfunction. In any case, caloric restriction in general have the effect of both increasing insulin sensitivity and decreasing blood glucose -- regardless of macronutrient profile

<comment><USER7> The doctor though should be able to provide access to a clinical dietician to help think plan the diet and think through the implications. I imagine some chemo and targeted drugs could interfere with lipid metabolism and there is also a risk of acidosis. So I would ask the doctor. It will probably be a case of "we don't know" but diet is basically the one variable under your control besides listening to the doctor.

There's one paper on it from a completed clinical trial. [https://www.ncbi.nlm.nih.gov/pubmed/27525031?dopt=Abstract](https://www.ncbi.nlm.nih.gov/pubmed/27525031?dopt=Abstract)

Also clinical trials using metaformin during cancer treatment. You might consider enrolling in one of these if it is feasible.

[https://www.cancer.gov/about-cancer/treatment/clinical- trial...](https://www.cancer.gov/about-cancer/treatment/clinical- trials/intervention/metformin-hydrochloride)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I don't care about whether they report results or if they miss deadlines for reporting. That's all this article is talking about.

But _only_ studies that are pre-registered should be considered when approving a drug, treatment, or device, and any incomplete studies (that is pre- registered but not reported for any reasons) should be treated as "all the patients died", and all individual researchers on the preregistration should be appropriately tainted for future consideration of studies in which they participate.

The related story in the article, "Gaming the system" does report on this:

> .. a recent study ... examined 19 drugs approved by the FDA in 2015. In only > 10 cases were all the trials provided to FDA for its decisions registered on > ClinicalTrials.gov.

This is unacceptable.

<comment><USER9> All of the punishments you suggested and also any involved patents released to the public domain since the data wasn't.

</comment></comment><comment><USER10> Hiding research results should be seen as this scandalous, shameful, and fundamentally anti-scientific practice. A heavy bias towards business profits, which is exactly what this is, goes against objective science.

What if you kept repeating experiments, and only published when you got the results you wanted? That goes against my personal ethics _and_ my understanding of how science is supposed to work.

<comment><USER11> > What if you kept repeating experiments, and only published when you got the > results you wanted?

This is pretty much how it's currently done. Science is far less exploratory than you make it seem. When it comes to publishing you should think of it more like law. You make the strongest possible case for your conclusion.

<comment><USER12> This is very backwards. In science, the evidence for a claim is precisely how hard you tried to disprove it. This doesn't mean that you're wrong, of course, but it's a massive problem.

<comment><USER13> That's only a subset of experiments, the ideal experiment makes any result publishable. For example the search for a new particle, don't find it that's fine. Alternatively, any result that's in doubt like salt's impact on cardiovascular heath.

Even better is really cheap experiments like analysis of existing data. That you can keep trying until you find something, sadly this means publishing datasets is a bad idea.

</comment></comment></comment></comment><comment><USER14> Perhaps unbeknownst to some folks, the FDA as a regulatory body is funded in large part now by Congress but by GDUFA and PDUFA which allows the agency to collect user fees for both brand and generic drugs from the drug makers themselves, in essence being funded by the industry it is meant to regulate. So it is then understandable why a lot of the guidelines become flexible (note that the FDA cannot enact laws, that is the duty of Congress)

<comment><USER15> This is a very common complaint, but the other side of the coin is that FDA needs resources to do its job and any time the number of submitted drugs changes the FDA would need less/more funding from congress if it was funded only by congress. Collecting fees means the size of FDA's funding is correlated with the amount of work it has to do. The proper way to determine whether FDA is unduly influenced by this is to look at the actual decisions it makes, which is something I remember reading medical researchers already tried to do.

<comment><USER14> GDUFA guarantees a decision within 10 weeks, which is considerably better than the running average before and even extreme cases such as 13 years before addressing applications.

There are unfortunately many cases that have been decided on the basis of finances rather than clinical justifications. I don't envy the agency, stuck between the disdain of the public, pressure from industry, and continually having to justify their existence to Congressional committees.

</comment></comment></comment><comment><USER16> > Few trial sponsors have consistently done so, even after a 2007 law made > posting mandatory for many trials registered in the database.

Then the reality is, it wasn't mandatory.

It's not reasonable to expect citizens to trust these entities when their conduct is not trustworthy.

</comment><comment><USER17> If there ever has been a sector where mandatory full transparency is useful then medicine would be a good candidate. The outcome of trials could be very useful for other researchers.

Same should apply for pricing. The fact that prices are completely opaque in the US makes it hard for patients to make good decisions.

</comment><comment><USER18> I'm kind of shocked that logging these results isn't already common practice.

</comment><comment><USER19> I think this is the primary purpose of the FDA (though not the NIH). Providing a shield from transparency, and even against criminal liability, is just another part of regulatory capture.

</comment><comment><USER20> Coincidentally, I've just heard Milton Friedman talk about "Health Care in a Free Market". Fascinating and eloquent.

He argues that the FDA did more harm than good, and that society would be better off without a governmental supervision for health care in general.

\-- [https://www.youtube.com/watch?v=-6t-R3pWrRw](https://www.youtube.com/watch?v=-6t-R3pWrRw)

btw, in the end he makes a strong argument _for_ negative income tax. This surprised me, as my model of his world-view was apparently more simplistic that it ought to be.

<comment><USER21> I disagree. FDA have set guidelines for clinical trials and moral standards to it. For an example you cannot experiment on a person without their consent and you have to state out what your trials is doing. It all lay out. It's because of Tuskegee syphilis experiment that we have IRB and FDA.

FDA also love stating that they prevented a drug that causes birth defect a while back unlike Britain.

Another example of government regulation working is cars. Death relating to car crashes have fallen every year with safety regulations.

It's not perfect but there are many cases that it works and there are laws and rules set in place.

The free market is not the panacea for everything.

<comment><USER22> Falling car crash rates don't prove regulation is successful. Consumers shop for safety too. It's difficult to compare the counterfactual, but to make this claim, you need to at least compare the rate of change of crashes in unregulated countries or times to regulated countries or times.

<comment> kube-system For both auto safety and pharmaceutical safety there is a large degree of consumer information disparity, information unavailability, and disincentive for the individual to protect the public interest. It takes a lot of resources to test those products, and consumers don't really have the resources to do it themselves. In some cases, insurers could possibly foot the bill (eg. IIHS), but that model still has a couple of big weaknesses: consumers may not be informed enough to parse the results, consumers might prioritize short-term needs over public health, and an insurance body may still have some incentives working against public benefit.

Things like truck under-ride guards likely wouldn't be on commercial trucks if they weren't regulated. Consumers aren't going to all voluntarily coordinate to buy vehicles which have crash-compatible bumper heights. Antibiotic misuse would be even more out of control if it weren't regulated.

Mexico is a good example for road regulations. They do not have the same crash regulations as the US, and many old model vehicles are still legal for sale there. Things like the 1950's VW Beetle were still sold there into the 2000s. They have the highest death rate per distance traveled in the world.

</comment></comment></comment></comment><comment><USER23> The pharmaceutical industry is full of unscrupulous bastards, news at 11.

</comment><comment><USER24> The FDA operates as a corrupt organization and, if wasn't a government agency, would be prosecuted under RICO.</comment>


The Year of Merging for the Vertical, Horizontal and Conglomerate - <AUTHOR> https://www.mnpg.co/the-year-of-merging-for-the-vertical-horizontal-conglomerate/ <comment><USER2> best example of bitcoin buzzwords to fill an article</comment>


Take a screenshot every minute and see how you're spending your day - <AUTHOR> https://github.com/tjluoma/screenshot-journal

<comment><USER2> This is just like some spyware my employer used to put on everyone's computers, years back. Weirdly, this was not a feature they seemed to be aware of - everyone was taken by surprise when some nearly-full hard drives started filling up, and when I asked if I could clear off these images from my computer, the answer was, "What images? ...Huh. Yeah, go ahead."

I actually created an HTML front end to conveniently flip through the pics for just this purpose.</comment>


Fed Chair Says Economic Recovery May 'Stretch' Through End of 2021 - <AUTHOR> https://www.nytimes.com/2020/05/17/business/economy/fed-powell-economic-recovery.html <comment><USER2> Selling optimism. Makes it seem as if recovery from this magnitude will be so fast. I don't think so, not with trying to go back to business as usual.

<comment><USER3> There's the recovery from the pandemic, and there's the economic recovery. The Fed chair is speaking about the economic recovery, not the pandemic recovery. The economic recovery will be faster the faster we get back to business as usual... _if_ we don't have to lock down again.</comment></comment>


What if video games could help fight climate change? No, really - <AUTHOR> https://www.wired.co.uk/article/climate-change-game-design-simcity-civilisation <comment><AUTHOR> After watching the BBC documentary on Climate Change a key issue seemed to be trying to get across what the issues are, most people are completely lost. Is David Attenborough the Gandalf of our age?

I remembered how a previous BBC documentary on games noted the history of games to get issues across. Computer games perhaps, but are there any good boardgames?

Perhaps using the GNS (Gamism - Narrativism - Simulationism)theory of game play:

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

My mind is still jangling from the Geeks Guide to the Galaxy Podcast on the history of Tabletop RPGs

[https://geeksguideshow.com/2019/07/09/ggg369-the-history- of-...](https://geeksguideshow.com/2019/07/09/ggg369-the-history-of-tabletop- rpgs/)</comment>


Show HN: Ambar – Corporate Mail Monitor and Archive - <AUTHOR> https://ambar.cloud/monitor/ <comment><USER2> Keep your corporate message flow under control. Monitor messages and attachments, be notified of every information leak. Create a universal archive of all your corporate message data. Easily find any message or attachment by any phrase. Works with almost every mail server. It's opensource.</comment>


Annie96 is typing.. - <AUTHOR> http://storiesforyourscreen.com.s3-website-eu-west-1.amazonaws.com/ http://storiesforyourscreen.com.s3-website-eu-west-1.amazonaws.com/annie96-is-typing/ (updated url) The creepiest chat history you will ever read. <comment><USER2> Awesome site. The text message effect is refreshing

</comment><comment><USER3> Creepy as heck, but I guessed the twist.</comment>


RediSQL reach v0.6.0, with real integration with Redis - <AUTHOR> http://redbeardlab.tech/rediSQL/blog/release_0.6.0/ <comment><AUTHOR> Here the author, if you have any question feel free to ask.</comment>