Show HN: Wayland compositor in around 500 lines of annotated C - <AUTHOR> https://gist.github.com/SirCmpwn/ae4d1cdcca97ffeb2c35f0878d75dc17 <comment><USER2> I saw this discussion yesterday:

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

And thought I'd whip up something for Wayland, too. Happy to answer questions about Wayland if anyone has some!

<comment><USER3> I read the blog posts you linked to yesterday, regarding wlroot and understanding how Wayland works. They help a lot in understand what Wayland is and how it work. It's really well written, thanks.

There's just one thing that's still a little weird. You show with Wayland McWayface how you can start clients, and use gnome-terminal in the example. The Gnome terminal shows up with window decorations, and as I understand it, that's because Wayland encourage (require?) the client to provide those decorations.

If the client provides the windows decoration, then that sort of eliminates what most of us would define as a Windows Manager, at least for the very simple ones. So it seems like you could write a GTK application for instance, say a desktop like the old Windows 3.11, theme it and then just start it with a random compositor.

I guess the question really is, could you write a general compositor, which just handle inputs and output, and then use that compositor to run any number of different desktop environments where the authors technically doesn't need to worry about Wayland?

<comment><USER2> >I guess the question really is, could you write a general compositor, which just handle inputs and output, and then use that compositor to run any number of different desktop environments where the authors technically doesn't need to worry about Wayland?

This is a goal we're working towards in the wlroots camp. You could do this, but the issue would be running a lot of the things that tend to define the desktop environment, such as the panel, menus, desktop feel, etc. In order to support that, we need a Wayland protocol that lets clients have some say in where they are displayed on-screen, such as a taskbar wanting to be shown across the bottom. For wlroots we made such a protocol[0], and it is slowly being adopted across the ecosystem. Porting DEs to use it would be a great way to help improve Wayland :)

