Amethyst – A tiling window manager for OS X - <AUTHOR> http://ianyh.com/amethyst/ <comment><USER2> I posted this yesterday in the thread about the Rust-written window manager, but it's relevant here as well.

There are plenty of apps that provide varying levels of window-manager functionality to OS X. I would try a couple out and see which feels right to you. I have tried most of them, and personally prefer Moom.

[http://manytricks.com/moom/](http://manytricks.com/moom/) [http://mizage.com/divvy/](http://mizage.com/divvy/) [http://ianyh.com/amethyst/](http://ianyh.com/amethyst/) [http://spectacleapp.com/](http://spectacleapp.com/) [https://github.com/fjolnir/xnomad](https://github.com/fjolnir/xnomad) [https://itunes.apple.com/us/app/bettersnaptool/id417375580?m...](https://itunes.apple.com/us/app/bettersnaptool/id417375580?m..). [https://github.com/sdegutis/mjolnir](https://github.com/sdegutis/mjolnir)

<comment><USER3> I swear by Spectacle. After trying a number of other wms, this is the one I ended up using for more than a year now. It strikes a good balance for me between features and simplicity, and the keyboard shortcuts are intuitive and don't clash with other apps (like iTerm, Fantastical, etc).

<comment><USER4> You should try BetterTouchTool. It can do everything spectacle can, but has a lot more features, and support for trackpad gestures, and other nice things. It even has draggable window snapping like Windows/Ubuntu Unity.

<comment><USER3> That's what I used for about a year before Spectacle, but it's too heavyweight for my taste.

</comment></comment></comment></comment><comment><USER5> I'm the Amethyst developer. I'm happy to answer any questions people have. I'm hopping on a cross-country plane flight in about an hour, but I have a layover. I'll try get back to people as soon as I can.

<comment><USER6> Is there a way to set up custom layouts? Eg, I'd love to have a variant of tall/wide-tall that puts the main area on the right side of the display, rather than the left.

<comment><USER5> Not yet. I've toyed with different ways of doing this, but haven't really decided on one that I really like. Maybe I should just go the road of other window managers that expose a scripting interface. Write a javascript file or something that defines a function that takes a list of windows and some other parameters and returns frames for the windows, binds to commands for modifying layout state, etc.

<comment><USER6> Would it be simpler to just define a couple "mirrored" variants of the main layouts?

<comment><USER5> Yeah, there's already an issue to track that ([https://github.com/ianyh/Amethyst/issues/129](https://github.com/ianyh/Amethyst/issues/129)), but in general it seems like people want more flexibility in defining how they want things to tile.

</comment></comment></comment></comment></comment><comment> shawn-furyan I've been using Amethyst as my WM for a couple months now, and have used XMonad for significant stretches in the past.

Amethyst tries to bring the XMonad experience to OSX. I think it does an admirable job, but there are some distinctions. Amethyst is simpler to set up, and is more forgiving to newcomers. It has a GUI for configuration, and an easily accessible list of commands. It also works on top of OSX's WM, so it's not so enormous a departure, especially compared to XMonad's fairly extreme dismissal of the mouse.

On the down side, XMonad really outshines Amethyst when it comes to performance. Amethyst is downright sluggish, where I've always found XMonad to be very responsive. Still, it's overall a true enough translation, and the sluggishness rarely actually hinders productivity. Overally, I think Amethyst is a capable daily driver, and a great intro to tiled window managers.

<comment><USER7> To me the performance of XMonad detracts from the trope that Haskell isn't performant (which I've been hearing/seeing lately).

<comment><USER8> I mean, its often slower than hand tuned assembly mixed with Fortran if that's what you mean.. Otoh,most things are

</comment></comment></comment><comment><USER9> I like tiling managers, but dislike having predefined layouts. Being able to split any tile horizontally or vertically arbitrarily many times is the way to go (i.e. i3-style). Would like to see tiling wm authors to consider this option when starting new projects.

<comment><USER5> It's on the list of things I want to do. I should have used a tree structure off the bat and done something like binary space partitioning.

</comment></comment><comment><USER10> As someone who's relatively new to tiling window managers (I've used manual ones like Divvy and Moom quite a bit though): is this approach only really effective with large monitors?

I've given Amethyst and other WMs a shot in the past and been instantly annoyed when they automatically tucked away windows into unusably small configurations. Is this part of the learning curve and addressed by proper configuration, or should be avoiding this for use on small screens? e.g. a MB Air 13"

</comment><comment><USER11> Am I the only weirdo who just uses multiple workspaces with ctrl-arrow and cmd-tab like a mad man? I genuinely enjoy it, especially with a second monitor.

I, maybe, have one or two apps sharing a single workspace. Most apps are in full screen.

<comment><USER12> You are not. :) I don't usually use full screen mode for apps when my Macbook Pro is docked, but when I'm just using the laptop screen it's ended up being surprisingly useful. (At least I was surprised.) Docked I'm usually only using two virtual desktops, sometimes three.

Mission Control gets slagged on more than it deserves -- it's fast and functional. On point for the actual link to Amethyst: I use Moom for window resizing/control from the keyboard, but in practice the mouse is actually pretty darn efficient when what I want is to make a window _this_ big and put it over _there._

</comment></comment><comment><USER13> Wow. This has focus follows mouse! (though they call it "mouse-follows-focus", for some reason)

I've been told focus follows mouse was impossible on OS X.

<comment><USER14> Who told you that? You could do it with just applescript if you wanted to, just need to enable accessibility so you can control windows and the mouse.

<comment><USER13> I've seen this "limitation" mentioned in various online forums, such as the following.

 _" Mac OS X interface and ergonomy is (as said by apple) not 'compatible' with the focus-follow mouse mode. Why ? Because a single application interface is split into lots of different elements. For exemple, you use an application like photoshop or word, you'll have different panels floating around the main window. With sloppy focus mode enabled, with an application below, you would'nt be able to reach them. And how should they consider the desktop, which is, finally, just a 'root' window managed by the Finder..."_[1]

Here are some more.

 _" Sadly, it seems that for the time being there is no good way to do this in OS X."_[2]

 _" The fundamental problem with sloppy focus on the Mac is that the menu bar is always associated with the currently focused application; if you had sloppy focus, accessing the menu bar for a specific application would be supremely difficult."_[2]