[0] [https://github.com/swaywm/wlr- protocols/blob/master/unstable...](https://github.com/swaywm/wlr- protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml)

<comment><USER4> >> You could do this, but the issue would be running a lot of the things that tend to define the desktop environment, such as the panel, menus, desktop feel, etc. In order to support that, we need a Wayland protocol that lets clients have some say in where they are displayed on-screen, such as a taskbar wanting to be shown across the bottom.

Isn't that the job of something higher level? I thought the wayland compositor would implement some desktop environment functionality. In other words the compositor itself would also define the DE by starting a panel and placing it at the top/bottom/side and by starting and placing any other items/processes that are part of that environment. I understand that this would add complexity to the compositor but isn't that where it really belongs? I still feel like it's a security concern for general processes to know much about the environment they are running in. OTOH I want to start several things at login and have the ability to place the windows from a script (like .login and passing window geometry to X). These are interesting issues and I hope the people making the decisions are keeping things both secure and simple in the software.

BTW, I'm hoping for animated wallpaper on my desktop. This is a low priority, but would that be an application that runs in root window, or would that be something the compositor knows to start an places it there? IMHO that's so special it's more of a compositor feature, but who knows... Should there be added protocols to do these things or just make a special compositor feature? I'm in favor of having it a compositor feature rather than increasing complexity of a protocol - I think it's less complex.

<comment><USER2> > I thought the wayland compositor would implement some desktop environment > functionality. In other words the compositor itself would also define the DE > by starting a panel and placing it at the top/bottom/side and by starting > and placing any other items/processes that are part of that environment

It can, that's how GNOME works today. It's not how it generally works on X, though, and it's not very modular.

As far as security is concerned, our layer shell protocol assumes that the client is trusted. We're working on ways of securely allowing third-parties to access this, but it's possible today to start implementing layer shell and restrict its use to trusted clients.

>BTW, I'm hoping for animated wallpaper on my desktop

This is possible with the layer shell protocol I'm talking about.

<comment><USER4> >> It can, that's how GNOME works today. It's not how it generally works on X, though, and it's not very modular.

We don't need modular.

>>>BTW, I'm hoping for animated wallpaper on my desktop

>> This is possible with the layer shell protocol I'm talking about.

It's also possible by building the feature into the compositor. No new protocols or possible security issues needed. Simpler is better in most cases.

<comment><USER2> I don't think that makes it simpler. I think that just makes a massive compositor which tries to please everyone and ends up pleasing no one, and being 10x the size it needs to be.

<comment><USER4> Ultimately the compositor IS the desktop environment. You can try all you want to keep it simple and enable functionality via other apps using a protocol, but that's essentially a complicated way of making plug-ins to the compositor. You will end up delegating security to everyone else.

<comment><USER2> That's not true. It's true for GNOME, and I guess Enlightenment, but they are not the only players. If you think there are legitimate security concerns with our approach then I'm open to hearing them but so far as I'm concerned so far you haven't said anything of value.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> Been hoping Wayland would help improve the sad state of remote desktop on Linux but from what I can see I'll have to way another 5+ years for something useful :(

I've installed KDE Neon on a NUC to play around with and I really like it a lot. But the lack of proper RDP server support is the primary thing keeping Windows on my primary machines.

Key features required:

\- Ability to resume local session from remote client and later locally again.

\- Ability to start session from remote client if no local session exist, and later resume it locally.

\- Performance (framebuffer-delta ala VNC is no-go).

\- Functional clipboard, so I can copy/paste between client and host. Text required, though images and files would be nice.

Anyway, really nice piece of code. Sure it's 500 lines but it seems quite straight forward.

<comment><USER2> We haven't forgotten about you, but we could use your help if you want it done fast. We've made some important progress towards supporting this functionality recently. A protocol our people have been working on is currently undergoing standardization[0] which enables software keyboard devices. A similar protocol could enable software pointer devices. We also made another[1] protocol for efficiently capturing the contents of the display.

Plug all of these together and an RDP server is probably possible. Maybe a few weeks of work with FreeRDP for the motivated programmer. My email is in my profile, reach out if you want to make some connections and get started.

[0] [https://lists.freedesktop.org/archives/wayland- devel/2018-Au...](https://lists.freedesktop.org/archives/wayland- devel/2018-August/039237.html) [1] [https://github.com/swaywm/wlr- protocols/blob/master/unstable...](https://github.com/swaywm/wlr- protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml)

<comment><USER6> Another issue with remote desktop (using VNC) on Linux is keyboard layouts (for inputting non-latin characters). With X server, the server passes a physical key number (keycode) and modifiers state (whether keys like Shift or Caps Lock are active) to the client and the client converts it to the corresponging character (keysym) using translation tables loaded earlier from the X server.

When you are accessing another computer remotely using protocols like VNC the local computer's keyboard layout can be different and it can produce characters not present in remote computer's translation tables. The VNC protocol itself transmits keysyms, not keycodes. So there can be a situation when there is no matching physical key number (keycode) for given character. So VNC servers like x11vnc had to modify translation tables on the fly and insert non-existing key into the tables and pass that key's number to X clients.

I wonder if this problem is solved with Wayland. As I understand, Wayland uses similar scheme and the compositor sends only a physical key number (keycode) along with the modifiers to the client and the latter does the translation. By the way, would not it be easier if the compositor did the translation itself?

The hack I described can also cause issues with hot keys. If I run application locally and it has a hotkey like Ctrl + S, and my keyboard has two layouts (English and Russian) then it will probably work with both of them because the application can bind the hotkey to physical key number. But when we send key presses remotely over VNC we send only a keysym (a letter code), not a keycode. If the remote server doesn't have Russian layout it is unable to guess what physical key was pressed and cannot recognize that I pressed Ctrl + S in Russian layout.

</comment></comment></comment><comment><USER7> This code is so well-commented that it makes me want to do some graphics programming – and I haven't needed to do any graphics programming other than HTML canvas in 30 years. What a fantastic contribution. Thank you.

<comment><USER2> Any of these projects could use your help :)

[https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots)

[https://github.com/swaywm/wlroots/wiki](https://github.com/swaywm/wlroots/wiki)

</comment></comment><comment><USER8> This is very valuable educationally! Thanks!

A slightly less minimal, but still small — 2000 lines total among all files — DE, leveraging Mir†, rather than wlroots, is here:

[https://github.com/AlanGriffiths/egmde](https://github.com/AlanGriffiths/egmde)

† yes, Mir can now use the wayland protocol

[trigger warning: C++]

<comment><USER9> I'm confused. Wasn't Mir supposed to be an alternative to Wayland?

<comment><USER8> There was Mir the protocol and Mir the library/codebase implementing the protocol. Since the Mir protocol and Wayland weren't _that_ different — after all both were intended as replacements for X — it didn't take much effort to adapt the Mir library to use the Wayland protocol.

(As for why Canonical thought that developing their own protocol was a good idea, I'm not sure, but based on what I remember reading about it from various sources — don't have links on hand, so take the following with a pinch of salt:

1\. They, rightly or wrongly, thought that some bad decisions were made with Wayland

2\. They preferred to have control over the protocol to be able to experiment / make quick adjustments based on their needs, and the experience they gained while using it in Unity8 (the main DE using the Mir library).

3\. They were aware that porting the Mir library to use Wayland, if/once this was decided valuable, would not be difficult (as turned out to be the case).

From a technical point of view, IMO it wasn't a completely terrible decision, but from a PR one it was.)

<comment><USER10> If they had used Mir as a test bed like Chalk is for Rust, it might have made sense.

</comment></comment></comment></comment><comment><USER11> I haven't really followed Wayland very closely but as a huge fan of tiling WMs (I've used StumpWM for more than a decade, although I switched to dwm lately) I've been a bit worried by the claims that Wayland doesn't have a window manager per se etc... Although I admit that's mainly because I haven't taken the time to understand what Wayland is exactly.

Just in order to aleviate my fears, can somebody tell me if in this brave new world it'll still be possible to effectively implement something like DWM or some other tiling WM "within" Wayland? Are there pitfalls I should be aware of?

I suppose there's got to be a way to do custom tiling, but I worry that there might be other less obvious limitations. For instance every time I attempted to use custom "window manager" on Windows (to add virtual workspaces for instance) I quickly noticed that it didn't work very well. One problem was that the window management was cooperative instead of preemptive: when the "window manager" attempted to hide a window it'd basically send a message to the application requesting that the window be minimized. If the app was frozen or simply uncooperative it'd remain where it was. Could that happen in Wayland?

<comment><USER12> Wayland works the way that Windows has since Windows Vista.

<comment> yjftsjthsd-h ...is this an endorsement or a downside?

<comment><USER12> just a fact.

</comment></comment></comment></comment><comment><USER13> you actually went and did it! not that I doubted it ;)

thanks, your contributions to the community are invaluable! this looks like a pretty awesome way to learn wayland :)

</comment><comment><USER14> > seat, <…> conceptually includes up to one keyboard, pointer, touch, and > drawing tablet device.

So it seems that hacks like [0] are impossible here. Is this a limitation of protocol or just this compositor (and/or wlroots library)?

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

<comment><USER2> No, a very similar setup is possible depending on the compositor. wlroots enables this. The Wayland protocol only exposes up to one keyboard per seat to the client, but wlroots lets you pass input to seats in any manner you choose. In sway you can have multiple keyboards with multiple layouts and we swap them out whenever you start typing on a different keyboard.

</comment></comment><comment><USER15> Without wlroots it would need several times more loc.

<comment><USER16> Not to mention if you didn't use libc - and think of how many loc it'd need if you wanted to implement the kernel and userspace tools too!

Thankfully, we live in a world where libraries exist and we can use them to handle the low-level details, and then we only need to care about the 500 lines of meaningful application-specific logic :D

<comment><USER17> totally missing the point

edit: can't reply to you because of all the downvotes

<comment><USER16> So explain the point? In several threads recently I've seen people say "The application's line count is higher if you also count the libraries as part of the application!" \- I mean yeah, sure, that's a factually correct statement, but... so what?

<comment><USER18> The point is that this app is 500 lines of C but it'd be two lines of Python:

        from wayland import solution_to_the_problem
        solution_to_the_problem()

In this case, wlroots is literally a library for writing a compositor.

("A small demonstration of the wlroots API" would have been a fine title for this post. Pretending it's a small amount of code is silly.)

"I made a tiny webserver using only the Linux kernel" is impressive. "I made a tiny webserver using only the Golang webserver API" is not as impressive. "I made a tiny social networking website using the Golang webserver API" is heading back towards impressive.

<comment><USER2> You don't have to be impressed, but I don't necessarily think it's disingenuous. A "small" Wayland compositor which doesn't use a library like wlroots is nigh impossible. The code for handling DRM+KMS alone is over 2000 lines of code, and that's tangental to the goal of "make a Wayland compositor". I'd compare it to saying a game written with GLFW isn't impressive because they didn't do all of the work to set up an application window.

<comment><USER19> For a toy compositor, is there any reason not to just use SDL? The DRM and KMS side of things is interesting, but doesn't help much in understanding the Wayland protocol.

<comment><USER2> You certainly could make a compositor with SDL, but I don't think it would be any better than wlroots. We also provide an abstraction of the underlying window system, the same code which runs your compositor in an X11 window can also run it on KMS+DRM without any changes (the compositor in this very link can run on X11, Wayland, and DRM+KMS with no changes). It also gives you a number of useful things like an implementation[0] of xdg-shell, which alone can be a couple thousand lines long. Also, negotiating graphics resources with clients is going to require you to get into the gritty OpenGL details if you intend to be efficient (and some clients don't even support shared memory, so it's also a matter of compatability). You'd also need to implement the seat to have input support, which can be another ~1,000 lines of code. GTK+ requires the data device to be implemented as well - over 1,000 more lines of code in wlroots[2].

[0] [https://github.com/swaywm/wlroots/tree/master/types/xdg_shel...](https://github.com/swaywm/wlroots/tree/master/types/xdg_shell) [1] [https://github.com/swaywm/wlroots/tree/master/types/seat](https://github.com/swaywm/wlroots/tree/master/types/seat) [2] [https://github.com/swaywm/wlroots/tree/master/types/data_dev...](https://github.com/swaywm/wlroots/tree/master/types/data_device)

That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features (like GTK+ dropdowns and context menus), and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code. In order to be equivalent in functionality to the TinyWL compositor I posted today, it would probably need to approach 5-6,000 lines.

<comment><USER19> >That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features [...], and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code.

That's what I'm interested in. wlroots hides pretty much all of the details about what's going on. This would be more about producing an example than an actual functional compositor. My next Rust project, maybe. Or even C#, for that matter.

<comment><USER2> If you're producing an actual functioning compositor you should be using wlroots anyway. It's unopinionated, we call it "40,000 lines of code you were going to write anyway". It's not practical to make a compositor without leveraging wlroots unless you have a huge team like GNOME or KDE - this is advice from several compositors who tried and are now using wlroots.

Still, if you insist on making _everything_ yourself, the wlroots code is pretty accessible and I've heard from people working on KDE and Mir that it's the best reference code to study for understanding how everything works and applying it to their own software.

[https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Please note that it is not written from scratch and is using a wlroots library that does most of the job. Most of the code are just the handlers for events emitted by the library. You cannot write a Wayland compositor and implement all required interfaces with just 500 lines.

</comment><comment><USER20> My question would be: given that current Wayland implementation kills all my windows when an error happens, in contrast with X11 where the session is killed but the windows are kept; what is the behavior of this compositor regarding errors?

<comment><USER2> Same, a crash will kill all of your applications. But that's also what happens when xorg-server crashes. The difference is that window management is usually handled in a separate process, and if that process crashes you don't lose the windows themselves. xorg-server is generally stable enough so long as your graphics drivers are stable and you don't do anything weird. It'll take time for Wayland compositors to become similarly mature.

There has been some discussion around making Wayland compositors that behave similarly, and on crash reslience with a Wayland-specific design as well, notably:

[https://arcan-fe.com/2017/12/24/crash-resilient-wayland- comp...](https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/)

</comment></comment><comment><USER21> For values of 500 exceeding 900, this is about 500 lines.

<comment><USER22> It says 500 lines _of C_.

<comment><USER21> Ah, OK. 500 lines of C, which are (further) annotated.

<comment><USER17> 600

</comment></comment></comment></comment><comment><USER17> How do I use this on arch linux?

<comment><USER17> lol you need this which is 40k lines of code [https://github.com/swaywm/wlroots.git](https://github.com/swaywm/wlroots.git)

only 500 lines of code (plus 40k but whose counting)

<comment><USER2> TinyWM also needs all of this code:

[https://cgit.freedesktop.org/xorg/xserver/](https://cgit.freedesktop.org/xorg/xserver/)

~500,000 lines of code that wlroots does not depend on, but who's counting.

<comment><USER23> The reasonable comparison would be with xlib. The xserver code is all about the hardware drivers.

<comment><USER2> Actually, the repository I linked to does not do much more driver stuff than wlroots does. The xorg drivers are maintained in separate trees:

[https://cgit.freedesktop.org/xorg/](https://cgit.freedesktop.org/xorg/)

Most modern xorg drivers depend heavily on mesa to do the heavy lifting:

[https://cgit.freedesktop.org/mesa](https://cgit.freedesktop.org/mesa)

wlroots depends on mesa as well.

xorg-server _does_ do more things than wlroots, but it's mostly legacy stuff. In terms of features anyone wants from a modern display server, they're pretty close. wlroots is repsonsible for spinning up an EGL context, talking to libinput, configuring DRM and KMS display resources, allocating GPU resources with GBM, negotiating pixel buffers with clients, etc, all things that xorg- server is doing for TinyWM.

</comment></comment></comment></comment></comment><comment><USER24> If Wayland is the "Linux desktop" then all the advantages are gone. You do know that Wayland's design effectively destroys any choice and customization right? Wayland's protocol is basically an isolation prison that requires "big DE's" and destroys choice. The protocol moves everything into one central place called the "compositor" this machinery must provide:

\- the window manager \- the hotkey daemon -the compositing effects -the windowing server -screen reading tools -screenshots -screen casting -magnifying glass tools -global dictionary tools -etc etc etc everything.

Wayland's design makes it impossible to write a portable hotkey daemon for instance. Supposedly for "security reasons". Wayland is a GNOME dev's dream, it kills the ability of people to control their own system. If you're actually excited for Wayland you either thoroughly misunderstand what it brings and just like it because it's new or you're a drooling GNOME-lover who hates customization.

<comment><USER2> This is FUD. One of wlroots core goals from day one has been to promote the standardization of cross-desktop protocols that allow for these features. We have already addressed two of the points you brought up, namely screenshots and screen casting, via these protocols:

[https://github.com/swaywm/wlr- protocols/blob/master/unstable...](https://github.com/swaywm/wlr- protocols/blob/master/unstable/wlr-screencopy-unstable-v1.xml)

[https://github.com/swaywm/wlr- protocols/blob/master/unstable...](https://github.com/swaywm/wlr- protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml)

There are several more protocols we have written and are working on to address similar concerns: [https://github.com/swaywm/wlr- protocols/issues](https://github.com/swaywm/wlr-protocols/issues)

3 delegates from wlroots, including myself, who together represent 8 distinct Wayland compositors, are joining 3 delegates from KDE at XDC 2018 to discuss the standardization of these protocols and propose them for integration across the whole ecosystem.

<comment><USER24> After 9 years there is not even anything close to a universal standard and discussion across compositors has just started this year. That's embarrassing.

<comment><USER2> There's already been universal standards under discussion for a long time, for example xdg-shell for application windows. The recent discussions are attempting to make _more_ standards, and has been going on for 2 or 3 years now. This is a lot of work, we're replacing the X11 stack which has a legacy going back over 20 years.

<comment><USER24> >xdg-shell for application windows.

Which is implemented by literally who? I can see a GNOME mutter commit but can't find anyone else from a few minutes of googling.

Also: "As of June 2014, XDG-Shell protocol was not versioned and still prone to changes. "[1]

Who else loves to build software atop unstable APIs?

>The recent discussions are attempting to make more standards, and has been going on for 2 or 3 years now.

These should've been going on since the begin, really makes you think what kind of intent the Wayland founders had. Wayland is being pushed as the future and there still isn't even a way to have a universal fucking screenshotter, I guess it's a security feature to be locked out of your own desktop, right?

1: [https://en.wikipedia.org/wiki/Wayland_(display_server_protoc...](https://en.wikipedia.org/wiki/Wayland_\(display_server_protocol\)#XDG- Shell_protocol)

<comment><USER2> >[xdg-shell] is implemented by literally who?

Uh... everyone. Mutter, Kwin, qwayland, wlroots, wlc, Sway, waymonad, Way Cooler, Weston, Enlightenment, and Mir all support it, as well as clients like GTK+, Qt, GLFW, SDL, EFL...

Look, you don't have to use Wayland. No one has said it's done, and Xorg still works fine. If it doesn't support everything you need, then it's not for you, no big deal.

<comment><USER24> >No one has said it's done, and Xorg still works fine.

Not when apps will exclusively choose to support it.

<comment><USER2> Well, woe is you then.</comment></comment></comment></comment></comment></comment></comment></comment>


Once-In-a-3B-year Statistical Move – Jamie Dimon on the US Bond Market - <AUTHOR> http://www.businessinsider.com/jamie-dimon-on-the-bond-flash-crash-2015-4

<comment><USER2> This is classic Business Insider. They explicitly ignore the context and try to shake you up with a cherry picked quote. Jamie Dimon doesn't think, and doesn't want his reader to think, that October 15th was a once in a 3B year move. Specifically, in the letter, Jamie Dimon 1) never uses the term "flash crash" and 2) spends the previous five paragraphs explaining exactly how and why liquidity dynamics in the fixed income markets have changed.

What he is saying is that the Oct 15th move looks really strange, but not if you actually understand how fixed income market makers are reacting to the Volker rule. Quoting Dimon:

 _For instance, the total inventory of Treasuries readily available to market- makers today is $1.7 trillion, down from $2.7 trillion at its peak in 2007. Meanwhile, the Treasury market is $12.5 trillion; it was $4.4 trillion in 2007._

What he's saying is that market makers have smaller inventories on absolute terms, and much smaller inventories on relative terms, so when multiple big market participants try to move in the same direction at the same time, there is much less inventory available to soak up demand.

<comment><USER3> Come on, every finance guy knows to cut off tail risk, yet they still don't. Look at LTCM, with all the brains they had still didn't cut off tail risk and Meriwether still came back and got burnt again. Look at Victor Niederhoffer, got burnt twice the exact same way not cutting off tail risk. Then you get a guy like Taleb profiting off tail risk. Complaining about liquidity crunches does not count as its one of the main parts of the tail risk.

<comment><USER4> What you're talking about is a hedge. Hedges are expensive. A better strategy to a lot of investors is to "hedge" by trading smaller. Of course the spectacular failures you name were spectacular because they weren't hedged and were done with immense leverage. There is no way looking forward to predict if a hedge that eats 1/2 your returns every year is a better investment than just taking a catastrophic loss every several years. And it's not as simple as taking a 50% haircut on every trade: in reality maintaining a hedge will turn many of your small winners into losers.

I personally guard against the prospect both by staying small (trading with only a small portion of my total account) and by maintaining net short deltas (beta-weighted). Keeping short deltas in a bull market with upward drift also has a cost, but it lets me sleep easier at night.

<comment><USER3> Bottom line, mean reversion strategies will bite you in the ass at some point.

<comment><USER4> I think it's clear that price isn't mean reverting. Vol, on the other hand, I think is.

</comment></comment></comment></comment></comment><comment><USER5> Dunno guys, when six-sigma events keep happening every seven or eight years, maybe it's time to reconsider a normal distribution as our go-to model.

<comment><USER6> I agree.

Normal distribution, arrived at via the central limit theorem, assume that the underlying distributions are independent. They may well approximate independence most of the time, but when extreme events happen, the distributions are correlated, the CLT doesn't apply (not in the simple way it is normally presented), and the overall result is most definitely not normally distributed.

Normal distribution is a terrible model for estimating risk.

The quote isn't the first to confuse bad statistics with some inherent weakness in statistics. Black Swan was a worldwide bestseller based on the same canard.

<comment><USER7> but if you stop assuming processes are iid Normal, the math gets somewhere between hard and very hard

</comment></comment></comment><comment><USER8> Wall Street has historically underestimated tail risk. I'm curious under what model this is a "once in 3 billion years" sort of move. Basically, financial markets don't behave as a normal distribution, and black swans are a lot more likely than their 7-sigma probabilities would suggest.

</comment><comment><USER9> > of course, this should make you question statistics to begin with

This doesn't make me question statistics at all. What it does do is further my belief that those doing financial forecasting have the same issues as meteorologists: incomplete models.

</comment><comment><USER10> This is not at all surprising. Statistics isn't the right tool for financial analysis... it's just the best tool that we have. Incredibly unlikely statistical events happen all the time in finance.

A great read on an alternative view on the topic of using statistics for finance is The (Mis)Behavior of Markets by Benoit Mandlebrot [1]. It's very well written, basic enough for most to comprehend and first book on finance I read in college (before I went on to major in finance + math).

The aforementioned book has some very interesting notions with Trading Time being my favorite. Basically one can near-perfectly "forge" financial data with fractal objects called "financial cartoons" [2]. The objects are composed to two distinct fractals - one for price vs trading time and another for trading time vs clock time [3]. The latter rescales the volatility seen former, either compressing or expanding it. Rescaling volatility isn't a new idea, but it was a parallel "discovery".

There has been some work on figuring out how to use Fractal Geometry to analyze financial time series data but it's still in its infancy. The problem is figuring out how to transform the data into the fractals domain + figuring out what the results from a fractal based analysis would mean for forecasting future events. I've been working on these problems for many years (in earnest in college and as a hobby thereafter) but made little true progress.

[1] [http://www.amazon.com/The-Misbehavior-Markets-Financial- Turb...](http://www.amazon.com/The-Misbehavior-Markets-Financial- Turbulence/dp/0465043577)

[2] [http://classes.yale.edu/fractals/randfrac/Market/Fake/Fake.h...](http://classes.yale.edu/fractals/randfrac/Market/Fake/Fake.html)

[3] [http://classes.yale.edu/fractals/randfrac/Market/TradingTime...](http://classes.yale.edu/fractals/randfrac/Market/TradingTime/TradingTime.html)

<comment><USER11> Read Mandelbrot's book, it's an excellent gateway drug into that type of thinking.

> There has been some work on figuring out how to use Fractal Geometry to > analyze financial time series data but it's still in its infancy.

Are you talking about things like the hurst exponent and such?

<comment><USER12> > Modeling extremal events

[http://www.amazon.com/dp/3540609318/?tag=googhydr-20&hvadid=...](http://www.amazon.com/dp/3540609318/?tag=googhydr-20&hvadid=39534863222&hvpos=1t1&hvexid=&hvnetw=g&hvrand=13475283605991488718&hvpone=76.24&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_7l4nyly3gm_b)

</comment></comment></comment><comment><USER13> I suppose that means the Swissie unpegging from the Euro qualifies as a once- in-six-trillion-year event ;)

Could any of the experienced traders on here offer some insight into taking advantage of the upcoming volatility in intra-day Treasuries price-action? Is it mostly done via TY futures and options or are some of the directional, leveraged ETFs (e.g. $TYO) also attractive? Or are indirect strategies preferable?

<comment><USER4> Unless your timeframe is strictly intraday, I'd avoid the ETFs. In most cases the futures are trading in _backwardation_ which just means that next months futures contract is more expensive than this months. So when they do the roll every month there's a slight drag. This is the problem with leveraged ETFs but also a number of popular non-leveraged stocks like USO and UNG.

I'm curious why you think there will be an increase in upcoming volatility intraday?

My opinion as a trader is: markets are random, scalping/daytrading is a hard (some would say impossible) way to make a living. I like to trade options because there are more ways to win. I can collect theta (time) decay even if the price stays fixed.

If for example you think bond yields will increase, then you're bearish on the bond market, so that view could be expressed by buying a calendar spread... eg in $TLT, sell the May $130 put and buy the July $130 put. The goal is that the May put decays in value while the long-dated put decays more slowly. Increased volatility will have an outsized effect on your long July option. You can do that trade for $192 per 1-lot.

But to be clear, that's very different than scalping in and out of a position intraday.

</comment></comment><comment><USER14> Well, duh, stock (or bond) market is not stochastic process.

</comment><comment><USER4> I sell premium as a primary investing strategy and as a rule there are only 20 or so underlyings with active enough derivatives markets by my standards. In widely traded underlyings not only do you get tighter markets, but a more valid crowd-sourcing of option probability.

As a rule, derivative liquidity in the bond market is significantly lower than equities.</comment>


How my team moved from loud co-working and never looked back - <AUTHOR> https://medium.com/@primozcigler/rent-a-quiet-and-productive-working-space-at-the-proteusthemes-office-in-ljubljana-slovenia-4fb4e4975973#.ep4r7qhny <comment><AUTHOR> This is just a quick writeup how larger coworking with open space didn't work for us. Ignore the 2nd part of the article as it is relevant only to locals.</comment>


Why being an Entrepreneur is a lot like being an MMA Fighter - <AUTHOR> http://www.linkedin.com/today/post/article/20130621175510-10486099-why-being-a-real-entrepreneur-is-a-lot-like-being-an-mma-fighter

<comment><USER2> Fluff. Don't know about the silly comparison.

Been dropped on my neck by guys 60 lbs heavier then me training; wrestling, not having take-down defense, then a few arm cranks, neck cranked by smaller guys with better technique, cracked in the face when I used to train, included muay thai. All in the goal of competing amateur (which didn't happen due to a bad neck drop from a takedown).

Probably concussed with some hard blows. Reaching for comparisons by "they know they will lose"?</comment>


Thoughts about Pi - <AUTHOR> http://www.colorforth.com/pi.htm <comment><USER2> Diameters might appear in drawings. But they NEVER appear in physics. (The distance between particles determines forces. Diameters are a boring parameter about the size of something.) Machine tool programming is mostly radii in the paths, and diameters in the setup parameters.

<comment><USER3> > Diameters might appear in drawings. But they NEVER appear in physics.

Even as a characteristic size in, say, Reynolds number definition?

</comment></comment><comment><USER4> The statement about the diameter being the interesting parameter is kind of exactly wrong. This is true for all the same reasons Tau is a better constant than Pi.

For example, how does one derive the area of a circle? The most natural way is to integrate with respect to radius. When using Tau and radius, you get A = (1/2) _Tau_ r^2, which is nice since it looks a lot like the integral of, say, momentum, which gives you kinetic energy. If you use Pi or diameter or both, then weird factors of 2 start to creep in. It's also much more natural to think about defining the radial extent at each angle, rather than the diameter, especially if you're dealing with something other than a circle that has changing radius.

<comment><USER5> Tau is not happening.

<comment><USER6> I'll echo what gp said to help make tau happen:

 _tau_ : the circumference (perimeter) of a circle.

(1/2) _tau_ ^2 : the area of a circle.

Beautiful. To go from one to the other, you integrate or take a derivative. Like gp said, there's no weird factor of two. Just the power rule in action.

<comment><USER7> You seem to have left out the r in both of those expressions.

Tou r. .5 tou r^2 .

<comment><USER8> Nope, all circles have a perimeter of 19.7392088022.

</comment></comment></comment></comment></comment><comment><USER2> Yeah but the radius of the moon's orbit is sure interesting.

</comment><comment><USER9> Your conjecture as to the surface area of a hypersphere embedded in 4 dimensions (a "3-sphere") is not borne out :) The answer is in fact d^3 pi^2 / 4\. See [https://en.wikipedia.org/wiki/N-sphere#Volume_and_surface_ar...](https://en.wikipedia.org/wiki/N-sphere#Volume_and_surface_area)</comment>


3241 people have me in my circles and I don't know why - <AUTHOR> https://plus.google.com/s/bas%20dirks I don't know if this is a common occurrence, but it seems that 3241 people/(accounts) have added me to their circles, whilst my own circles consist of 12 people. I hardly use g+ but the accounts seem legit. Do I put friend-recommendation algorithms in panic mode, have I been "circled" by a very social botnet, or is there another reason why I have 3241 followers? <comment><USER2> someone like Scoble probably put you in a circle and then 3k folks followed that circle.</comment>


GPS signal disturbed at altitudes above 2000-3000 feet over Norway [pdf] - <AUTHOR> https://rntfnd.org/wp-content/uploads/Norway-Comms-Auth-Report-GPS-Jamming-Sept-2017.pdf <comment><USER3> It is worth noting that there are two different ways to attack GPS: jamming and spoofing. Jamming is when you broadcast a noise signal at the GPS frequency, which prevents affected receivers from receiving the GPS signal. The result is that the GPS doesn't know where it is. Spoofing is when you send out a fake GPS signal that appears genuine but has the wrong timing. The result is that the GPS thinks it knows where it is, but it's wrong. Spoofing is more difficult -- and far more serious -- than jamming. What is reported here appears to be (an attempt at) jamming, but spoofing attacks have also been reported in the past.

[https://www.schneier.com/blog/archives/2017/09/gps_spoofing_...](https://www.schneier.com/blog/archives/2017/09/gps_spoofing_at.html)

<comment><USER4> This is what keeps my awake at night sometimes... that one of US drones flying over Afghanistan will be eventually fooled into thinking the target it has to drop a bomb on is actually somewhere else over the Europe.

<comment><USER5> The GPS P(Y) and Military codes exist to (hopefully) prevent spoofing.

<comment><USER6> They aren't. A spoofer doesn't need to know what the signal means/be able to decrypt it. Just retransmit signal received from a different place at higher power. Only way to distinguish it from a real one is timing, but that requires an atomic clock, which is $15,000 and too expensive for most applications.

But, military grade GPS receivers use virtual beam forming to achieve a very high attenuation of spoofing signal so they are extremely hard to spoof, they always get the real signal as stronger.

<comment><USER7> Yeah I doubt the engineers forgot about replay attacks when designing their military GPS.

<comment><USER8> They arn't very easy to avoid, say you capture the signal from a satellite that is not visible to the receiver, or being jammed out, unless you have an extremely high precision clock, you can just delay the signal rebroadcast and spoof away.

<comment><USER9> Everything involved in GPS requires all the nodes (both the senders and the receivers) to have "extremely high precision clocks."

That's the whole idea, really: you, the receiver, have a clock, and a map of where the various GPS satellites will be around the earth at given times. You "hear" the current time announced from three satellites (along with their station IDs), and compare those times to your clock to figure out the flight time of the data, and thus the distance to the satellites. Then you take the satellites' known positions on the map at the current time, plus the flight times, and triangulate your own position.

If one of the three times you've received is a "lie", then its relative time will correspond to an impossible distance for that GPS satellite to be relative to where the map says it should be (e.g. over the horizon relative to you), and relative to where the _other_ two satellites that you heard from are. (Theoretically you _could_ receive such signals—using reflectors, like HAMs do—but GPS discounts this possibility and just considers it invalid data.)

<comment><USER10> GPS receivers do not have clocks. Atomic clocks are expensive and large; there is no way you get one every device.

Only the satellites have atomic clocks. The receiver get the time from the satellites. It basically compares the time delay between the satellites to determine position and time.

<comment><USER9> I didn't say they have _atomic_ clocks. They do have clocks, though. Like most computers do. And they are high-precision, and are low-drift _enough_ to predict the locations of satellites as long as they have been re-synchronized within the last few days or so.

Which, as you say, also happens by just observing the time signatures from the satellites. You need four visible satellites to determine your own time, though, whereas you only need three for position, so time isn't re-synched as often as position is calculated. The internal clock in the receiver allows the receiver to carry on tracking with only three time sources for a while.

But, to be clear on the topic of the parent discussion: I believe JDAM missiles (the ones that actually do use GPS) _do_ have either an atomic clock source [more recently], or [formerly] have at least a high-precision monotonic clock source with low drift that is synchronized at point-of-launch by the clock on the bomber, which also has an HPC that was calibrated at _its_ launch by a real atomic clock. They don't need to rely on external time-sync.

And modern ICBMs? Well, unless your jammer/spoofer can keep up with them, or is itself a satellite, you're only going to be able to affect them when they're on their descent course and making final adjustments. And, like this article says ([https://www.technologyreview.com/s/423363/how-cruise- missile...](https://www.technologyreview.com/s/423363/how-cruise-missiles- would-beat-gps-jammers-in-libya/)), ICBMs have redundant aiming systems based on computer vision applied to either visual-spectrum or radar-based sensors.

<comment><USER11> Your final point conflates icbms with cruise missiles - very different things. I don't believe icbms use TERCOM or visual matching.

<comment><USER6> Nor they use GPS for that matter. ICBMs are completely inertial.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I experienced a very odd GPS failures about a week later (September 24) in south-eastern Sweden. At one point I was driving for about an hour (in quite isolated areas - <USER2> [https://email@example.com,16.2094966,13.37z](https://firstname.lastname@example.com,16.2094966,13.37z)) without my iphone being able to get a gps fix. It's never happened before, or since.

The phone was fixed to the car's front window with plenty of sight towards the sky. I rebooted the device twice but it didn't help.

Our natural instinct here is to blame the russians for these kinds of things. At this time our biggest military exercise since the 90s was taking place in this region, with a lot of US involvement: [https://en.wikipedia.org/wiki/Aurora_17](https://en.wikipedia.org/wiki/Aurora_17)

(One random theory: the russians were trying out some kind of remote, localized target GPS jamming tech. The GPS outage stopped once I got closer to the largest city in the region (150k people).

Additional rationale: If they unleashed GPS jamming signals that made hundreds of thousands of people lose GPS it would probably have made news. By localizing it to just affecting a couple of hundred people in isolated areas they would avoid that kind of mess.)

<comment><USER13> I would assume the US/NATO also jams GPS/use some sort of scrambler for the unencrypted signal to have some military advantage...

<comment><USER14> I think the US military uses a different GPS signal that provides higher accuracy positioning.

<comment><USER15> The feature is called "Selective Availability", and has been disabled since May 2000.

[https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_...](https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System#Selective_availability)

<comment><USER14> So are you saying that the US military does not have a higher accuracy positioning system? I highly doubt that.

<comment><USER15> There are well-known ways to improve GPS accuracy, such as dGPS [1], inertial guidance, and beam-riding [2].

I think it unlikely that the US military has a secret second constellation of GPS-like satellites, operating on an undetectable secret frequency. Firstly, it would be difficult to launch and operate such a constellation in secret, and secondly, because augmenting the GPS data with independent, secondary sources operating with a different approach provides more redundancy and is proven technique for increasing accuracy.

The capability to limit accuracy in the satellite signal already existed – the fact that it was shut off is a strong signal that the perceived benefit is no longer important.

[1] [https://en.wikipedia.org/wiki/Differential_GPS](https://en.wikipedia.org/wiki/Differential_GPS) [2] [https://en.wikipedia.org/wiki/Beam_riding](https://en.wikipedia.org/wiki/Beam_riding)

</comment></comment></comment></comment></comment></comment><comment><USER16> There's was also some cellphone outage reported in Baltic

[https://www.washingtonpost.com/world/europe/latvias- cellphon...](https://www.washingtonpost.com/world/europe/latvias-cellphones- stopped-working-russias-war-games-may-be-to- blame/2017/10/05/449162d4-a9d3-11e7-9a98-07140d2eed02_story.html?utm_term=.9a11a75a4095)

</comment><comment><USER17> I don't see the assumption of the cause in the PDF (difficult to read on this tiny mobile device).

Could it be iron ore or something else affecting the magnetic fields? Does this happen elsewhere on earth?

<comment><USER18> Seems unlikely to be a natural phenomenon, considering it's never been noticed before.

Could be the Russians are up to something? Jamming GPS signals would be a significant strategic advantage in war time.

<comment><USER19> It's bad if you relly on one and only system. As there is NAVSTAR GPS, Glonass and Galileo you'll have to jam your own system too.

<comment><USER20> GPS and Galileo use the same frequency for their public service. Jamming one gets them both.

Glonass is a couple hundred megaherz away from GPS L1.

<comment><USER19> So there is no reason NOT to support Glonass.

<comment><USER21> Except the Russians run and control it and may consider opportunities to weaponize it offensively against unsuspecting Western users.

The best bet is to use as many positing systems as possible in order to prevent attacks narrowly targeting one positioning system.

<comment><USER19> The same can be said to NAVSTAR GPS. The only system which is not primarly built for military uses is Galileo.

Yes, that's what I am saying. Don't rely on one system. Using more also increases accuracy.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Would be interesting to see if this shows up in GPS occultation data.

</comment><comment><USER23> There was massive solar flare activity in September which may (or may not) have something to do with this.

<comment><USER24> It is the rare natural phenomenon that can make 1 MHz-wide bandstopped white noise, centered exactly on a human-chosen navigational frequency of import.</comment></comment>


Mill CPU Inter-Process Communication - <AUTHOR> https://millcomputing.com/topic/inter-process-communication/ <comment><USER2> Overall, this seems like one of the weaker Mill talks. Since they apparently don't yet have a real OS running real software in simulation, they probably haven't had the ability to test the ideas that affect how software is structured at a higher level.

They don't provide nearly enough ways to transitively grant permissions. Using the mechanisms discussed in the talk, it doesn't seem like you can implement a simple asynchronous queue of units of work to perform, each having their own permissions. The belt architecture encourages these sorts of second-class mechanisms that have to be used in a rigid way, because the details can be hidden in the belt and not be exposed architecturally.

Unless there's something else not mentioned in the talk, it seems like you still need to trust the OS, because when the OS is asked to allocate a page for a spillet there is nothing stopping it from creating a virtual alias of that page elsewhere and allowing another thread to read its data.

The mechanism to support fork() is a total kludge. Why have a single address space if you're just going to add segmentation in such an ad-hoc way for a single use case? Just run the original binary in emulation until exec() or something like that.

<comment><USER3> the fork exposition was weak. admittedly fork() was a mistake and constrains alot of implementations in strange ways. i still dont understand how local/global exactly matches the semantics of cow.

transitive permissions are capabilities.

while i'm sympathetic to the lack of market appeal to a capability based system, doesn't it seem like you could implement posix on top of one by compromising it? fd transfer over unix domain is already halfway there.

seems like a better alternative.

<comment><USER4> > i still dont understand how local/global exactly matches the semantics of > cow.

It's not, it's "copy on reference".

<comment><USER2> They were light on the details, but what stops an OS from mapping the same physical page into two distinct local regions of the address space and implementing copy-on-write as usual?

<comment><USER4> Presumably nothing, but it doesn't seem like that would break anything?

</comment></comment></comment></comment></comment><comment><USER5> The Mill design is fascinating because it is genuinely very different to anything else. But it seems that the entire team might die from old age before they actually have any working silicon produced. Which would be a shame.

<comment><USER6> They aren't trying to produce silicon, they are trying to produce patents.

<comment> racer-v The goal of their first funding round was to create a patent portfolio; the second is earmarked for an FPGA implementation. Hard to do it the other way around, although to be honest FPGA dev kits are so cheap these days I don't know why this requires a funding round.

<comment><USER7> Depends on the size of the chip you are trying to model, once your chip exceeds a certain level of complexity FPGA modeling can get expensive really quickly.

[http://chipdesignmag.com/images/idesign/fpga/figure1.jpg](http://chipdesignmag.com/images/idesign/fpga/figure1.jpg)

And such don't come cheap.

<comment> racer-v I suppose at $10K each, buying enough Altera Stratix 10 boards for the team could start to add up.

</comment></comment></comment></comment></comment><comment><USER8> Looking around the Mill Computing, Inc website, this feels like an (accidental?) sweat equity scam. I realize that is a very loaded charge, but this is NOT how real companies are run: "In the beginning we were a sweat equity organization; no one received a salary; instead, contributors received units that converted to stock when we incorporated. At incorporation 45 people had worked on the Mill and became shareholders. After incorporation we are still a sweat equity organization; we now use a stock option system for sweat equity, and we still pay no salaries. Reward for work today is comparable to what it was before incorporation."

I was involved in something similar around 10 years ago where we were working on a revolutionary EDA suite for analog and mixed signal circuit design. The owner was quite technically competent but kept upping the ante and theatrics to the point that no customers or suitors took the company seriously, only the desperate employees. They never closed sales nor sold the IP.

I advise extreme caution in dealing with the business side of this.

<comment><USER9> I understand the sentiment but the wording is indeed too loaded. A scam would mean the scammer gains a benefit.

<comment><USER10> Drinking the sweat of your workers like a vampire drinks blood?

<comment><USER11> That's really more the VC model; a bootstrap is different.

</comment></comment></comment></comment><comment><USER12> On a regular basis Mill pops up here and generates some interest, I just can't understand why.

They haven't produced an FPGA proof of concept, after claiming they would have one ready last year. They now say they need investors to finish it, yet they previously claimed to not even be looking for funding.

They claim to have angel investors, but they are all secret ones. Of course it's an investors right to stay private, but the reason you often see investors and companies shouting from roof tops is because the funding event itself can help a company. Publicizing it generates PR, gives the company credibility in dealing with other companies, and is a signal that can generate demand for more investors.

Even putting that aside, the biggest issue is they haven't made a compelling case for how their ideas will outperform existing CPUs in practical usage scenarios. Yes a running FPGA would be nice, that's not the only way to show potential.

They could do quantitative analysis, modeling, or start adding a lot more detail to their talks and papers (which tend to sound about as deep as you get in an undergrad architecture classroom), and argue very specifically and comparatively against today's standards, even for just a few key scenarios.

Maybe they believe even those ways would still have capital/labor/opportunity costs that are prohibitive or for a startup? Another option could be small meetings with a few well respected hardware architects, who will have the best chance of understanding the potential value. Once convinced, they will probably be glad to write about it or just provide a reference, which will make funding, partnerships, hiring, etc all easier.

I dislike being critical of people swinging for the fences, because it's what many of us here are trying to do, and it's important that people keep doing it. However in this case it's not just about long odds. Because of the reasons above and a few other details, things just don't add up. I don't believe the FPGA will ever demonstrate anything compelling, and don't think any investor in their own backyard on sand hill road will bite.

It's all conjecture of course, I'd be happy to be proven wrong.

<comment><USER13> You brought up the question of why people are interested in the mill and then discussed the question of whether the mill is viable. They're not completely unrelated but still distinct.

Being a software guy I can't say much about the viability. Watching Ivan's lectures and thinking it over however tickles the same part of my brain that enjoys learning a new programming language. It is just fun to see how some problem could be solved differently.

<comment><USER12> that's a good point - i would agree that's a very natural and healthy viewpoint yet has nothing to do with the startup aspect.

</comment></comment></comment><comment><USER3> watching the talk. does he not compare this to a classic segment/call gate architecture because he doesn't expect it to be a familiar reference? i'm certain he's seen it before :)

edit: i thought they managed to do all of this without segments, but at the end we hear about a special local segment with offset addressing apparently introduced just to handle children of fork()..i lost how cow can be expressed losslessly as local/global

redit: question around 1:00:00 explicitly ask this question, and he said, erroneously i think that while semantically similar this is the first time a direct hardware implementation of a call gate has been proposed

<comment><USER14> I can think of a couple systems with hardware call gates

He also doesn't mention the word 'capability' anywhere either - this is all 1980s stuff

<comment><USER15> Ivan definitely mentioned capabilities at some point in the evening - "I'd love to build a capability architecture but I wouldn't be able to sell it" (which he's also mentioned in previous talks) but it may have been after the camera stopped rolling.

<comment><USER4> He does say that, but if you watch previous talks (either that or the material available) he says the primary difference (IIRC) is that you aren't supposed to segment individual data objects, but rather instead coarse grained address space segmentation, so there's really no technical difference, but it's kind of an usage difference.

<comment><USER3> i think the other (turf-like) segmentation strategy is pretty common in earlier work. i wonder about the relative efficacy from a VM implementation standpoint. particularily wrt grant/revoke on a byte range rather than a segment.

the other thing that struck me as really strange was a bit in the question period where he says that 'smart devices' (DMA?) are different from simple devices (pio?) in that they are expected to be first-class multiprocessing citizens. doesn't that imply that high-performance peripherals need to be specially designed for the Mill? (likely with a Mill core attached)

<comment><USER16> Wrt smart peripherals, probably all it means is that you need an IOMMU if you don't want to have to trust your drivers.

<comment><USER11> We have focused on the core and less on the uncore, which is why there have been no talks on I/O. The goal is for a smart peripheral to be indistinguishable from just another regular core; the Mill design is big on regularity. That implies that it has its own PLB and TLB, responds to HEYU, and supports the same IPC mechanisms, both those in the talk and those NYF.

Of course, modern peripherals don't look like that, so there will be adaptors. IBM 360 channels and CDC6600 PPs also haven't been architecturally revisited in a while.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> Of all of the Mill subjects, the pointer kludge to support fork (itself a kludge, yes) seems to me to be the biggest offender of the "sufficiently smart compiler" red flag.

I just have a sinking feeling about hoping a compiler can correctly identify and track all pointers to know how to flag them. The "pointer is a native- word-sized int" assumption may be so ingrained -- from compilers to stdlibs to the wide variety and age of programs -- that it will be nigh impossible to rid existing codebases of it completely.

But I'm _not_ a compiler guy (or hardware, or assembly, or C for that matter) so I could be quite mistaken. Perhaps it's enough to fix the compiler and make it capable of emitting warnings/errors when it detects a violation.

As far as the talk itself goes, I'm a little sad that there was so little new information though I understand that we're quite deep in the technical details and there's a lot of prerequisite background that you can't reasonably expect from a random tech audience. If there are more than a few more talks you might need to reevaluate this method altogether and use a different format.

I'm very glad that you've decided to change the wording to refer to it as an "SSA machine" as opposed to "belt". I think many more people are familiar with SSA or can be convinced that it works ("your current compiler uses it _right now_ " probably helps) by describing it as "SSA where you can only reference the last N results" as opposed to building a whole model based on a "conceptual giant shift register" from before. I've been following the Mill talks since the first few videos and recently I wonder if even the asm programming model should be writing raw SSA instead of belt numbers, especially since genasm assumes an infinite belt anyways.

</comment><comment><USER16> Unrelated to protection: Ivan mentioned that this is an SSA-like architecture.

How does the compiler implement PHIs connecting expressions with different latencies? Let's say I have:

`if (cond) { x = a + b; } else { x = a * b; }`

The MUL is may take a bit longer than the ADD, but the user needs to accept the argument at a given belt position. How do you avoid having the pay the latency cost for the MUL if `cond` is usually true?

<comment><USER11> The tool chain does hoisting and if-conversion with wild abandon. That code becomes {x = cond ? a+b : a*b}, and both expressions are evaluated in parallel. The conversion is a heuristic; if you have tracing data for the branch then it might not convert. However, a miss-predict is a lot more expensive than a multiply so the tracing has to be pretty skewed to be worth the branch.

The conversion does increase the latency of getting the value of x. If there's nothing else to do then the tool chain will insert explicit nops to wait for the expression. The same stalls will exist on other architectures for the same code, just not visibly in the code. It happens that making the nops explicit is faster than a stall; you can idle through a nop with no added overhead, but you can't restart a stall instantaneously.

</comment></comment><comment><USER18> Just wanted to say, it's always a real treat to watch Mill talks, and I thank Ivan for putting in the hard work of making them so good! (The negativity I see here on HN really disappoints me).

Also, is the thread talk close at hand? I feel I learned less from this talk than usual; most of the material was already discussed in the security talk.

</comment><comment><USER19> The emperor has no clothes. The guy who claims to have written 12 compilers hasn't turned out one in a decade. How are microarchitectural decisions being driven without a compiler?

</comment><comment><USER20> I like the idea behind Mill, and the openness of the talks, etc. That said, it's been a -very- long time without so much as a real demo. What gives?

</comment><comment><USER16> I wonder how the PLB can be fast. You have a dictionary from byte range to permission. This is harder than TLBs, which map a relatively large granule where you can form a search key by just extracting the top bits from the virtual address.

Intel MPX has a similar protection model, and that introduces a lot of overhead (of course it is bolted onto an existing arch and it wasn't a high priority feature).

<comment><USER21> The protection entries have ranges. The bounds are in bytes, but the range can be _massive_.

Imagine you load a 7MP image which takes, say, 21MB of RAM. That would be 5184 4K pages in a classic TLB. In the Mill's PLB, that whole part of the address space can be in a single protection entry.

Then, there's a big difference from how things can be organised in software vs hardware. The hardware PLB has some number of entries, and it will check _all_ those entries _in parallel_.

<comment><USER16> Yes, you will have a CAM, but the CAM for a PLB would likely be more expensive than a TLB, right? And today's TLBs are only a few hundred entries for the first level. The PLB would seem to necessitate many cycles for a load, longer cycle times, or a high power CAM. Even if you could make address queries quickly by replicating ranges based on some graularity, invalidating the PLB becomes expensive on a grant revocation.

I understand that Itanium was forced into a low frequency, high power L1 cache by being at a similar in order statically scheduled design point, where you need loads to be fast in order for a compiler to be able to come up with a reasonable static schedule. Unless there's some really nice idea out there that's radically different from TLBs as they are today, I bet PLBs will be the major limiter of performance for general purpose code.

<comment><USER21> Each protection entry is has a lower and upper bound. The entry can cover something as small as a single byte, or as big as the whole address space or anything inbetween.

It is just a normal bounds compare to see if each entry covers the access, and the PLB has as long as the top-level cache access takes to do the checks.

So the PLB misses far far less often than a conventional TLB.

<comment><USER22> TLBs index a tag with the higher bits and compare one retrieved value for equality only. A PLB with arbitrary resolution would need to do 2 subtractions for the 2 compares and do that for all active entries in parallel. That is, for every simple load/store in a 16 entry PLB you'd need to do 32 subtractions! Unless you come up with a novel scheme to handle this your chip will get hot. Maybe you can reconstruct the indexing TLB scheme on the fly in hardware or something like that, or have an special purpose embedded Cortex-M3 that recreates an efficient lookup structure for the MILL :-). And no, a 64 bit subtraction is not one clock cycle when you run at 1ghz.

<comment><USER21> The entry contains an upper and lower bound, and requires two comparisons but no subtractions.

</comment></comment></comment></comment></comment></comment><comment><USER23> I work with a lot of OO code (ORM) that regularly contains references on objects to other objects. How would that "security model" behave wrt the map of reachable objects in relation to the object passed... let's assume by reference. I figure this scenario would be somewhat similar to the problem of "/.." paths in URLs on web servers.

<comment><USER11> The grant model requires you to grant each object individually that you want to pass. That is annoying if you have many objects. In both the caps and grant models you can cut the overhead by thinking of the whole graph as "the object". A typical approach is to allocate graph nodes in an arena and pass the whole arena.

Fine granularity is expensive, which is why the monoliths have one process- granularity. If you have 100,000 graph nodes and want to pass all of them _except_ this one then you will have to pay for the privilege, in any protection model. The Mill lets you pay less.

</comment></comment><comment><USER24> Is this mill architecture going to hit the market anytime soon?</comment>


Microsoft designs smart bra to combat emotional eating - <AUTHOR> http://arstechnica.com/science/2013/12/microsoft-designs-smart-bra-to-combat-emotional-eating/ <comment><USER2> Sorry about off-topic, but if there was ever a real title that I would have thought came from the headline generator of last week, this has got to be it!

</comment><comment><USER3> Actual paper is pretty interesting: [http://www.cs.rochester.edu/hci/pubs/pdfs/FoodMood.pdf](http://www.cs.rochester.edu/hci/pubs/pdfs/FoodMood.pdf)

</comment><comment><USER4> In case anyone didn't make it to the last paragraph, the bra device was a previous iteration. They have moved toward bracelets suitable for everyone. (Well, everyone with hands.)

> Since conducting this research, the team has moved to testing the use of > Affectiva Q3 bracelets, which detect mood, so that both men and women can > participate. The pilots, say the authors, have been "quite promising" for > both sexes.

<comment><USER5> Looks like the Affectiva Q sensor is discontinued and the company said they're moving away from that into facial tracking instead. How does the Q3 come into play then?

Discontinued site: [http://www.qsensortech.com/](http://www.qsensortech.com/) Press Release: [http://www.affdex.com/news-article/affectiva-accelerates- inv...](http://www.affdex.com/news-article/affectiva-accelerates-investments- in-affdex-emotion-measurement-discontinues-q-sensor-device/)

</comment></comment><comment><USER6> This has such tremendous potential. So much of our lives are ruled by habits, and who here doesn't have habits they want to break or new, better habits they want to develop?

Imagine if this could notice your boredom behaviors and prompt you to work out or study, if it gave you a solid reminder when you were watching more TV than you thought was useful, etc. Even if it noticed when you'd been sitting for more than an hour and prompted you to get up and stretch.

That would be fucking awesome.

</comment><comment><USER7> 1\. Electrodermal Activity Sensor 2\. Electrocardiogram Sensor

So, we can rest assured that the embedded system and controller board will be equipped with software that defaults to an always-upload mode, dumping all data to microsoft.com. The device will be completely unusable and it's data inaccesible without a one-time prompt agreeing to the EULA.

Is Microsoft trying to convince women to submit to continuous lie detector monitoring, under the auspices of weight control?

<comment><USER8> >rest assured that the embedded system and controller board will be equipped with software that defaults to an always-upload mode, dumping all data to microsoft.com ... Is Microsoft trying to convince women to submit to continuous lie detector monitoring, under the auspices of weight control?

What? I get it, its in fashion to hate on MS but come on these are just ridiculous assumptions. Let's look at it from a technical point of view. If you want an always-upload device, at the current state it would require a substantially battery which needs to be recharged atleast every 12hours. Now who will buy a heavy bra that fails in half a day?

Lie detector.. really? because its in the evil interest of a corporation to know when only women are lying.

<comment><USER7> It needs a battery no matter what. It assuredly has a battery. How would it function at all without a battery small enough to power a wrist watch?

How much battery power do you need, in order to pipe readings from a sensor into a tiny 2GB cache of flash memory?

Then, the data syncs with your laptop, because how else will you find out what the readings are, without some kind of GUI interface showing you some charts and graphs that interpret the raw sensor data?

The sync software will come bundled with a "share your data, oh goody!" feature that defaults to constant sharing mode (dark pattern). You charge the battery whenever you sync. In the presence of an internet connection, it uplinks to MsSmartBra.com, where data is monitored and tracked so everyone knows your high score! Yay!

<comment><USER8> Wait so you changed your course of comment from "always-upload" and "lie- detector" to "syncs to a central server" when plugged in? Then how is this different than existing products such as Nike fuel band or fit bit?

My initial response was to your paranoic bit on being always on. Without the help of a median device, for data to be always uploaded or for constant lie detection, a wifi/4g module has to used. Which in itself is a battery sucker and not to mention, adds to weight of the bra making it uncomfortable.

<comment><USER7> Okay, my mistake in using the term "always-on." That term is generally reserved for broadband network connections.

But consider the standard use case for undergarments. It will continuously collect data any time it's worn. That could turn out to be a lot of data, even in a store-and-forward data collection strategy. And really, bras are most commonly worn in social situations, so most data will be collected while the subject engages in social interactions.

I point this out as a possible "lie detector" because that's my immediate association with respect to electrodermal and EKG sensors used in combination. Add in respiration (a small leap since this will be strapped to your rib cage) and you would have the complete recipe for a lie detector. That part doesn't seem to be included, although my free association still stands.

I'm hypothesizing that Microsoft might be taking aim at a strategy to crowdsource ambient lie detector data, because that sounds like a really interesting data set, with lots of opportunities for exploitation.

What motivation could there possibly be, beyond "pure evil", as a drive to study this sort of thing? Perhaps a sense of adventure and bold curiosity for the future that lies ahead? I dunno, but it's already well established that Microsoft is a known collaborator with the DoD and most alphabet agencies. Maybe it's a sureptitious fishing expedition?

Why women only? Because a complete lie detector session involves respiration. So, if it's a sureptitious data collection program, you start with the question: how do we convince people to adorn themselves with cumbersome blood pressure cuff, EKG, electrodermal and respiration sensors that we usually wrap around their chest? Who would ever wear anything tightly strapped around their chest? Wait! Women do that all the time, whenever they wear a bra!

Good work, Johnson! Here's a two million dollar budget! In six months, be ready to show me something that will convince people to willingly share respiration, heart rate, and skin conductivity via the web. Then we'll restrospectivly analyze the raw data set, blindly without context, and try to pick out the liars, and develop a common statistical model of deceptive behavior, ironically collected using deceptive tactics.

</comment></comment></comment></comment></comment><comment><USER9> That's awesome! Can men wear it, too?

</comment><comment><USER10> Cmon people, this is pretty sad. Humans are not robots and shouldn't be treated as such. What's next? A pair of underwear to stop men from impulsive sex? We have a soul, a spirit. Find the real reason why you harm yourself and emancipate that in a spiritual way .. not an electronic bra.

<comment><USER11> First - humans ARE robots and have no soul/spirit, second - you should not treat non-human with disrespect just because it was of another species. Animals have feelings just like you, and in the future an actual mechanical robots might too. Would you still treat AI as it was "a thing", although it could feel, understand and act just like any human being? Because if so, you should treat every human being as thing too.

<comment><USER12> _> > First - humans ARE robots and have no soul/spirit_

I very strongly disagree with this, but I know on HN this makes me an absurd fool with no data to back myself up with. Ya know, on my myers briggs[1] test that took last year, and also about 20+ yrs ago when I was in highschool the results were the same. I have a strong sense of spiritualness and connectedness. I'll link this blog[2] but I suspect its contents will be dismissed around here as unscientific baseless nonsense. Not trying to change anyone's mind here, just showing how I feel. Maybe some readers will better understand the other people in the world, like myself, who don't think like vulcans[3].

1\. [http://en.wikipedia.org/wiki/Myers- Briggs_Type_Indicator](http://en.wikipedia.org/wiki/Myers- Briggs_Type_Indicator)

2\. [https://findingourwayhomeblog.wordpress.com/tag/myers- briggs...](https://findingourwayhomeblog.wordpress.com/tag/myers-briggs-type- indicator/)

3\. [http://en.wikipedia.org/wiki/Vulcan_(Star_Trek)](http://en.wikipedia.org/wiki/Vulcan_\(Star_Trek\))

<comment><USER11> Regarding the MBTI test, take it with a grain of salt.

As for spirituality, if it is how you feel, it's nothing wrong. The way human body functions is not a matter of agreement between people anyway.

Also being reasonable and logical doesn't automatically make you emotionless.

</comment></comment></comment></comment><comment><USER13> Thank goodness for HN to keep us abreast of these developments.

</comment><comment><USER14> always nice to see innovation in the over-the-shoulder-boulder-holder space

</comment><comment><USER15> Breast tissue is very sensitive, not sure electronics "permanently" being there is a great idea. And please don't downvote me just because you don't believe this could lead to higher rates of cancer - it's still not fully known and should be considered a valid concern. EDIT: A number of spiteful and/or lazy people on HN eh?

<comment><USER16> Females, at least where I'm from, regularly keep things in their bra such as cell phones. It never ceases to amaze me when a phone suddenly materializes from seemingly nowhere. Given that I feel they would hardly be opposed to some thin embedded electronics in the bra.

<comment><USER15> Yes, I have seen this too. I'm sure they're not aware of or perhaps don't believe the studies showing that there's increased cancer around the area where heavy cellphone use it as. Sure, you can argue they're not using the phone - however phones more and more actively push and receive data.

<comment><USER17> Citation badly needed. There have been many studies on this and, as far as I'm aware, not one has shown such a link.

<comment><USER15> I have to head out now - this was nearest I could find at the moment - [http://www.spandidos-publications.com/ijo/43/6/1833](http://www.spandidos- publications.com/ijo/43/6/1833) \- if clicking "View Affiliations" you can see where study was done, who's involved, and could do more searches. The study's conclusion is 70% increased in certain cancers if used 1 year or longer, and 300% increase if 25 years or longer (cordless and cellphone) - though not many participants had used cell or cordless phones for 20-25 years.

<comment><USER17> So, I just read over the paper, and the biggest thing that stands out to me is: it's completely backwards, methodology-wise. They start from tumors, then work backwards to collect data about their mobile phone usage, and compare them to a control that is selected from a comparable population. I'm sorry, but that's _not_ good science. Read over the "Materials and methods" section.

It also has a remarkably low sample size (n=593). This is in contrast to the Interphone study (n=~14000), which found no statistically significant correlation between brain cancer and cell phone usage.

<comment><USER15> Seriously? This is how many studies are done, unless you can have a highly controlled environment say with breeded rat populations. And yup, wouldn't it be great to keep track of absolutely everyone - and then see how they progress? The problem is most of us are bombarded with a lot of pollution (not just electrical), which all will affect our body's ability to cope with dis- ease and sickness.

I'm not sure where you're getting the sample size of 14,000 ... though different pieces of the study had upwards of 5,000 participants.

<comment><USER17> This is indeed how many studies are done. It's also why many studies are 1) completely worthless, and 2) impossible to reproduce.

This is simply not valid science. It's not blinded, it's not representative of the population at large (or these would've come out of a randomly selected population), and it's not properly controlled. It's junk science.

<comment><USER15> So you believe it's completely useless and no value to take 1 common factor, and see what other common factors exist or vary from others who don't have that common factor?

<comment><USER18> Go read "bad science", then come back and answer your own question. :)

<comment><USER15> I hope the book itself doesn't make such as generalized claims as some of the sections of the Wikipedia page describing its sections..

I will add it to my read list though, thanks.

<comment><USER18> I found it very elaborate, actually. It's certainly a very good read :)</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Belgian gambling commission investigates Star Wars Battlefront - <AUTHOR> article (https://nieuws.vtm.be/binnenland/onderzoek-naar-nieuw-star-wars-spel) in dutch, translated:
The commission is opening an investigation into the new Star Wars: Battlefront 2 game. In that game you can pay to improve your character or vehicle. The mechanism is based on chance; you don't know up front what you'll get. Overwatch is also under investigation.
The game will be in store next Friday and is seen as one of the largest releases this year. In the game, you can improve your character and obtain things like weapons or vehicles.
Those without time to play can buy the improvements also with "Loot Crates". those are virtual boxes that are bought without knowing up front what's inside.
And that's the problem, claims the Gambling Commission. Because you want certain items but don't know what you'll be getting when bought, it's a form of gambling. Such activities are under the purview of the Commission, according to Naessens, director of the Commission.
The Commission claims it's a danger especially to the underage, who may feel socially pressured to spend a lot of money. That's why they're starting the investigation. "Games of chance are regulated by the commission", explains Naessens.
In worst case, EA may have to pay 100k fines or the game may be banned. EA has not responded so far. <comment><USER2> There's a few more they could start looking into also.</comment>


Ask HN: Help me understand online payment gateways - pcidss-clueless I'm a long time developer that's recently moved into web development. I'm also based in the UK, so that seems to limit my options somewhat significantly.
As I understand it, my options are either speak to my bank about a internet merchant account, or use a third-party payment processor. It seems however, that if my company is newly formed and thus doesn't really have a trading history, the likelyhood of my bank allowing me to have an internet merchant account is slim. Using a third-party payment processor usually - from what I can see - results in customers being redirected to a third-party branded checkout page, which I want to avoid. Is this correct, or am I missing something?
If I have a merchant account and people are submitting payment data to my server that I am then passing on to be processed, I am responsible for PCI DSS compliance, correct? (Am I correct in my understanding that Braintree gets around this by having your checkout form POST to their servers?)
Lastly, can anyone recommend a means for me to accept credit and debit card payments [in pounds Sterling, for a UK site] for a newly formed business that doesn't use a third-party [Paypal, Google Checkout etc]? <comment><AUTHOR> I recently launched a niche startup selling addon content for Photoshop. It's a purely digital-goods business: people pay money and in return they get an email with a download link.

I looked at a bunch of solutions (shopify, 2checkout, paypal, authorize.net, e-junkie, and others). Ultimately, I went with a company called FastSpring. It's a third party shopping cart solution, but they let you use your own xhtml/css template. They do include some text in the footer to let you know who's providing the service, but it's not really intrusive.

If you want to see how it looks, here's a page from my site. Click the add-to- cart button: <http://photoshoplayerstyles.com/sale>

Overall, I really like their service. They pay out twice a month, directly into my bank account. I'm in Canada, and most places just won't do this, so it was a nice surprise when it just worked.

Edit: I should mention, they handle international sales smoothly, too. I've had sales from all over the EU. They detect the country, do currency conversion, charge the correct VAT, etc.

<comment><USER2> Offtopic, I remember seeing this when you announced it. How's the site going?

<comment><AUTHOR> Not bad. It paid my rent this month.

Conversion rates are good, but getting links and traffic has been difficult. If I could move the site up from #7 to #1 for my domain keywords on Google, I'd be very happy.

<comment><USER3> Good Luck :)

</comment></comment></comment></comment><comment><USER4> We have had several different merchant accounts and bank accounts over the years, and have found that your bank is probably the last place from which you want to obtain a merchant account.

These days most businesses (online businesses, at least) obtain a merchant account through an Independent Sales Organization (ISO). The ISO is basically an independent sales rep for a Merchant Services Provider (MSP) associated with a bank. When your account is set up, the funds from your customer pass seamlessly through the MSP's bank and are deposited into your local bank account.

The ISO makes his/her money through fees on your account. The more sales you have, the more they earn.

Competition between ISOs is intense, so it pays to shop around. Every local bank I've dealt with "outsources" their merchant accounts to an ISO. I assume the bank receives referal income from the ISO, as the fees we've been quoted for a merchant account through a local bank have always been higher than we've found elsewhere.

A few months ago, we quit having our own merchant account and moved to PayPal, as basic interchange fees have increased to the point where we found that is the least expensive option for our level of sales (>$10,000/month).

We use a basic PayPal Website Payments Standard Account using their name-value pair (NVP) interface. Our customers enter their shipping address data on our web site and their credit card information on PayPal's web site so we don't have to worry about PCI compliance. We use custom headers on our order page ("Checkout: Step 1") and our PayPal page ("Checkout: Step 2") to make it look pretty seamless. You can upgrade to a Website Payments Pro account for $20/month if you want to do it all on your own server, however.

<comment><USER5> Just one small nit: Website Payments Pro was raised to $30/mo a little bit back. We used this for some time and it worked reasonably well, but there are other options that don't cost as much.

We use a combination of our own merchant account through a reseller and Authorize.net, which has about half the monthly fees of the PayPal option and lower rates.

</comment></comment><comment><USER6> It took us months to get a payment system for my start up in Australia. Its a nightmare. You are correct in thinking there are only two options - a merchant account or a service like paypal or authorize.net. However, if you have a merchant bank account and use a 3rd party gateway, you are submitting and storing the credit card information on the gateway and not on your own server, therefore PCI DSS complaince is not required. Many credit card gateways have APIs so that you can create a seamless experience if you wish. I would certainly try approaching the banks for a merchant account. Our company was fairly new when we got our merchant facility and there was never any concern about how old the business was. They were more interested in the type of product and thus the risk of getting charge backs. The bank may also be happy to provide the facility for a security deposit. Also, before you make a final decision, compare all the charges and how much the facility is going to cost your business. The charges seem to vary dramatically between banks and providers.

</comment><comment><USER7> (1) At least in the US, banks are only _one_ way of getting a merchant account. There are decent number of companies that offer merchant accounts. It is a pretty competitive business and there are plenty of companies and affiliates vying to get you under their belt because they get a fraction of a % of sales you do for life. Google around. Banks may not be the best option. In U.S you can definitely get a merchant account for new businesses with little history. I was able to get one at 15 under my brother's name--who was barely 18 and had no prior biz record.

(2) Yes, merchant account can help you avoid 3rd party pages and gives you complete control of the flow of the order process.

(3) Yes it is a bad, bad idea and mostly not officially acceptable to store cc info on your server.

<comment><USER8> Actually, in the UK, banks are pretty much the only way of getting a merchant account, see:

[http://www.businesslink.gov.uk/bdotg/action/detail?type=RESO...](http://www.businesslink.gov.uk/bdotg/action/detail?type=RESOURCES&itemId=1073791016&r.s=e&r.l1=1073858790&r.lc=en&r.l3=1073920405&r.l2=1073858942&r.i=1073791013&r.t=RESOURCES)

(sorry for shitty URL)

The only non-bank merchant accounts you can get are Amex & Diner's Card, both of which only work for their own cards.

<comment><USER9> He's referring to Independent Sales Organizations (ISOs), which are groups sponsored by acquiring banks to underwrite, provision and maintain merchants accounts for clients.

</comment></comment></comment><comment><USER10> You are responsible for the security of any information on your system. Thus you should want to be PCI DSS compliant even if it is not a requirement.

Take a look at PayPal Website Payments Pro.

[https://www.paypal-business.co.uk/process-online-payments- wi...](https://www.paypal-business.co.uk/process-online-payments-with- paypal/index.htm)

Why don't you want to use PayPal. Its a pretty safe path to start accepting payments online and you can use their transparent API so they are not visible. Get an account, read their API docs and security best practices for the language of your choice (and in general). Implement an example from the docs on your server and grow it from there. Don't store credit card data on your server and don't cut corners when checking integrity of communication between you and PayPal.

<comment><USER11> Paypal is expensive and I have had too many problems with them to ever consider using them for my business.

<comment><USER12> Also note that in general, keeping away dubious companies helps both your own reputation and the society as a whole.

And PayPal has gained a lot of bad reputation for several reasons. The Wikipedia provides a good summary of the issues: [http://en.wikipedia.org/wiki/PayPal#Criticism_and_limitation...](http://en.wikipedia.org/wiki/PayPal#Criticism_and_limitations)

</comment></comment></comment><comment><USER13> The easiest way for you to achieve PCI compliance is definitely by using a 3rd party gateway. Customers will have to leave your site but you can usually skin the gateway page to look like the original store. If credit card data is entered in a PCI compliant server, even in an iframe on your site, then you aren't responsible for making your server PCI compliant to accept credit cards.

</comment><comment><USER14> I did lots of research and finally settled with Payloadz ... visit <https://www.payloadz.com/default.asp>

Edit: they support PayPal, Google Checkout, 2Checkout, Amazon Payments and TrialPay - also you can use their system to create your own affiliate system/network.

</comment><comment><USER15> Can anyone make recommendations for merchant accounts in the US? Are there any that you would avoid? beanstream, authorize.net and Braintree all look pretty similiar, are there any real differences? Thank you!

</comment><comment><USER16> Self promotion here, but I suggest you check out <http://payfacade.com>. We're trying to make life of web developers easier regarding online payments.

</comment><comment><USER17> I highly recommend talking to Isaac and the team over at recurly.com (you can guess his email address (: )

Even if you don't end up using them you'll get some very valuable intel.

<comment><USER18> Off topic: I always wondered how to put a 'smiley' inside of brackets, I never considered making it face the other way around. Genius!

</comment></comment><comment><USER19> See also this previous thread on the topic: <http://news.ycombinator.com/item?id=1074860>

</comment><comment><USER20> Have you looked at 2 Checkout?

<http://www.2checkout.com/community/>

</comment><comment><USER21> What kind of bullshit banks in the uk wont give a business a merchant account?

Anyway, chargify can recommend you some gateway/merchant account providers.

<comment><USER22> From the text of his question it doesn't sound like he's actually asked yet.

I also read recently that chargify only works with Barclays in the UK, but I'd check that out yourself.

In other words, OP, you probably have more options than you realise, go talk to your bank's business advisor. Or a few banks. I mentioned to mine that I will want to do what you want to do in a few months and she didn't bat an eyelid, although I haven't yet pursued it.

Also, why post with a throwaway account? It's a perfectly good question, the whole area's fairly confusing at first!

</comment></comment><comment><USER23> You might find my free ecommerce cheat sheet helpful if you go the custom solution route (merch acct, cc processor, etc): <http://jumpstartcc.com>

<comment><USER24> Looks interesting, thanks. BTW the page says "2009", might want to bring it up to date.</comment></comment>


The Power Of A Picture - <AUTHOR> https://media.netflix.com/en/company-blog/the-power-of-a-picture <comment><USER2> I have just enough experience with marketing to be able to avoid images that are shit. All their loser images are shit. The author of the article is on the right path, faces full of emotions and cultural relatability is important. The best teasers (and snapshots are just the most minimalist teasers) make a promise to (1) tell a story that is (2) relevant to me and (3) fits my mood.

The problem with video snapshots is that everybody is so freaking good. We're spoiled by every random tube site doing image recognition and automatically A/B testing frames from videos and serving the most popular. Big budgets are spent on promoting movies and TV. So a lay analysis like this cannot possibly begin to scratch the surface.

</comment><comment><USER3> I'm confused as to why Netflix would need to A/B test their thumbnails. If people are browsing thumbnails, I think they would already be paying subscribers. Is there a business reason for doing this?

<comment><USER4> Help customers find content they like and keep them around. If you run out of content, why wouldn't you cancel your subscription?

</comment></comment><comment><USER5> Nice! A/B testing carried to its logical conclusion. I would not have thought of dynamically rating thumbnail images, but once I read the article, it was 'of course' they would do that.

</comment><comment><USER6> Netflix: 2016 and we still don't let you sort by rating or filter out media you've already seen.

<comment><USER7> Sorting by rating can be subjective, but it is odd that it doesn't hide things you've already seen.

There's even a 'Watch it again' category that is populated by things that you watched and rated highly.

<comment><USER6> There's nothing subjective about withholding the ability to sort/filter by ratings.

And it's obvious that users should be able to mark content as "watched" even if you didn't watch it on Netflix.

I generally like Netflix, but when I'm wading through 100s of movies and television programs that I've already seen, or that have 1 or 2 stars, my loyalty to Netflix is greatly diminished.

Meanwhile, they waste time and money on algorithmic recommendations that are, in my experience, almost completely useless. (And I've bothered to rate a lot of content in the hope of improving their recommendations, too.)

I want to turn on Netflix (or an alternative), hide all the watched content, hide everything below three stars, sort by highest-to-lowest rating. It's not difficult.

</comment></comment></comment><comment><USER8> So the "don't judge a book by it's cover" doesn't reach enough people these days.

<comment><USER9> Did it ever?</comment></comment>