[1] - [http://jeremy.zawodny.com/blog/archives/000149.html#comment-...](http://jeremy.zawodny.com/blog/archives/000149.html#comment-14550)

[2] - [http://superuser.com/questions/27306/focus-follows-mouse- or-...](http://superuser.com/questions/27306/focus-follows-mouse-or-sloppy- focus-on-mac-os-x)

<comment><USER15> ""The fundamental problem with sloppy focus on the Mac is that the menu bar is always associated with the currently focused application; if you had sloppy focus, accessing the menu bar for a specific application would be supremely difficult.""

Well that's the real trick. It _would_ be difficult to access the menu bar if you had a mess of weirdly placed and sized windows scattered around, like the OSX UI paradigm assumes you do.

But if you have a tiling window manager, and especially if some of those tiles are full height, it's quite easy. Just put your mouse in the window you need, and then go straight up to the menu bar.

Yes, once in a while you need to cross some extra real estate with the mouse in order to "dodge" a UI element you don't want to switch focus to, but it's really no problem.

I've been using tiling UI and focus-follows-mouse on snow leopard since 2009. I couldn't work any other way.

</comment></comment></comment></comment><comment><USER16> First off, thank you ianyh!! Tiling window managers are a huge productivity tool, and when I see people manually resizing windows, it's painful to watch. I'm on OSX now, but used XMonad extensively when I was on a *n?x distro.

At the moment, I'm using Spectacle for OSX. [http://spectacleapp.com/](http://spectacleapp.com/). Are there reasons I should use Amethyst instead? I'd love to see a feature matrix or something in you FAQ about the other options, and what Amethyst brings to the table.

<comment><USER5> A feature matrix isn't a bad idea (and I opened an issue to track [https://github.com/ianyh/Amethyst/issues/267](https://github.com/ianyh/Amethyst/issues/267)), but it's kind of hard to compare as they are such different pieces of software. Spectacle is manual window management and Amethyst is tiling window management.

Manual window management generally gives you better control and generally less overhead in terms of complexity. So it works well in the case of "I want to be able to move this window to the upper half of the screen", "I want to be able to make this window take up the entire screen", etc. You have to trade simplicity to get flexibility, though. What if I want to be able to move window to the upper right hand quarter of the screen? Or what if I want my screen divided into a grid of 3x4 and I want a window in the [0][1] position? You can accomplish all of those things, but you have to specify how to go about it, thus adding complexity. Slate, for example, puts that complexity upfront in writing a config file. Divvy, for example, puts that complexity at runtime.

Tiling window management gives you a more hands off approach. So things like "I want all of my windows to be laid out in this orientation, but I don't want to move them myself", "I want all of my windows to be visible at any given time", etc. You don't take actions to lay windows out, you just define algorithms for how they should be laid out and let the software sort them out. You have to trade simplicity to get control, though. Defining those algorithms can be complicated if you're not doing something really straightforward, and if you're not doing something straightforward it can sometimes be non-trivial to grok what's actually going on. Or you end up doing a lot of runtime massaging to get things working the way you want.

To each their own, though. I prefer tiling window management, I have coworkers who prefer manual window management. They're just different tools.

</comment></comment><comment><USER17> For Windows I just stumbled across MaxTo ([http://maxto.net/](http://maxto.net/)) I've been using it for a couple of days and I'm really impressed.

<comment><USER18> In a previous life I used [http://code.google.com/p/python-windows- tiler/](http://code.google.com/p/python-windows-tiler/) for Windows. It's not the most stable application though.

</comment></comment><comment><USER19> I've used BetterTouchTool's tiling functionality for the most part, but I just got a 4K monitor and most granular most tiling managers can do is quarters. I wish there was an out-of-the-box solution that allows me to just tile my space more granularly

</comment><comment><USER20> I use a window manager, but really only to have a hotkey that fullscreens a window (three, actually: one for current, one for left and one for right display). With 2 displays, I find that I have all I need with just an editor window and a documentation browser window. I guess I have smaller displays than most people because if I resize a window (browser windows mostly) beyond about 2/3 its layout gets messed up or a horizontal scrollbar appears.

</comment><comment><USER21> I really just want a window manager that allows windows to snap to each other and the edges of the screen when resizing or moving them. Does something like that exist? I don't care for the pre-defined layouts or hotkeys, I just want to be able to visually drag/resize my windows and have them take up the most optimal amount of space.

<comment><USER22> I personally use Cinch, which is good enough for me: Maximise if I drag a window to the top, left/right half if I drag a window to the side.

[http://www.irradiatedsoftware.com/cinch/](http://www.irradiatedsoftware.com/cinch/)

So far I've never seen a tool which glued one window to the other though.

<comment><USER21> Yeah, that's about as far as I've gotten as well. Snapping to other windows seems like the natural next step for me--it's weird that not a single app has taken that approach, though.

</comment></comment></comment><comment><USER23> I wish there was a window manager such as this but where you could put the application into full screen mode. So have two programs running in full screen mode side by side. Sublime and others (iterm) look so much less distracting without their window frames.

</comment><comment><USER24> Weird, I was literally just googling for this and found Amethyst. Seems nice.

I've noticed it gets a little slow to rearrange things sometimes with lots of windows but the functionality I need is all there.

Works great with my three screen setup too, which many tools like this don't.

</comment><comment><USER25> No one mentioned this one yet, it's not free but works pretty well with Windows 7-like snapping too: [http://www.nulana.com/flexiglass/](http://www.nulana.com/flexiglass/)

</comment><comment><USER26> What's the benefit of using this vs. WMs like SizeUp?

I'm asking this question because I'm quite comfortable with SizeUp and don't understand if learning how to use a WM is worth it.

<comment><USER24> Seems to me that there are 2 big benefits over sizeup (though i'm basing this entirely on their website, i've not used it)

1 - With sizeup you have to manually move your apps around. With this, new windows are automatically tiled (and you can then move things around afterwards with the keyboard shortcuts)

2 - This seems like it supports more complex layouts (with various layouts built in)

<comment><USER5> That is generally correct. I wrote a longer comment about this but SizeUp is about manually managing windows and Amethyst is about letting software manage windows for you. It's generally a matter of personal preference which you prefer.

<comment><USER26> In case anyone looking for the referenced comment: [https://news.ycombinator.com/item?id=8769044](https://news.ycombinator.com/item?id=8769044)

</comment></comment></comment></comment><comment><USER13> Does anyone know whether there's any chance i3 could be ported to OS X's native windowing system (whatever it's called) ?

<comment><USER27> You can probably run i3 in X11, although non-X11 apps won't work with it. Your best bet is to run i3 in a full-screen VM.

I researched this myself a few months back, since i3 was the biggest thing I missed when I had to switch to OS X (new company, new computer). Eventually I gave up and settled on Amethyst. It's not bad once you set up the keyboard shortcuts to your liking. The main things I miss are the tree structure for window organization, and window borders that stick together when resized.

I created some bounties on bountysource for features I'd like to see in this project. Hopefully other people want them enough to contribute as well, and ianyh will get a nice return on his contributions.

</comment></comment><comment><USER28> Seeing this (and others like it), what's the benefit of having a tiling-only WM over a floating WM with tiling capabilities?

<comment><USER5> Well, Amethyst can float windows so I wouldn't call it a tiling-only WM, but there's a lot of reasons I prefer it over floating window managers.

I'm really lazy and want software to deal with my windows for me. I used floating window managers for a long time and found that I spent a lot of my time arranging windows in the same patterns.

I also found that with floating window managers were just too limited for things I wanted to do on a daily basis. Two come to mind off hand. I want to be able to make a window temporarily bigger, but keeping the other windows on the screen and sized appropriately and I want to be able to easily switch which window is the "primary window." When I'm doing web development without external screens I find it very help to have an editor and a browser window open at the same time. One of them takes up about 80% of the screen and the other takes up about 20% of the screen, but I switch which is which pretty often. Make the editor take up most of the screen, make some changes loosely referencing things in the browser window, make the browser window take up most of the screen and see effects loosely referencing the code in the editor. And sometimes I've also got a Hulu or Netflix window open taking 20% of the width and 50% of the height. The complexity of making that work with a floating window manager is just too much compared to how easy it is for a tiling window manager.

I also just like being able to see everything on my screen at the same time.

</comment></comment><comment><USER29> Looks really weird with the window shadows though.

<comment><USER30> Yep, I like adding some space between windows.

I proposed something like that for spectale some weeks ago. Got refused. [https://github.com/eczarny/spectacle/issues/290](https://github.com/eczarny/spectacle/issues/290)

I mostly use apps in fullscreen and sometimes need to see 3 /3 apps at the same time, then switch to fullscreen, then back to tiled mode again...

Small aesthetic gaps around windows may not be such a waste of screen estate.

<comment><USER5> Window spacing is actually in the works for Amethyst. It just has some issues because some windows just don't size exactly. Terminal windows, for example, only size in increments of cursor size, so you're almost always a bit smaller or a bit larger than you want, which makes the spacing in between windows look weird.

<comment><USER30> I noticed that with or without my spectacle patch.

I tend to prefer uneven gaps than no gaps though, considering how unpleasant overlapping drop shadows looks like.

</comment></comment></comment></comment><comment><USER31> Use it also. Cool tiling manager.

</comment><comment><USER32> Use this every day. Works great.

</comment><comment><USER33> it's ok, I prefer to be able to set windows where I want them and assign keyboard shortcuts. I was the original author of Breeze, now autumn apps has it available - [http://autumnapps.com/breeze/index.html](http://autumnapps.com/breeze/index.html)

</comment><comment><USER34> Divvy is sufficient for me.</comment>


Show HN: Construct 3 – Make games in the browser - <AUTHOR> https://www.construct.net/gb?v=1 <comment><USER2> Ashley, Congratulations on such an ambitious release! I volunteer at a coding club for kids and Construct 3 seems like a perfect fit for the education market.

We primarily work with Scratch, but are always looking for a good "next step" for kids interested in publishing more ambitious games outside of the Scratch sandbox. We've tried a few downloadable engines or pure coding environments (e.g. Stencyl, Gamemaker, Phaser, Corona, Unity), but run into problems with the learning curve and installations.

Being web-based is a great advantage for Construct 3 in education. In our school district (NYC), students share laptops on carts and rely on Google Drive for storage. If you have additional information regarding your roll-out plans for the education market, please let me know. I could speak to some administrators at various schools and also teachers working with the csnyc.org initiative.

<comment><USER3> We're really excited for Construct 3 in education, we think we have a unique offering here. We plan to have it rolled out and available for purchase in 8 weeks ready to go.

Always happy to chat about this stuff, feel free to email me on email@example.com if you have any specific questions and if there's anything we can do to encourage administrators to give us a go.

<comment><USER2> Looking forward to it. Are you planning to release an Educator's Guide? Also, are the Construct 2 docs/tutorials relevant for Construct 3? I never used v2, so I'm unable to compare. Thanks.

<comment><USER3> We're obviously working on C3 guides, but there are a lot of similarities so the C2 resources should be useful until then.

</comment></comment></comment></comment><comment><USER4> We've been using Construct 2 for years at more than 200 events to get tens of thousands of students interested in coding at CodeDay. It's the only thing we teach in our beginner workshops now.

Our biggest problem has always been that it was Windows-only. I'm super excited to see that Construct 3 for the web has finally launched. (Finally, we can use Chromebooks!)

Congrats!

<comment><USER3> Hey Tyler! That's amazing to hear. One thing we are interested in experimenting with in the future for Construct 3 (not possible in C2) is "free weekends" like some games do, but even "free time-period for specific events". If we look to experiment in this area I'll be sure to reach out to you.

<comment><USER4> If it's similar to Construct 2, most of our students will probably fit in the free plan during the event, anyway :)

</comment></comment></comment><comment><USER5> I've been an avid Construct 2 user for a long time now and I am really impressed with Construct 3 thus far (in its limited form). The performance is fantastic, literally feels like a desktop application running in the browser. I couldn't see use of any framework or library, is this all custom? What platforms will Construct 3 support exporting to, plans for supporting the Nintendo Switch? Really nice work, this must have taken a long time to build.

<comment><USER3> > The performance is fantastic, literally feels like a desktop application > running in the browser.

We are so relieved to hear this, after 3 years work this was always front and centre of our goals.

> I couldn't see use of any framework or library, is this all custom?

Yes, all custom built

> What platforms will Construct 3 support exporting to

Exports HTML5 games, which can be wrapped in various ways to run on Win/Linux/Apple desktops, iOS, Android, Steam, FB etc etc. List goes on!

> plans for supporting the Nintendo Switch?

Would love to, but we know as much as anyone else about the Switch at this stage. If anyone from Nintendo reads this please reach out!

<comment><USER6> Try to get in touch with Damon Baker (@DWBakes). He deals with Indies but should also be able to refer you to the right people.

</comment></comment></comment><comment><USER7> This website really needs a screencast video. The all text features page has zero pictures. I have no idea how the product works besides the one screenshot on the homepage.

Look at this UX: [https://www.construct.net/ca/make- games/features](https://www.construct.net/ca/make-games/features) it's a long list of links, all text, and you have to click each one to see the block of text.

<comment><USER3> Yes, are aware! There is still a ton to do on the website, and we're actively working on it. This is a beta phase which should last ~8 weeks then everything will look a lot smarter :)

<comment><USER7> Ah, great, I shouldn't be so critical of a beta product.

Looking forward to a video of the new product. I watched one of the 2nd version and it looked interesting.

<comment><USER3> Criticism is good, keeps up on our toes :)

</comment></comment></comment></comment><comment><USER8> Charging per-year seems like a pretty risky move in the game-dev world. I understand WHY you'd want to, but think game-devs tend not to be big fans of this approach. Was it tough to decide to go with this model? How has the feedback been from Construct 2 users?

<comment><USER7> Where do you see the pricing?

[https://www.construct.net/ca/make-games/buy- construct-3](https://www.construct.net/ca/make-games/buy-construct-3)

It's telling me it's in beta.

<comment><USER3> Pricing is over here: [https://www.scirra.com/forum/construct-3-pricing_t187766](https://www.scirra.com/forum/construct-3-pricing_t187766)

Won't be available to buy until beta is over.

</comment></comment></comment><comment><USER9> Been a longtime follower and user of Construct (all the way back from early Construct 1 days) and the work that's been done in both Construct 2 and Construct 3 has been extremely impressive - I was initially skeptical about C2's move to HTML5, but over time it made a very convincing case for the fact that web can indeed be performant. I think moving the whole IDE to web was the logical way forward for Construct itself, and I'm glad to see it's working out with C3.

However, as things are right now, it seems that the time has come for me to part with Construct. I do web development for a living, and game development is something I do for fun on the side mostly for my own enjoyment these days. The limitations of the C2 Free Edition were too much for me (as a programmer even my tinkering tends to be event-heavy, and even my smallest toy projects tend to start with creation of more layers than what's available in the free version), but this wasn't really an issue since the Personal License was simply a one-time investment, and I've been very happy with my purchase.

However, with the move to a subscription-based payment model, this changes completely. I can't justify paying $99 a year for how much I use the program. The Free Edition is also not an option because it seems to be even more restrictive than the C2 one. This is extremely unfortunate from a personal standpoint, and I'm clearly not alone with this opinion, seeing how much negative feedback the move to subscription model has garnered on the Construct forums.

But there is also the business standpoint to consider. The one-time payment was a huge pro for C2 and more than made up for the restrictions of the free edition in my books. But now with the move to a subscription model you're competing more directly with the likes of Unity that also uses a subscription model. And if you look at what Unity offers in the free tier[1] and compare it to Construct[2], the latter looks like a complete joke in comparison. With Unity, you get a full-featured engine with all the export options that you can make money with (with a revenue cap after which you need to upgrade, similar to C2 Personal -> Business), with the most notable "downside" basically being a "Made with Unity" splash screen. Something like this is what I would expect to see with the C3 Free Edition as well in order for it to be truly competitive. After all, game IDEs don't exist in a vacuum.

[1] [https://store.unity.com/](https://store.unity.com/)

[2] [https://www.scirra.com/store/construct-2](https://www.scirra.com/store/construct-2)

<comment><USER3> We don't think we directly compete with Unity. If you imagine all engines in a pyramid, Unity is at the top and we're somewhere in the middle. Construct users often graduate to Unity, but conversely people who try Unity and find it too overwhelming come to us.

I think in comparison to our direct competitors in our space, our pricing is still competitive.

<comment><USER9> >We don't think we directly compete with Unity.

Well, you should, because both C3 and Unity using a subscription model vs the one-time payments of many other options makes it the most direct comparison. Both concretely and psychologically a subscription model requires a much more serious commitment to the product compared to a one-time payment.

And beyond the payment model, I've long thought that Construct offers a serious alternative to Unity for serious development purposes if you're making 2D games, and in fact I'd say in many ways Construct has the edge over Unity in this space since it's built for 2D development from ground-up whereas Unity is a 3D engine first, which makes 2D development in it more cumbersome. This is why I was happy to see you mention in another comment that you intend to shift the marketing of C3 to a more "serious" direction, where C2 often gave the impression of a "toy". But that's just another reason why you should consider yourself as a serious alternative to Unity yourself.

I assume that the "direct competitors" you're talking of are along the lines of Clickteam Fusion and Game Maker. It's certainly true that these are both 2D-focused game IDEs, but both are sold as one-time payments, much like C2. As someone who moved from Multimedia Fusion 2 to Construct 1 back in the day, I personally think C2 has already been the king of this space for years, wiping the floor with the competition when it comes to both usability and performance as well as scaling to big projects. This is why I'm not at all fundamentally opposed to "going bigger" with a subscription model to compete against other subscription model game IDEs, because I believe C3 is very much capable of competing in this space, all the while having a lower barrier to entry. But again, to be competitive here, things should really change with the way the free edition is handled.

Ultimately right now Construct 3 falls into a very uncomfortable position where I would never want to downgrade to the likes of Clickteam Fusion (neither the current 2.5 nor the upcoming 3) or Game Maker Studio 2 (because they are both less powerful/performant as well as less usable on the whole and scale big way worse), but I honestly wouldn't want to use Unity either because while power-wise it's definitely capable I'd still be somewhat of a downgrade in terms of usability for 2D development (I have actually used Unity for a couple projects in the past, but I've stuck around with Construct 2 for this exact reason). As a professional programmer there isn't really any insurmountable obstacles to using any of these programs for me, so it's all about the convenience for me, and 2D development with Construct is where I believe the sweet spot lies in this regard. But as it is, C3 free edition is just too restricted power-wise and the subscription is too big of an investment. Because of this I also see myself having a hard time recommending C3 to other people in the future, where recommending C2 used to be a no- brainer.

<comment><USER3> > Well, you should, because both C3 and Unity using a subscription model

Similar payment models doesn't mean you're competing. Granted there will be some overlap, but generally we feel our customer bases are fairly well defined and separate.

> I assume that the "direct competitors" you're talking of are along the lines > of Clickteam Fusion and Game Maker. It's certainly true that these are both > 2D-focused game IDEs, but both are sold as one-time payments, much like C2. > As someone who moved from Multimedia Fusion 2 to Construct 1 back in the > day, I personally think C2 has already been the king of this space for > years, wiping the floor with the competition when it comes to both usability > and performance as well as scaling to big projects.

Thank you for the kind comments, and I'm glad you consider Construct to be wiping the floor! Shows we're doing something right ;)

We did not observe as many free edition conversions to paid as we would of hoped with C2. For this reason, we're experimenting with locking it down more than C2. We will see how this goes. Our philosophy has always been "give more" not "take away", so we're starting conservatively.

And, as you put it, we are wiping the floor with the competition so we feel reasonably comfortable at this stage experimenting with a different pricing model.

Worth mentioning is that we're planning on selling C3 for ~$99 USD per year, if you want all the Gamemaker export options you'll spend > $1,000. I feel in comparison to that, our pricing is still competitive.

<comment><USER9> >Similar payment models doesn't mean you're competing.

It inevitably invites comparison though.

>We did not observe as many free edition conversions to paid as we would of hoped with C2.

I can understand that, and I wouldn't mind it at all if C3 was also a one-time purchase like C2 (if that was still the case I'd be buying C3 in a heartbeat), but I definitely think it's the wrong way forward with the change in the payment model. I have a bunch of small C2 projects from over the years I've used the program, and I can go back and edit them with C2 even today. However, if I got a C3 subscription for a year and upgraded my projects to C3, then a year later when my subscription ran out my projects would suddenly become essentially read-only due to the free edition limitations, and this whole thing of effectively locking me off from my own projects just completely kills my interest in the current free/paid model of C3. (I'm not actually sure how Unity handles this same scenario, but seeing how the free version still offers the fully-featured engine and how the tiers differ, I'd expect the story to be much better there.)

>Worth mentioning is that we're planning on selling C3 for ~$99 USD per year, if you want all the Gamemaker export options you'll spend > $1,000. I feel in comparison to that, our pricing is still competitive.

While that's true for Game Maker Studio 2, you also have to consider that both Clickteam Fusion and Game Maker Studio 1 have shown up in several Humble Bundles for practically pennies at this point. I actually own both CF2.5 and GM:S along with the most important exporters available for them (Desktop/iOS/Android/HTML5) and I only paid $15 for each (and I bought both because I wanted to see how they stack up against C2 today, which cost more than both combined). From usability and performance standpoints I don't see GMS2 being that big of an upgrade, so sticking with GMS1 would certainly be a viable option for anyone interested in it as an alternative.

>And, as you put it, we are wiping the floor with the competition so we feel reasonably comfortable at this stage experimenting with a different pricing model.

Well, sadly as much as I like Construct as a 2D game IDE, it pretty much kills the program for me and also makes it way harder to recommend to other people as well, which is something I've done a lot with C2 over the years (I got a lot of people at my uni to use it and know several people who ended up buying personal licenses as well).

Personally I think you could expand the free version and make the paid version more expensive. If I ever get around to doing commercial products with Construct, I certainly wouldn't mind paying more than $99 a year for a paid version, even if it was just to get rid of splash screens. You could also take cues from how Unity differentiates the tiers in other regards, like with the cloud build queue priorities and multiplayer support etc (if you're using Scirra-provided infrastructure).

</comment></comment></comment></comment></comment><comment><USER10> I've been following Construct since the early days and it's amazing what a great following it has mustered. I keep seeing cool games made with Construct being posted in various indie game groups on Facebook. I initially disregarded it as a toy project you couldn't use to build real games but I was proven wrong.

<comment><USER3> Thanks for the comment! We're adjusting our language around promoting Construct 3 compared to Construct 2, we think we undersold it previously and it's been stuck with the "toy" feel. We're hoping to shed that moving forwards.

</comment></comment><comment><USER11> It's like Scratch on steroids. I'm making games together with my son in Scratch. Will give this a try when he's ready to try something more complex. Btw. the performance of the app is great for a web-app. What were your main challenges to get this performance?

<comment><USER3> Thanks, and I'm happy you'll consider it to use with your son. Performance wise, I'll let Ash talk more about that as he's the one who's been obsessively making sure it loads and runs as good as possible.

<comment><AUTHOR> Layout performance is the biggest problem probably - when things change the browser too often does a full layout of the document. We use tons of CSS containment but there are still bugs where Chrome does far more layout than necessary, e.g.: [https://bugs.chromium.org/p/chromium/issues/detail?id=667370](https://bugs.chromium.org/p/chromium/issues/detail?id=667370)

Virtual DOM is completely unnecessary to us. We have minimal problems with DOM calls. It is all to do with layout performance, and VDOM makes no difference at all there.

</comment></comment></comment><comment><USER12> When browser vendors killed Flash, it was like someone killed YouTube and forced all amateur video creators to deal with portability themselves. It "professionalized" the field and drove away untold numbers of people who just wanted to show their interactive doodles to the world, not run the JS fashion treadmill for the rest of their lives. And programmers congratulate themselves on that!

        It looks like your browser will not be able to run Construct 3.

The world craves a Flash replacement suitable for amateur creators, but it will need to take portability more seriously than every JS framework in existence.

<comment><USER13> Hitting the same message, as my Chrome is 1 version behind.

Most people will not be willing to change their browsing habits to use your web application. The onus is on us, as software developers, to ensure our code runs in the user's browser, not the other way around.

Ultimately it's up to you to decide where the line is drawn; nobody supports IE7 anymore because it's hardly used. But I suspect you'll lose a tremendous amount of potential users by not supporting Firefox, Safari or recent Chrome.

I'm sure you guys are aware of preprocessors; is there a reason you haven't used them to implement things like HTML imports or CSS variables?

<comment><USER14> > The onus is on us, as software developers, to ensure our code runs in the > user's browser, not the other way around.

I assume the exported games are portable and can run in older browsers. So the users shouldn't have to worry.

</comment></comment></comment><comment><AUTHOR> Sorry folks, we only launched yesterday, if you happen to see a 404 message please just visit: [https://www.construct.net](https://www.construct.net)

</comment><comment><USER15> > Currently the latest version of Chrome is the only browser that supports the > advanced and exciting features we've built into Construct 3. We hope to add > support for other browsers once they catch up with us!

What features are currently missing from Firefox to be allowed to use Construct 3? Seeing more and more errors like this lately, and most of the times the features the developers don't think Firefox supports, actually exists.

Edit: Running Firefox 52, I get a list of features that are not supported yet that is needed, so seems legit.

If you want to try Construct 3 anyways on Firefox, you can enable dom.webcomponents.enabled and dom.dialog_element.enabled while running Firefox 53 in about:config, and everything should work fine. Firefox 53 is supposed to be released 2017-04-18.

Thanks to the team behind Construct to actually use feature detection instead of user agent sniffing to block browsers.

<comment><USER3> We are obviously extremely incentivised to support as many browsers as we can right now, but Chrome is the only one that can run it (nearly) out the box.

Firefox is close, but is missing HTML imports and Dialog element. If you open: [https://editor.construct.net/](https://editor.construct.net/)

It will list the missing features.

<comment><USER16> I wasn't familiar with HTML imports, and after searching around it looks like Firefox will never support ([https://hacks.mozilla.org/2014/12/mozilla-and- web-components...](https://hacks.mozilla.org/2014/12/mozilla-and-web- components/)). Any plans for polyfills, etc.?

<comment><AUTHOR> We can potentially polyfill them - we're waiting for dialog element support first, that's still holding back support in most other browsers. HTML imports are outrageously under-valued as a technology for building this kind of web app. We're hoping to do some blog posts highlighting how awesome they are and try to turn around opinion on that.

<comment><USER17> Can't you just... program that stuff yourself? By relying on such "cutting- edge" features, you get all the drawbacks of web technology with none of the reach.

<comment><AUTHOR> No, HTML imports are the kind of technology that are the perfect architecture for this kind of web app and arguably are what make it possible. It'd take a whole blog post to explain, hopefully I can write it up soon!

<comment><USER17> There are web applications that are way more demanding than this, that have run on more platforms for a while and that _don 't_ need any of these questionable experimental features.

I could understand if you said you need WebGL or WebAudio or some other hardware/OS interface. You _don 't_ need HTML imports.

<comment><AUTHOR> Perhaps I should have added another qualifier: for a team of three developers. (One initially.)

<comment><USER17> ...even for a team of _one_ developer!

Look, I understand how one might _like_ HTML imports. Once you've gone down the rabbit hole of Web technology, all the fancy experimental features make it look like HTML/CSS are now adequate. They're not. It's a trap.

The real answer is writing Javascript (or something that compiles to Javascript). Always has been, always will be. Don't trust the web consortium to specify things that _maybe_ browser vendors will implement. Do it yourself now, thank yourself later.

<comment><AUTHOR> We took the same bet with CSS grid, and it paid off. Lots of features can make a massive improvement to the development experience. We used a wide range of experimental features starting around 2014. Most of them came to fruition. HTML imports has been the only tricky one so far, which I think is a pretty great result on all the bets we took.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Having tried lots of game-making-apps and frameworks, I always keep coming back to Construct2, now 3. Also as web-dev I'm impressed by the good performance and usability. (If you find the time, maybe do a blog-post about the challenges you faced and clever solutions you came up with :-P)

I'm not a fan of apps in browsers, but on a Mac it beats having to start VMWare and Windows by far!

For me, the hugest win over 2 is the ability to run it on the mobile device in parallel and have almost instant testing. Maybe you could add a feature like generating a preview-url at some point?

On my Android it didn't work with the latest updated Chrome, but it works fine with Chrome Canary or Beta, which can be downloaded from the Play-Store.

Also great to be able to pay monthly, even if it's a bit more.

So, 1000x thanks for making Construct!

</comment><comment><USER19> The link is a 404 Error.

For what it's worth though. I went to the homepage and it does seem like a really nice product that a lot of effort was put into. When I saw game maker I didn't expect to be as impressed but it seems far better than the other web based game makers I've seen.

Although it requires the absolute latest Chrome (I was half a version back) which is interesting. I wonder what is in Chrome 57 that is required and not in Chrome 56.

<comment><AUTHOR> CSS grid was the main reason: it's new in Chrome 57 and we use it heavily!

Sorry about the 404, shouldn't happen to everyone but we're working on it...

<comment><USER19> Do the games made with it need Chrome 57 or just the builder?

<comment><USER3> Just the Construct 3 editor itself. The games can run as far back as IE9 (but without WebGL). All modern browsers out the box will be able to run Construct made games.

</comment></comment></comment></comment><comment><USER20> I've only tried Construct 2 for a short time, but the output for the HTML target was running amazingly smooth, and the tooling was very, very nice.

<comment><USER3> Thank you really appreciate the compliment. We hope we've managed to bring what we've learnt from outputting HTML5 games into the editor itself.

</comment></comment><comment><USER21> Congratulations!

Even if I prefer native to web, I have to concede you guys did a wonderful piece of work and I had quite some fun playing around with it.

Good luck with the project.

<comment><USER3> Thanks for the message, glad you had fun playing round with it and appreciated the amount of work that went into it!

</comment></comment><comment><USER17> Does anybody ever actually want to do serious work "in the browser"?

I can think of many drawbacks. Where's the benefit?

<comment><USER3> One code base to maintain which will (theoretically with the right browser) run on Mac's, Linux, Android, Windows etc. At the moment Construct 2 is bound to Windows only.

Secondly, a huge feature that we're yet to show is multi language ability. This is an insanely difficult thing to implement in a C++ program, but reasonably trivial in HTML.

In the browser lets us reach everyone in the world, whilst only maintaining one code base and let's us develop and iterate faster than ever before.

<comment><USER17> Like you said, this is all theoretical. You can reach "the whole world" with the right browser. At that point, you might as well ship an Electron app.

But that's not even the point of my question. What I actually meant is: Where is the benefit for _the user_? I wouldn't want to use applications in-browser, unless there's some real value in that. For everything else, I strongly prefer a "native" application.

<comment><USER3> What other game dev tools can a user on a Chromebook use? Or an Android device?

Another thing, it enables us to rapidly iterate and deploy through one code base. Maintaining code bases for multiple platforms will be like a ball and chain on our feet. End user will get a better product.

<comment><USER22> End users don't get a better product just because you don't want a ball and chain on your feet.

Apps wrapped in a browser are blatantly clunky and feel out of place from the OS compared to something using native controls, not to mention consuming more resources and battery. [0]

[0] [https://news.ycombinator.com/item?id=13940014](https://news.ycombinator.com/item?id=13940014)

<comment><USER3> Have you tried Construct 3? The feedback we're getting (some in this thread) is that it's very responsive. We're getting feedback on social media that people are forgetting sometimes they are using it in a browser. Making it feel as performant as possible has always been the #1 goal. Browser apps have a bad rep because there are a lot of badly written ones out there.

What specific parts of Construct 3 do you feel are clunky?

<comment><USER22> Sorry, I cannot yet give feedback on Construct 3's quality as a game development tool (though it looks promising in that regard) but being a web app, after just a few minutes with it I am faced by too many inconsistencies and annoyances that just. would. not. happen. in a native app.

Menus, panels, windows, controls, fonts, fullscreen support, accessibility..too many to list, and WHY do I get the ugly red X button on the right corner when I'm on a Mac?? Why do you force me to use Windows UI paradigms, after making such a big deal about web apps = yay portability?

The reality remains that for now and the foreseeable future: Users do NOT, CAN not, get the best possible experience unless you're willing to write and maintain native apps.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Since you are moving to a subscription model, I'm curious as to how updates and support will change. I usually equate subscriptions with better support and/or more frequent updates. What differences can users expect on this front in comparison to C2?

</comment><comment><USER24> Funnily enough, I just came across this site, this morning [http://agentsheets.com/](http://agentsheets.com/) , an academic effort to make games in the browser.

EDIT: don't leave a comma right after the URL, add a space :-)

<comment><USER25> Link does not load

<comment><USER24> It should now, thanks!

</comment></comment></comment><comment><USER26> Congratulations on what looks like a very impressive piece of software. Do you guys have any plans to add collaborative features to Construct? Where, say, students in a remote classroom could work on the same game together?

</comment><comment><USER27> Has anyone tried using Electron to make a desktop version of their game? I think this is a great way to make games: release them on the web to see what kind of traction you get and than release a desktop version with Electron!

<comment><USER28> I'm considering this path. I'm currently making games for game jams with Phaser, so I imagine porting to Electron wouldn't be too difficult. I'm not sure what the best path for getting JavaScript games into mobile app stores would be though.

</comment></comment><comment><USER14> How does it compare with Game Maker?

</comment><comment><USER29> Will there also be an offline/desktop version of Construct 3?

<comment><USER3> Yes, there will be. Coming soon! Also, as it is, Construct 3 will run offline. Try bookmarking it, pulling your internet cable out then visiting it :)

</comment></comment><comment><USER30> Very interesting. Any information about upcoming pricing?

<comment><USER3> Full current details here: [https://www.scirra.com/forum/construct-3-pricing_t187766](https://www.scirra.com/forum/construct-3-pricing_t187766)

For most users, it will be $99 USD p/y. Businesses/educational institutes will have different pricing.

</comment></comment><comment><USER31> I get a 404 on this.

<comment><USER3> Fixing this now! Sorry!

Edit: Now fixed</comment></comment>


A step-by-step guide to building a simple chess AI (2017) - <AUTHOR> https://medium.freecodecamp.org/simple-chess-ai-step-by-step-1d55a9266977 <comment><USER2> The wikispaces were dropped a while back; the new chess programming wiki is at chessprogramming.org

The biggest gains (from my experience as a developer of WyldChess) are from improving move ordering, heuristic search pruning and position evaluation parameters.

Move generation speedups are relatively low yield because most of the time is spent in evaluation.

</comment><comment><USER3> If you want to build something like a chess AI, but you want to produce something that beats the current state of the art, we could always do with new computer engines for Isopath[0] :)

[0] [https://isopath.jes.xxx/](https://isopath.jes.xxx/)

</comment><comment><USER4> This is a really cool and well written post. Thank you!</comment>


Shotspotter CEO Answers Questions on Gunshot Detectors in Cities - <AUTHOR> https://www.aclu.org/blog/free-future/shotspotter-ceo-answers-questions-gunshot-detectors-cities <comment><USER2> The privacy concerns with systems like these is not what they currently do, but what they are capable of.

It doesn't matter what your privacy policy says, and it doesn't matter if the default configuration is to only download the audio near the time of a possible gunshot.

The important part is that these devices can stream audio to remote servers. The NSA or anybody who finds or can coerce accesses to the system could use them to eavesdrop on everything within range.

No amount of "privacy policy" is going to prevent it.

<comment><USER3> That's assuming that audio from these sensors is at all useful for eavesdropping on people. Try a speakerphone lately? Even with higher quality codecs than we got in the POTS days and things like beamforming, the result is pretty terrible in decent sized conference rooms. Now try this outdoors, further away from people, with the noise floor of a city instead of a quiet room.

The cases people point to where ShotSpotter has picked up understandable words have been people very close to sensors who were shouting immediately before, during, or after gunfire the system picked up. But at that point, it's unreasonable to claim some sort of violation of privacy when people are screaming for all to hear.

</comment></comment><comment><USER4> Redwood City, CA had the first system. It was much simpler than this. They had analog microphones on phone poles, connected to a logarithmic amplifier which traded dynamic range for bandwidth. Phone audio is 8 bits at 8KHz; think of this as remapping to 16 bits at 4Khz, although it was done with analog hardware. They needed the dynamic range to see the full risetime of a gunshot, and gave up a big chunk of the voice spectrum to get it.

Each microphone had a wired phone line connection to the central system at the police station, which was a PC with a data collection card running LabView. A LabView program turned gunshot information into map plots. It was a simple, local system.

The new systems are much fancier. They're "cloud-based", which means the data goes first to ShotSpotter's HQ. They have synchronized clocks (probably from GPS), so they can send in timed audio snippets to be matched at the analysis center. It's a service now, rather than just hardware. Not clear what kind of data connection they have; probably cellular data.

</comment><comment><USER5> Wait - what? There are so many guns fired in US cities that a company can build a sustainable business creating a system that spots these gunshots?

<comment><USER6> I've lived in Sacramento, Portland, and now San Francisco and I have yet to hear a gunshot in any of these cities.

<comment><USER5> Right? I thought that was just something from TV/Movies - this looks more like they are selling fear than something real.

Why would a city invest in something like this? Especially if you get the information via emergency calls?

<comment><USER7> I happened to start working with a similar system today. For our customer there are several factors they are interested in:

# Mapping gunshots in both time and space. These types of sensors can attempt to classify the type of weapon used based on the audio signature. If there are are several shots from similar-sounding sources moving through the city at a certain, or in a certain area over the period of days (or month), this can tell you more than you could determine from just emergency calls.

# Tieing the gunshot sensors in with other input devices, like cameras. You can reduce the time spent looking through, say, traffic camera recordings that happened in the vicinity of the gunshot looking for related video.

# Automatically pointing moveable cameras to look in the direction of a gunshot. Means you don't need as many camera for the same effective coverage.

</comment></comment></comment></comment><comment><USER8> Does this technology have a slippery slope? Assuming that the technology isn't useful for recording conversations, what's the worst that could happen by implementing this in residential neighborhoods?

<comment><USER5> As far as I see it you waste money that could be better used in staffing police, implementing social programs etc - this thing is a solution to a very tiny problem: gunshots that are not reported via emergency calls. As far as I can see this does not help with robberies, burglaries, attacks with fists/knives/bats etc.

Even if its not a slippery slope - I'd imagine there are several better alternatives where you can spend the money.

<comment><USER9> > this thing is a solution to a very tiny problem: gunshots that are not > reported via emergency calls

I wondered how big a problem this is, but the only number I quickly could find is annoyingly from their advertising material and claims that in some areas only 10 % of shots were reported, which is not really the relevant number. Does anyone have a number on how many people die of gunshot injuries that either weren't reported or reported to late?

<comment><USER10> That's also not the relevant number. In places like Chicago, what you end up with is a tiny proportion of the population (say 2000) that is perhaps 100 times more likely to be murdered and is a major drain on your city's image. This is fuelled by revenge killings; someone gets shot or shot at, their family/friends round up the posse.

So what you want to do is get people off the street before they start shooting, or if that fails, you get them off the street as soon as they start shooting in order to break the cycle.

At the moment, with the dispatching of officers etc, you find that it takes about 2 minutes from receiving a call to an officer being dispatched (that's from the London Ambulance Service). A lot of this is just the time between the call arriving and the operator working out where the person is. Before the call, there are perhaps 15 seconds where the bystander who calls up is getting their phone out and dialing.

In this case, with the new system you can in principle have two squad cars each half a mile away knowing where the gunshot is to a reasonable level of accuracy, perhaps within a couple of seconds of the shot itself.

Within a minute of the first shot, the police can be on the scene. In this case, the suspects have only just jumped into their cars, and so are picked up easily.

There's no opportunity for any kind of revenge, because the suspects are in a cell.

Of course it's not a fantastic idea for every city; but if you're a company that focuses on military hardware, filtering off into LA, Chicago and NY can easily be an advantage for all.

</comment></comment></comment></comment><comment><USER11> But why? Why do you want to know when a gunshot happens? By the time you've heard it, it's already too late.

"You were so focused on whether you could do it, you never stopped to ask whether you should." - Jurassic Park

</comment><comment><USER12> Is it possible to create a (cheap) non-firearm device that mimics gunshots closely enough to fool the system?

Would be fun to put dozens up all around, on slow timers.

<comment><USER13> Depends on the sophistication of the system, and how many microphones it has. The vast majority, if not pretty much all of this class of gunshots, are going to start with the bullet being supersonic, the shock wave of which contributes to the signature (in the case of sniper fire I mentioned elsewhere in this discussion, it will tend to fool people into thinking the source is as much as 90 degrees from where the rifle actually is).

I'm having difficultly coming up with anything that isn't essentially a blank firing gun, and I'll note those are deadly really close up.

<comment><USER12> So, a firecracker won't do the trick? I realize that's still explosive, but unless you're stuffing them up a nostril first they're pretty safe.

<comment><USER13> To my thoroughly trained ears they sound very different.

Thinking about it, to avoid false positives, companies doing this need to filter out fireworks, the proverbial car backfire (do they do that any more???), etc.

</comment></comment></comment></comment><comment><USER14> I'm not an expert, or even a layman in audio encoding, but it seems to me that a solution could be found that couples an open source capture program with their backend. The open source (audited and only updated from the open source branch) capture program filters the audio stream down to something that only contains a gunshot signature, and nothing else. If the motivation is there a solution is certainly possible.

<comment><USER15> It could be done, similar to this lightning detection project:

[http://www.lightningmaps.org/realtime](http://www.lightningmaps.org/realtime)

[http://www.blitzortung.org/Webpages/index.php?lang=en&page=3](http://www.blitzortung.org/Webpages/index.php?lang=en&page=3)

TL;DR They do triangulated time of flight for EM emissions from lightning strikes.

<comment><USER10> Thing is, with lightning it is _dead_ easy because you're talking about what is essentially a straight line through the atmosphere.

In a city, you get more issues: double datapoints from the gun and the bullet, multipath effects, etc etc etc.</comment></comment></comment>


Tracking is the opposite of freedom - <AUTHOR> http://ivanca.tumblr.com/post/172752515693/tracking-is-the-opposite-of-freedom <comment><USER2> _next they will want to track who you meet with, how much time you spend with them_

Who you meet with, and to some extent how long you spend with them, can be derived from analysing the tracking data of individuals e.g. knowing that three separate people are in the same coffeeshop together on several separate occasions at different times leads to the conclusion that they're likely to know each other.

This is the pernicious thing about tracking people; data about individuals builds to become information about groups.

<comment><USER3> >" knowing that three separate people are in the same coffeeshop together on several separate occasions at different times leads to the conclusion that they're likely to know each other."

Does it? Three people who visit the same coffeeshop at the same time in the morning also leads to the conclusion that they all live on the same block and work 9 to 5 jobs.

<comment><USER4> So you're saying the inferred information doesn't exist because of some false positives? I'd say false positives can be more dangerous because humans will have propensity to trust the algorithm and interpret it as truth

<comment><USER3> >"So you're saying the inferred information doesn't exist because of some false positives?"

No, exactly nowhere in my comment did I say "inferred information doesn't exist." Nor did I imply that.

</comment></comment></comment></comment><comment><USER5> [https://cosmobird.github.io/content/category/activism/2-atta...](https://cosmobird.github.io/content/category/activism/2-attacks/unique- id.html)

<comment><USER6> The irony that your link requires javascript to show ... anything.

<comment><USER7> How is that ironic? You can build a tracking system using many programming languages.

</comment></comment></comment><comment><USER8> >Recently India has started tracking its citizens with their fingerprints, every thing they buy, every place they visit, every money transaction, everything.

Can't you just use cash? I assume my credit card company, my bank, their partners, and the government know where I am if I use the card. Isn't that the logic thing to think?

<comment><USER9> The US is very cash centric, but a lot of countries are slowly migrating away from it. Many stores don't accept cash and it is mostly the older generation that continue to use it.

If we want cash to remain stores must be forced (by law) to accept it, and this must be done soon. Even if we go that route you will quickly become that weirdo that payed in cash if you actually makes use of it.

<comment><USER10> >...it is mostly the older generation that continue to use it.

People always forget the homeless.

<comment><USER11> In developing countries even people with homes often don't have addresses. But they can have a bank account on their mobile phone, like M-PESA.</comment></comment></comment></comment>


HuddleChat: Did Google Just Rip Off 37Signals? - <AUTHOR> http://www.readwriteweb.com/archives/huddlechat_campfire_rip.php <comment><USER2> "We're flattered Google thinks Campfire is a great product, we're just disappointed that they stooped so low to basically copy it feature for feature, layout for layout," said 37Signals founder Jason Fried by email. "We thought that would be beneath Google, but maybe its time to reevaluate what they stand for."

How cute. 37Signals thinks they invented the basic chat interface.

<comment><USER3> Also: if they're willing to backchannel this to reporters, they should have the stones to say it on their (hugely popular) blog.

</comment></comment><comment><USER3> No.

When you publish and promote an application, it is fair game. That Campfire (which we use and pay for) is so easily reproduced as a side project is a problem 37Signals has, not a problem for other teams.

I played with HuddleChat and the interface similarities are apparent; however, HuddleChat is not a class-for-class, id-for-id knockoff of Campfire.

Add to that the fact that most of the design of Campfire is obvious; the only distinctly 37Signals-ish aspect of it is minimalism. If you (fairly) started a project with the goal of being "at least as functional as Campfire", it's easy to see why you'd end up with something that looked similar.

</comment><comment><USER4> I don't get the complaining. It's a sample to show the power of AE. It's not as if Google has released HuddleChat on the level of Gmail or Google Maps. Speaking of which, does anyone know if Yahoo or MS complained about design copying when Gmail was released?

From the comments:

""" As one of the App Engine product managers, I wanted to give an update -- we've now taken HuddleChat down from the App Engine app gallery. The App Engine team was looking for some sample apps to help kick the tires on their new system, so we invited Googlers to build some as side projects. A couple of our colleagues here built HuddleChat in their spare time because they wanted to share work within their team more easily and thought persistent web chat would do the trick. We've heard some complaints from the developer community, though, so rather than divert attention from Google App Engine itself, we thought it better to just take HuddleChat down.

Thanks, Pete Koomen Product Manager, Google App Engine Team """

</comment><comment><USER5> yeah this is bollocks. Did 37 signals rip off IRC?

</comment><comment><USER6> _Did Google rip Campfire off? Absolutely._

OK, let's be sure we're all talking about the same thing. When I hear that company Foo ripped off product Bar, I think that Foo has made an unethical clone of Bar's design or Bar's actual copy/code/content. By this definition, releasing a piece of software with Bar's exact feature set does not constitute a "rip-off," but merely competition.

This doesn't look like a rip-off to me after an admittedly brief look at the interface. I'd believe it if someone, without looking silly, could actually enumerate a list of Campfire design elements Google "ripped off." To me, Campfire's interface looks minimalist and elegant; HuddleChat looks rather like a wireframe. It seems silly to say that the two apps have the same look and feel.

</comment><comment><USER7> No, it's just a standard chat layout.

</comment><comment><USER8> [http://www.amazon.com/Competitive-Advantage-Creating- Sustain...](http://www.amazon.com/Competitive-Advantage-Creating-Sustaining- Performance/dp/0684841460)

Should I send a copy of this to 37 signals? I thought this was business 101. If you don't have a sustainable competitive advantage you will undoubtedly suffer. 37 signals doesn't have said advantage.

</comment><comment><USER9> Even if they did copy Campfire, I don't really see the problem. It just goes to show, that if your software is really easy to make, you will probably see some competition. In my own startup, the business idea is to make localized clones of cool web apps.

</comment><comment><USER10> Yes or no, it was both a stupid move and in poor taste. Google App Engine requires developers to put a fundamental trust in Google (in a away AWS does not).

It was incredibly stupid of them not so much because they did/did not steal the idea/layout so much as it is about the appearance of stealing it. "Caesar's wife must be above reproach." Intended or not (and I'm sure it wasn't), it sends an implicit signal that Google thinks this platform is best used to make knock-offs of existing products.

With a company full of bright engineers (so many, it seems they hardly know what to do with themselves sometimes), they ought to have been able to come up with a slightly more original idea to showcase app engine.

Of course, in all likelihood, this product came from the ground up, not from the top down, and for some reason, no manager at Google thought it was going to be a problem.

<comment><USER11> "In all likelihood, this product came from the ground up, not from the top down, and for some reason, no manager at Google thought it was going to be a problem."

Never ascribe to malice, that which can be explained by incompetence.

<comment><USER12> _"Never ascribe to malice, that which can be explained by incompetence."_

Or in this case _competence_. It was trivial for a few Googlers to functionally clone your super-duper web-app in their _spare time_ with Google's new _publicly available_ tools?! Doh!

<comment><USER13> Henry Ford comes to mind.

</comment></comment></comment></comment><comment><USER14> Im sorry but if anything 37s ripped off IRC

</comment><comment><USER15> No.

</comment><comment><USER16> Maybe 37 Signals should have gotten RMS and the FSF to patent their software.

</comment><comment><USER11> Did Google rip Campfire off? Absolutely.

Is Campfire "obvious"? Design always seems obvious in retrospect. That's the point of design, it isn't a whiz-bang new feature, it's a way to arrange existing things in an effective way. Good design is the art of doing things that--in retrospect--seem obvious.

In any event, i find it interesting that Google now appear indistinguishable from Microsoft. Copying somebody else's app and giving your copy away so you can drive traffic to your platform has been done before.

<comment><USER3> This isn't a Google application. It's a side project --- and, design aside, a totally obvious side project --- of a couple Google developers. Do you really want to single them out for attacking 37Signals?

As for the non-obviousness of Campfire's design, defend the argument. When Campfire was launched, it wasn't launched as a pioneering new chat interface. I don't see what's particularly interesting about it.

<comment><USER11> Google launched and showed off an example application that rips Campfire's look and feel off. As for whether it was a "pioneering new chat interface," that is hardly the point where ripping off design is concerned.

It's just like ripping off the layout and visual appearance of a designer's portfolio web site. There is nothing pioneering or innovative about the way designers make web sites to display their work, but there _is_ design in the chocies they make and there is value in those choices.

If design doesn't matter, Google could and should show a chat application with a completely different look. If design does matter, then they are executing a blatant rip off.

Is it illegal? Wrong? _Lame_? You can decide for yourself. But it is still a rip off.

 _update_ : This is my last word on the subject. But I will say the following: there is a very well-known standard of "obviousness": The Clean Room.

Perhaps this application was made in a clean room, or something close enough: if the people making it weren't familiar with Campfire and arrived at almost the identical design from first principles, then of couse I am happy to withdraw my statement and accept that the design in "obvious."

Perhaps they have already spoken up and assured the world that it is just a coincidence that their app is so similar to Campfire. But I am not convinced that a particular design is "obvious" if it is executed by someone who studied another design first.

<comment><USER3> This is actually not what "clean room" means.</comment></comment></comment></comment>


How to create a successful webcomic? - <AUTHOR>

My "how-to-make-awesome-comic-site-like-no-other" ideas so far:<p>- Make animationed shorts. People are vlogging with a video camera, but no one is doing that with animation.<p>- Make comics with HTML5 animations.<p>- Provide a new comic and a new video every single day.<p>- Mix and match infographic-style layout with personal comics and doodles.<p>Any thoughts? I'd be really thankful for any ideas or thoughts. Any thoughts. <comment><USER2> ship

<comment><AUTHOR> agree</comment></comment>


Preview: Docker and Containers EBook Series - <AUTHOR> https://github.com/thenewstack/docker-and-containers-ebooks

<comment><USER2> Awesome intro!</comment>


Why the Mauritius oil spill is so serious - <AUTHOR> https://www.bbc.com/news/world-africa-53754751 <comment><USER2> Some news said that the tanker got closed to island to connect Wi-Fi. OMG.

[https://www.lexpress.mu/article/381284/membres-dequipage- con...](https://www.lexpress.mu/article/381284/membres-dequipage-confirment- celebration-dun-anniversaire-bord-vraquier)

[https://www.news24.jp/articles/2020/08/14/10699738.html](https://www.news24.jp/articles/2020/08/14/10699738.html)

<comment><USER3> I can't view the Japanese link but the French article mentions nothing about connecting to the internet, or "WI-FI". Wouldn't a ship have satellite internet?

<comment><USER4> The Mauritian article says:

"Before the "Wakashio" ran aground on the reef at Pointe-d'Esny on the evening of July 25, the crew was celebrating the birthday of one of its members. This was reported by three crew members of the bulk carrier to Central Criminal Investigation Department (CCID) investigators.

They also stated that the bulk carrier had approached the island to pick up a wi-fi connection. Seven others made the same statement to investigators from Mauritius Shipping. These seamen initially made a history of their voyage which started in China to Australia and then another route from China, with a stopover in Singapore, before heading for Brazil.

It was on this route that the bulk carrier crossed the territorial waters of Mauritius. The crew of about 20 consists of three Indian nationals, sixteen Filipinos and one Sri Lankan. The "Wakashio" was under the responsibility of Captain Sunil Kumar Nandeshwar, a 58-year-old Indian national. They are represented by Mr. Kushal Lobine and Mr. Irsaad Munsoor, lawyers for the insurers of the Protection and Indemnity Club."

<comment><USER5> They almost certainly mean cellular connection, not wifi. Apparently it is quite common for ships to get closer to shore for this reason. All crew members have cellphones; satellite internet connectivity on the other hand is vastly more expensive and access among crew is limited for that reason (and even then typically justifiable only for business purposes).

</comment></comment></comment></comment><comment><USER6> Tangential but something that have been buging me for a while - these type events are not enough brought in to the equation when EVs are compared to ICEs.

I usually get comparisons to the refined gas/diesel with the whole process of the battery.

Not saying batteries are great for the environment, but we have had so many leaks during the years. Deep horizon is still leaking and where almost at 1.000.000 m3 if I recall correctly.

At least with batteries the pollution is kept more localized, which I believe is to be preferred.

<comment><USER7> Wait till all the used Tesla's get resold in poor countries and all those batteries end up in rivers and the ocean.

<comment><USER8> You mean in the countries where they literally dig up live copper wires to sell for cash?

Why would they dump hundreds of kilos of very expensive rare earth metals to rivers?

<comment><USER9> I think "dump them in the river" was a metaphor for "seriously damage the environment in order to extract the valuable bits" which is what we currently see with most waste processing.

</comment></comment></comment></comment><comment><USER10> There doesn't seem to be details about the cause of the collision as yet. However for a candid look at the grim reality of the maritime industry, and how these kinds of disasters are far too common, I highly recommend _The Outlaw Ocean_ by Ian Urbina. The human trafficking elements are particularly disturbing.

<comment><USER11> Also Normal Accidents by Charles Perrow

<comment><USER12> The port explosion in Beirut would make a perfect new chapter in _Normal Accidents_. I'm guessing the cause of the MV Wakashio accident will turn out to be a simple failure rather than a complex and unexpected failure mode (Perrow's "normal").

<comment><USER13> Economist Tim Harford has been running a small and occasional podcast series, Cautionary Tales. It opened with an episode discussing Perrow, produced immediately before, and releasing just after, Perrow's death last November.

He's looked at risk, may be thinking of technical debt, and I've suggested Beruit.

Recommended.

<comment><USER12> Thanks :-) _Cautionary Tales Ep 3 – LaLa Land: Galileo's Warning_ [1] has the following in the shownotes:

> Charles Perrow's Normal Accidents introduces the idea of complex, tightly- > coupled systems and has good accounts both of the Three Mile Island and the > Fermi reactor accidents. Just after we'd recorded the episode, I heard the > sad news that Charles had died on November 12th. He'll be missed.

[1] [https://timharford.com/2019/11/cautionary-tales-ep-3-lala- la...](https://timharford.com/2019/11/cautionary-tales-ep-3-lala-land- galileos-warning/)

</comment></comment></comment></comment></comment><comment><USER14> Drone footage of the ship:

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

Wikipedia article:

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

<comment><USER15> That particular video was published before the ship started leaking, and has a jarring soundtrack choice (John Williams, the Flying Theme from E.T.). People should check out the other videos in the channel to get a sense of how things have changed.

<comment><USER14> Yeah sorry, I didn't realize there were more recent videos and it's too late to edit my comment.

<comment><USER15> It's a gorgeous video! Which is weird and incongruous, lol.

</comment></comment></comment></comment><comment><USER16> >The ship, MV Wakashio, ran aground at Pointe d'Esny in late July, and oil began leaking from it last Thursday.

>Fuel has been transferred to shore by helicopter and to another ship owned by the same Japanese firm, Nagashiki Shipping.

So they had more than a week to prevent this.

<comment><USER17> I'm not liking the timeline either. News agencies are really dropping the ball on this one.

</comment></comment><comment><USER18> Why are these ships allowed to go anywhere near reefs?

<comment><USER19> Not to minimize it, but you seem to be only thinking about this one instance of a sunk tanker, and not the thousands and thousands of ships that do this on a regular basis with no problem. These low probability risks, and countless others like them, are part of a tapestry of a probabilistic horror show that supports our everyday way of life.

<comment><USER20> We are you assuming he/she is thinking in that manner? Some things you cannot put a price tag on. Getting oil cheaply from point a to point b is nice, but if all it takes is one major and uncontained spill to forever kill one of the few remaining large coral reefs...

<comment><USER21> We all think in that manner, all the time.

<comment><USER19> Exactly. I didn't mean it personally. It's human nature. Best we can do is recognize it. Or maybe, ignore it. I guess it depends on what you want in life...

</comment></comment></comment></comment></comment><comment><USER22> Jets usually avoid flying low over cities in case of crash. Can't oil tankers do something similar?

<comment><USER23> Sure, but in this case the crew headed closer in to the coast to get better wifi reception - they were celebrating a birthday party.

I guess the jet analogy would be jet pilot flies really low so his kids can see him wave from their window.

on edit: my only source for this birthday claim is a tweet [https://twitter.com/Ariel_Saramandi/status/12931545218922700...](https://twitter.com/Ariel_Saramandi/status/1293154521892270080) but I believe it as I am by nature a misanthrope.

</comment></comment><comment><USER12> I rewatched the Drone footage [1] js2 linked to and I think I made the same logical error that the captain/crew did; I mistook the breakwater as the edge of the reef and missed the slightly deeper ridge that juts out perpendicular to the island/lagoon.

The "coral ridge" that they hit is obvious in the many photos that are shown in an image search results on "aerial photo MV-Wakashio". I was surprised by the drone footage since it looks like the ship was perpendicular to the reef edge which means that the ship was heading directly at the large/populated island at near full speed but this was not the case. They were probably running parallel to the breakwater and hit this hidden anomaly in the reef and then wave action trapped the ship in this literal corner. Without tugs I don't think the ship could back out even if undamaged so I guess one outstanding question is whether a timely deployment of tug boats could have prevented the break-up of the ship.

The accident occurred at 8pm local time (16:00 UTC +4) so it was dark but the crew would have been awake. Tragic overconfidence.

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

</comment><comment><USER24> What are the financial penalties for this? Cost of damages most interesting angle and not mentioned in article.

Company and leadership on boat should be held liable to the greatest extent possible. Set an example to curtail this sort of reckless behavior.

<comment><USER25> Company will blame it on the captain, and that will be the end of it.

Sadly this is our reality.

</comment></comment><comment><USER26> Somewhat related: this startup is supplying graphene based absorbent pads called Sorbene to help clean up some of the mess: [https://www.sorbene.com/](https://www.sorbene.com/)

</comment><comment><USER27> They couldn't get the CEO to make a statement? A 2 minute rail delay gets an immediate apology from the CEO in Japanese companies - I guess destroying another country's beauty and livelihood doesn't warrant that.

</comment><comment><USER28> With so many seafarers not being let on shore(and not having wifi on board), not being relieved, and working months past the end of their contracts, it's only a matter of time before there are more accidents.

<comment><USER20> Until evidence points otherwise, this is just another spill in a long series of marine ecology disasters and blame should not be allowed to be placed on the coronavirus situation.

<comment><USER29> I don't think it has to do with the current epidemic.

</comment></comment></comment><comment><USER30> Since it's not happening in our backyard, I doubt the majority will care. We'll keep buying our precious cars, voting against green and nuclear, and continue our way of life unabated.

C'est la vie.

<comment><USER31> I wonder how much of globalism exists only because of distance-care relationship

</comment></comment><comment><USER23> I posted a related article a few days ago [https://news.mongabay.com/2020/08/mauritius-grapples-with- wo...](https://news.mongabay.com/2020/08/mauritius-grapples-with-worst- environmental-crisis-in-a-generation/)

</comment><comment><USER32> It's past time to move off fossil fuels. Join the EV revolution and let's use the technology and engineering of the past to carry us to a future where we can look back at the ancient relics of Industrialization V1 and wonder how we were so primitive.

</comment><comment><USER33> Will anyone get fined and will the processed from the fine go to help the local area?

<comment><USER34> Of course. not.

They're throw some cleanup stuff at it, claim it's better and within a week will all be forgotten.

</comment></comment><comment><USER35> Oil spills may not statistically happen that often, but they happen way too often. There has to be a way to prevent this from happening ever again.

<comment><USER36> Easy, stop using oil.

<comment><USER37> Not so easy. Powering large ships for the ranges needed for global trade without using fuel oil is currently an unsolved problem. There's a small EV cargo boat with a range of only 50 miles. Battery density and ship efficiency needs to be greatly improved before we can replace the engines and fuel tanks in cargo ships.

(For clarification, the oil spill in Mauritius is the fuel oil from a bulk carrier, not an oil tanker.)

<comment><USER38> Sails ?

<comment><USER37> There are various concepts for wind propulsion but even the most optimistic think they'll only provide some of the energy needed. Some kind of EV/wind hybrid might be the answer but battery size is still a major issue.

</comment></comment></comment></comment></comment><comment><USER39> Seems like a weird argument. So oil spills in unprotected areas are less serious because nature there is already impacted in other ways? Won't make any difference to the animals and plants in the end.

<comment><USER40> > So oil spills in unprotected areas are less serious because

I do not think this is the point the author tried to make. I read this more like "despite the minor amount of oil spilled compared to other spills, this one will hurt like a big one".</comment></comment>