Spotify GDPR data export: user receives 250MB containing every interaction - <AUTHOR> https://twitter.com/steipete/status/1025024813889478656 <comment><USER2> What grand times we live in, where you can actually get this kind of data from the services that you use.

Having the law say your personal data is owned by you and not some company just because it's on their server may turn out to be a landmark in consumer friendly legislation!

<comment><USER3> Frankly, I think a lot of this data isn't the users, but rather Spotify's. If Spotify didn't exist then the interaction data with it wouldn't exist. I don't see how it can possibly be "owned" only by the user here. Does a user "own" security footage in a store that they enter? Definitely not.

<comment><USER4> I'm upvoting and agree in the realistic point you are making, but feel this isn't the most popular point of view right now? I personally believe info just shouldn't be captured period, beyond reasons for authentication protection purposes/identifying malicious/off pattern use of my login/auth token. We are releasing a new business/info mgmt product soon that has no GA/full story/user tracking whatsoever. It's not clear why everyone enables a floodgate of tracking just 'cause. We are implementing better feedback/reporting channels instead.

<comment><USER5> One thing that people constantly praise Spotify for is the quality of their music recommendations. You can find so many testimonials of people saying that their "Discover Weekly" playlist suggested them songs which they felt they had been searching for their whole lives.

Needless to say, such accurate recommendations of music, which even close personal friends have trouble doing, is based on building as complete of a psychological profile of the user as possible. There wouldn't be any way to do it without gathering lots of information about your very personality.

Surveillance isn't always bad -- after all, what is a baby monitor?

<comment><USER6> At some level, I think one _should_ have privacy concerns with baby monitors ... did your baby choose to opt-in?

(Three kids here, and no, we never used a baby monitor...)

<comment><USER7> I hope the sarcasm is flying over my head here...

</comment></comment></comment></comment></comment></comment><comment><USER8> I enjoy the mental exercise of finding where boundaries lie.

For instance, if you simply observe the actions people take when they talk to you, that's obviously your observation. If you were to, say, journal it, it's still yours. It's a weird thing to do, but it's yours.

If you used the journal to optimize yourself, perhaps to make conversation with you more enjoyable, again, that's weird, but perhaps also merely a paper version of what already goes on inside your head.

What if talking to you were really enjoyable, so that while people could technically avoid it, they usually didn't want to?

At what magnitude does the volume of people you're observing reach a scale where the people you're observing start to believe your observations are theirs?

<comment><USER9> It's a huge difference when a company does it rather than an individual (as in your example).

<comment><USER8> It's a convenient difference, but I don't think it actually impacts anything.

It's an indirect way to address the level of resources you have at your disposal, which is itself only important for the scale at which you can capture the data.

In general, for the things people are OK with citizens doing but not OK with corporations doing, they mean an individual could not do it at a scale that bothers them. I'm specifically curious about what that scale is.

Certainly for me, there exists a hypothetical scale at which an individual gathering and recording detailed observations of other people becomes a little unsettling. Perhaps not criminal, but it falls into a "wish it didn't happen" bucket.

</comment></comment></comment><comment><USER10> Impressive-- [https://twitter.com/steipete/status/1025029133175336960](https://twitter.com/steipete/status/1025029133175336960)

"They even store the brand of headphone I use. How do you even get that data, digging deep in CoreBluetooth?"

<comment><USER11> If you think about it, now it makes sense why big names in smartphone industry like Apple and Samsung are removing P2 plugs from smartphones in favor of more powerful interfaces like Lighting/USB-C: so you can track more information about the user.

Just imagine: you can track which kind of phone a user that likes to listen to Heavy Metal, for example, likes to use, or which phone is more popular at the moment. Based on this you can develop phones that is more likely to sell or use specific marketing campaigns depending of the kind of music a person listen.

<comment><USER12> There's a much more mundane explanation - waterproofing. Lightning and USB-C connectors can both be made intrinsically waterproof up to IPx7, while the 3.5mm jack can't. Waterproofing is a key point of differentiation for recent flagship phones. An iPhone 7 will survive a dip in a toilet bowl or a pint of beer, but an iPhone 6 probably won't.

<comment><USER13> So all the other phone manufacturers selling IP68 phones with headphone jacks are lying?

<comment><USER14> I had a Xperia Z5 and every time water touched the headphone jack the phone would go crazy thinking that I was plugging and unplugging something repeatedly.

<comment><USER15> On the assumption that the phone itself is fine, that could be fixed in software.

</comment></comment></comment></comment></comment></comment><comment><USER16> It's kind of weird (and worrying tbh) that the user doesn't get _all_ the data by default. Shouldn't all the data be sent upon request, is there a clause saying 'only after nagging the TRUE data will be sent?

<comment><USER17> There's a sense in which summary views are the real data. If I asked Spotify to share my data, and they just sent me a 250 MB file of every interaction they've ever recorded, I would conclude they're trying to obfuscate which data they actually use and how they use it.

<comment><USER18> Yeah. If Netflix sends me every byte I've ever viewed, that's pretty useless.

<comment><USER19> Exhaustive list of your data (sorted, redundant copies not included):

0x00

0x01

0x02

0x03

...

0xFE

0xFF

<comment><USER20> I think just 0 and 1 would suffice ;)

</comment></comment></comment></comment></comment><comment><USER21> Here is a template for whoever else wants to request their data:

[https://www.dropbox.com/s/fx5yyrru1uvx6no/sarletter.txt?dl=0](https://www.dropbox.com/s/fx5yyrru1uvx6no/sarletter.txt?dl=0)

Source (@mikarv on Twitter):

[https://twitter.com/mikarv/status/1012386696934182912?ref_sr...](https://twitter.com/mikarv/status/1012386696934182912?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1013539192805064704&ref_url=http%3A%2F%2Fdancemusicnw.com%2Fspotify- gdpr-data-exports-user-tracking%2F)

</comment><comment><USER22> If Spotify didn't give you all data with your first request I guess that they are in breach of GDPR?

<comment><USER23> Yes, you would then have a basis to file complaint to your (within the EU) country's data privacy authority

</comment></comment><comment><USER24> Has anyone tried this request in the US? I'm assuming they would just tell you to politely shove it?

<comment><USER25> They are a Swedish company.

The British regulator considers the rules to apply to all people, not just European citizens, so I think the Swedish would have the same opinion.

In general, Europe has rights that apply to everyone, regardless of citizenship. This makes a difference when it comes to searches at the border, drone strikes, refugees and so on under the European Convention on Human Rights.

This should become a selling point for EU businesses.

</comment></comment><comment><USER26> Remember all of the data Winamp2 used to gather and send to third-party servers?

<comment><USER27> It's weird how perception on these things has shifted. So many practices are "normal" today which used to be clearly labeled "spyware" only 15 years ago. They successfully rebranded spyware, now it's called "telemetry", or similar.

Anyone remember the huge privacy-related outrage when Windows XP came out, because it forced users to do challenge-response activation? How times have changed...

<comment><USER28> It might just be that all those people have switched to free software and aren't being vocal because of that?

</comment></comment></comment><comment><USER29> While this is an extreme example, I'm not the least bit concerned about Spotify collecting this data. This data is likely used by Spotify to understand user behavior to improve user experience and improve their recommendation engine, or to simply understand how users interact with the app. I was delighted to find that Spotify sends you concert notifications of bands that I listened to the most. Personally, as long as they are not sharing this data with others without my permission they can collect this info. All of this is clearly stated in their privacy policy including the bit about Bluetooth) [https://www.spotify.com/is/legal/privacy-policy- update/#s5](https://www.spotify.com/is/legal/privacy-policy-update/#s5).

<comment><USER30> > "this enables us to access your GPS or Bluetooth to provide location-aware > functionality"

They only Bluetooth in the context of acquiring location data..

</comment></comment><comment> a-dub I have a friend that always used to joke that if Spotify ever failed and got sold off to private equity, they would shift to a business model where they mine for embarrassing music and behaviors and then extort people to keep quiet about it.

</comment><comment><USER31> I'd be interested in knowing if he is a paid subscriber or not.

I understand that Spotify needs data to power Discover Weekly, but I'm not sure I'm comfortable with this amount of data.

</comment><comment><USER32> This is great. I wonder if the EU can write a law to allow us to see what adverts are being served to which audiences on platforms like Facebook and Google. More transparency please.

</comment><comment><USER33> > Having the law say your personal data is owned by you and not some company > just because it's on their server may turn out to be a landmark in consumer > friendly legislation!

It's interesting to think where this goes in the future. Can I demand my purchase history from physical McDonalds restaurants at some point? Why limit it to internet-related interactions? (Or maybe this is already included in GDPR and I'm just not aware?)

<comment><USER25> You can already demand this data from McDonalds, if they retain it.

You've been able to for about 20 years, in some form with the previous laws.

(More commonly, you could demand the paper records your employer has about you.)

</comment></comment><comment><USER34> The main issue as i see it is that he did not get data when he asked. He had to complain.

</comment><comment><USER35> Man I was comfortable running spotify as the only non-free app on my Linux machines, now I'm not.

It's back to ocp and mods/classical music/occasional purchased for me I guess... (except on my phone of course which is a lost cause)

<comment><USER36> Why are you uncomfortable with Spotify now?

<comment><USER28> Because it's a piece of proprietary software?

</comment></comment></comment><comment><USER37> Is this data collected by Spotify, or __all__ data Spotify has for a user? That is, it's certainly possible for any given service to gather / aggregate data from sources other than itself.

</comment><comment><USER38> Has someone started a list of GDPR data export requests and their results? I wonder what interesting information is out there...

</comment><comment><USER39> Seems like CSV would've been a better format than JSON for this type of data based on the screenshots.

<comment><USER40> Indeed. Your typical data requester isn't going to know code for working with JSON. And converting JSON to CSV is a pain.

<comment><USER41> To be fair, GDPR stipulates only that it should be available in a common machine-readable format. It doesn't require the most convenient format conceivable.

Also, CSV can't easily handle nested objects. If the data model is even slightly more complex than a plain table, it doesn't make much sense. I'd also argue that even if the source data is stored in an RDMS without exotic data types, a JSON with a nested object representation is probably going to be more friendly even to non-developers than multiple files with opaque foreign keys linking back and forth.

<comment><USER40> Sure, simple JSON you can view in browsers.

But with CSV you can just use spreadsheets. Are there n00b-friendly apps based on R, Python, etc?

And can't you always convert JSON to multiple CSV files?

<comment><USER42> Only if you accept a potentially unlimited number of CSV files/sheets. Many forms of data aren't really easily normalizable to a limited number of flat tables without losing information.

<comment><USER40> OK, then. How would someone who's not technically sophisticated interpret such JSON?

I suppose that some service could handle it. But then there's another level of trust and GDPR compliance.

<comment><USER42> Open it in any decent plaintext editor/viewer, it'll likely have support for 'prettyprinting' json, and it'll be readable.

If you want to 'do stuff' with the data, then JSON is a very (IMHO most, but your mileage may vary) reasonable format; unless that data really is just a single flat table, it would be hard to blame them from picking this format.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> OK, I've been wondering if I could get this data. Now I want mine.

</comment><comment><USER44> If something is free, you are the product being sold...

</comment><comment><USER45> Meh you are the product spotify is free!

<comment><USER46> Spotify has over 70 million paid subscribers.

<comment><USER47> So they're paying to be tracked. Nice gig if you can get it, Spotify!

</comment></comment></comment><comment><USER46> Confusing title. I thought there was some horrible bug that sent a 250MB file every time you clicked something! After reading the tweet I realize it's saying the 250MB file _contains_ every interaction.

</comment><comment><USER48> Instead of "with", please use "containing" in the title.

<comment><USER49> Agreed. I couldn't understand why every single interaction would generate 250MB of data!</comment></comment>


Revery – Native, high-performance, cross-platform desktop apps - <AUTHOR> https://github.com/revery-ui/revery <comment><USER3> > Revery is the same - aside from platform-specific behavior, if your app > looks or behaves differently on another platform, that's a bug!

I want my applications to feel like they belong to the platform and _not_ identical on every platform

<comment><USER4> Of course that's a choice for everyone to make, but I feel like in general the benefit of fitting in the platform is overrated.

After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example. Another family of examples would be the big software packages like the Adobe or Autodesk stuff, they tend to have a fairly custom look&feel.

IMO it's probably sufficient for the thing to look "modern" (ie up to date wrt to UI fashion trends). Then you get the huge upside of easier maintenance and less bugs.

<comment><USER5> Non-native GUIs are probably the number one reason we've fallen so far behind in control over our UIs that "dark mode" is legitimately considered a feature.

It is absolutely ridiculous that, in 1995, I could completely change the font sizes and color scheme of my UI radically and it would work with the vast majority of applications, but in 2019 I have to wait for a developer to decide to add a theme or provide some kind of customization facility unique to their software.

<comment><USER6> In 1995 there were far fewer platforms than there are now, and most people only had one: their own computer.

Nowadays, we expect the same services to work on our laptop, our work computer, our personal iPhone, our work Android, our smart TV... the importance of parity between versions is much higher.

<comment><USER7> True, and also, the fact that apps have to work everywhere because everyone's either on Mac, Windows, Linux, or BSD. And also a lot of power users and people who except things to just work compared to the early days of the PC. Remember sound drivers?

</comment></comment></comment></comment></comment><comment><USER8> Well the example application seemed fairly solid, well worthy of a screenshot. I would like something like this for some simpler custom tools every now and then.

It does seem to exhibit the usual custom rendered app issues. I suppose it is constantly redrawing the screen, as it seems to have constant cpu usage even when doing nothing, so not laptop friendly (though perhaps fixable still).

Some of the widget seem fairly arcane but usable. No keyboard control that I could find. Screens that needed to scroll didn't. Text input is custom, so that will be a source of frustration for many for a long time (lack of cursor control, IME, etc.), likely fine for internal tools for a while.

One thing that was very alien to me was the build tooling and language/runtime. It was easy enough to run the example per the readme instructions, but it is quite hidden what kind is the end product. I eventually found an actual executable of around 4MB (3.3MB stripped), but I'm not quite sure how self-contained that is. Also how easy would it be to link C/Rust lib, so that revery would only be used as the UI layer for something else.

<comment><USER9> Hey scoopr! Thanks a lot for trying it out.

> It does seem to exhibit the usual custom rendered app issues. I suppose it > is constantly redrawing the screen, as it seems to have constant cpu usage > even when doing nothing, so not laptop friendly (though perhaps fixable > still).

Yes, at least when there is an animation active (we redraw the screen in that case). Most event-based apps, though, would only redraw in response to user input or for a temporary animation - our initial demo is constantly animating at 60hz, so maybe not the best performance demo...

> Some of the widget seem fairly arcane but usable.

Definitely. Still a lot of work needed here. We've had some excellent help from the community getting an initial palette of controls; but still a ways to go!

> One thing that was very alien to me was the build tooling and > language/runtime.

This is great feedback. We should include more details in our README about this. The stack is really Esy [1] -> Dune [2] -> OCaml compiler (ocamlopt) [3]. Then C linker for your platform.

> Also how easy would it be to link C/Rust lib, so that revery would only be > used as the UI layer for something else.

I haven't tried Rust, but C libs are doable with Reason/OCaml's C FFI [1]. In fact, several of the underlying pieces of technology powering Revery (GLFW, FreeType2, Harfbuzz) are used via this FFI [4].

[1] [https://esy.sh/](https://esy.sh/)

[2] [https://dune.readthedocs.io/en/latest/quick- start.html](https://dune.readthedocs.io/en/latest/quick-start.html)

[3] [https://caml.inria.fr/pub/docs/manual- ocaml/native.html](https://caml.inria.fr/pub/docs/manual-ocaml/native.html)

[4] [https://github.com/bryphe/reason-glfw](https://github.com/bryphe/reason- glfw)

</comment></comment><comment><USER10> > As a consequence, Revery is like flutter in that it does not use native > widgets.

This puts a step above Electron, but one below wxWidgets in my hierarchy of cross-platform desktop frameworks. It really annoys me when frameworks pretend they are "native" (to separate themselves from Electron) but don't actually use native widgets. Sure, you might be getting a performance gain, but you're still losing on platform-specific behavior.

<comment><USER11> I think it's a matter of taste.

If you like native widgets more, you can look into briskml

[https://github.com/briskml/brisk](https://github.com/briskml/brisk)

</comment></comment><comment><USER12> The more I hear about Reasonml the more it intrigues me. This project is obviously in early stages, but it appears to have found a combination of parts from the ocaml and web development ecosystems that just might work well. All the best!

<comment><USER13> I've much more will to learn ReasonML than Typescript.

<comment><USER14> I keep considering it myself. I've done some things with OCaml, so I doubt the learning curve would kill me. I am a little dismayed that it's still a client side only language. (there are efforts to bring it to Node)

<comment><USER15> It's not a client-side-only language. You can and people do write servers with OCaml. Here's a full-stack OCaml/Reason app that demonstrates the state of the art today in tooling and usage: [https://github.com/atongen/setml](https://github.com/atongen/setml)

</comment></comment></comment></comment><comment><USER16> Every GUI library should have some screenshots..

<comment><USER17> If you look at the roadmap section there's really nothing to screenshot yet. Widgets available: View, Image, Text. Widgets not available: Input, Button, Slider, Checkbox, ScrollView and everything else not on their list.

<comment><USER18> Sorry this just hasn't been updated in a few weeks. I just opened a PR to update the README to clarify that. We actually have all of those done right now. Here's a gif of radio buttons in action from a pull request [1].

[1] [https://user- images.githubusercontent.com/21044999/51702694-...](https://user- images.githubusercontent.com/21044999/51702694-aba73a00-1fd1-11e9-99d5-dd882dc0ff48.gif)

</comment></comment></comment><comment><USER19> The developers behind Oni (a text editor inspired by Vim and VSCode) are rewriting it in this framework:

[https://github.com/onivim/oni2](https://github.com/onivim/oni2)

<comment><USER20> The project looks interesting, but the licensing change from MIT is a bit worrying:

"Oni 2 is licensed under the CC-BY-NC-4.0 license."

CC licenses are not a good fit for software in general - and "non commercial" isn't very clear. Making something available at zero cost doesn't necessarily make it "non commercial".

Ed: and it means that code snippets/widgets from oni2 can't be used elsewhere without careful licensing - which is one reason cc/NC is a poor fit even for code examples - it's for education, but you cannot use what you learn...

<comment><USER9> Oni 2 creator here. Agree with your concern 100%. We're working to review the license and come up with a better fit with more clarity.

We really just want a license that says - free to use for educational / non- commercial purposes, but a license is required to use in a commercial environment. No real "drop-in" licenses to support this, unfortunately. Some additional thoughts about our considerations here: [https://www.reddit.com/r/neovim/comments/ae7ef6/question_abo...](https://www.reddit.com/r/neovim/comments/ae7ef6/question_about_oni_2_license/ednq9hz/)

The work that we want to share out (custom widgets that are more generally applicable) will live in Revery - that's the reason we split Revery out from Oni2 into an MIT Licensed project - so that we could share the heart of the work out with a broader community, and get help building out this foundation, too.

<comment><USER20> Hm. The problem here is that this sounds like it won't be open/libre/Free, and is likely to have issues with collaboration (on the code).

It sounds like a dual license with AGPL might be what you want?

Just an example, if I work for a year on a free/gratis project using and modifying oni2 - I'll have a _disadvantage_ working in a commercial setting on similar projects - I can't use my own snippets, mixed with oni2 code in my commercial (even if open/free) project...

I think the "shareware" model might work (and eg: giving free licenses for education, non profits etc). But I'm not sure how the "user freedoms" for code can work at the same time as there are restrictions that are unclear.

Maybe the best one could hope for is a source-available license a la tarsnap. But that would pretty much make oni2 a closed (no external collaborators) project.

Maybe that's your intention?

</comment></comment></comment></comment><comment><USER21> This would be fantastic for VST (Audio workstation plugins) that must be lean on resources, cross platform, and very rarely want a native UI anyway.

</comment><comment><USER22> I doubt that it's feasible to reimplement GUI widgets. They require tons of micro behaviors. Revery will need to implement not just the looks, but also input, with a bunch of different devices in various configurations―which means lots of possible combinations and interactions between the elements.

Since Revery doesn't use native widgets, it will lose all advanced native features―e.g. nuances of input handling, and automation―or will have to reimplement them one by one on the low level, polluting the code with native paradigms from each platform.

Browsers and GUI toolkits spent decades on this, and still they lag behind, as evidenced by QT's non-support of keyboard remapping on MacOS (i.e. sane "home" and "end").

<comment><USER9> Note that Revery was built to power a text editor - which involves custom controls and interactions. Even elements as simple as scrollbars get re- implemented in that space.

I've been continually amazed at the ingenuity of the React ecosystem - so many intricate, well-designed custom controls - I believe if you have the write set of primitives, that community can make amazing things happen. So I'm hopeful and optimistic that we can at least get a subset of decent controls. But agree it's a challenge!

There are some cases (like text input) that are just so hard to get right - and can even change between OS versions - so we're looking at native support for some of those pieces.

Also, there is another project, similar in spirit to Revery, called Brisk [1] that uses platform-native widgets entirely. We're actually working closely together with them.

[1] [https://github.com/briskml/brisk](https://github.com/briskml/brisk)

</comment></comment><comment><USER23> Say what you will but electron being "terrible" has been a great thing for advancing the state of cross platform gui!

<comment><USER24> true. on macos many of the QT and java apps that used to be the norm were a lot worse. clipped buttons, for example.

or pseudo-aqua buttons that were not quite right, uncanny-valley style.

</comment></comment><comment><USER9> Hey HN! I'm Bryan, creator of Revery. I was really surprised when I saw Revery on the front-page of HN, so cool!

I apologize that there isn't more info - we're still working on website, docs, architecture diagrams, etc. But I'll be around for a bit to answer questions. It's still pretty new and actively developed - we're building it in parallel with the next version of our Oni [1] text editor. Some of the rationale for this decision can be found in our early architecture document for the next version of Oni [2].

ReasonML (which is a syntax over OCaml) is now a great environment to build native apps. Most of the attention has been focused on the compile-to-JS scenarios, but the tooling is at the point where you can just as easily compile-to-native on the major platforms, thanks to tools like Esy [3] - workflow isn't much different from NPM+JS development!

Jordan and team, as well as OCamlLabs on the OCaml side, have been smoothing out this native workflow (it's not easy to build a package manager for native code!), and I think/hope you'll see more ReasonML projects like Revery start to pop-up.

I'm bullish on this because React-as-a-paradigm (pure-functional UI) is a natural fit - it's like a language designed for React.

Not only that, there is some incredible work that has been invested in the OCaml ecosystem, too:

\- The compiler is FAST

\- The GC is FAST (also deterministic and supports sliced collections, important for perf)

\- Very powerful type system (ADTs, GADTs) - we even express the React 'rules of hooks' in types, such that they're enforced in the compiler.

The output code generated by the OCaml compiler (ocamlopt) is fast too - <USER2> some cases on par with C++ [4]

Everything seemed to line up in terms of tech to make it a natural fit for us to give it a try :)

And Revery is meant for very custom UIs - there is a counterpart project called Brisk [5] that uses platform-native widgets. We share common infrastructure and in fact uses Brisk's reconciler to provide the 'React' layer and component model.

[1] [https://github.com/onivim/oni](https://github.com/onivim/oni)

[2] [https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a...](https://gist.github.com/bryphe/ca3260914818a1293864e9fa6422a69c)

[3] [https://esy.sh/](https://esy.sh/)

[4] [http://www.ffconsultancy.com/languages/ray_tracer/comparison...](http://www.ffconsultancy.com/languages/ray_tracer/comparison.html)

[5] [https://github.com/briskml/brisk](https://github.com/briskml/brisk)

</comment><comment><USER25> If I built a web app with Reason can I reuse the code and turn it into a desktop app using Revery?

<comment><USER18> Unfortunately, we aren't compiling pure React code to native -- for something like that Electron is probably the go-to solution for now. However, the reverse is true. Revery apps can be compiled into a web app without you needing to do anything (assuming you aren't using any native-only libraries with it). So all our example code is automatically able to be compiled to a JS web app.

</comment></comment><comment><USER26> Has anyone here actually tried using it? I'd be interested to hear a comparison between Revery and Electron in terms of ease of use, performance, drawbacks etc. I read through the README but tbh I'd prefer an external opinion.

<comment><USER27> look at qmoji[1] a mojibar[2] (electron app) clone written in reasonml.

The README includes package size, and memory usage comparisons.

[1] [https://github.com/jaredly/qmoji](https://github.com/jaredly/qmoji) [2] [https://github.com/muan/mojibar](https://github.com/muan/mojibar)

<comment><USER18> Looks like this is using Fluid rather than Revery. Not sure about memory usage in Revery but I think it should be lower than that. Definitely something I'll look into

</comment></comment></comment><comment><USER28> If anyone is interested in a similar idea, but using javascript (or React), this reminded me of a project I heard of a while ago: [https://github.com/parro-it/libui-node](https://github.com/parro-it/libui- node). It's built on top of [https://github.com/andlabs/libui](https://github.com/andlabs/libui), "a portable GUI library for C" and it powers a truly native React Native for desktop: [https://github.com/kusti8/proton- native](https://github.com/kusti8/proton-native).

Disclaimer, I've only ever dabbled in these projects and cannot attest to the quality, package size, speed, etc. Just figured I'd share

</comment><comment><USER29> >> Revery is like flutter in that it does not use native widgets

The word native is pretty overloaded these days. According to this article, native means using react-native in their browser page. And their browser is somehow fast.

<comment><USER11> Native in the context of Revery means you get a native binary out of it.

</comment></comment><comment><USER30> Is this targeting the same space as Flutter? That's an enormous amount of work, and can't imagine it being done without a Google-scale level of resources (I'd be happy to be proven wrong, though!).

<comment><USER18> Not entirely. For now Flutter is focused mainly on mobile apps whereas Revery is focused primarily on desktop apps (though we do plan to tackle mobile apps eventually and Google is sort of moving in the direction of targeting desktop in Flutter).

However, we are like Flutter in that we're implementing all the UI components from scratch. It is a lot of work but I've been shocked by how quickly things have moved -- I made my first PR a little over a month ago and since then we've gotten: checkboxes, sliders, scrolling, buttons, input components, box shadows, overflows, etc. as well as a ton of performance/bug fixes. Our example apps went from rendering images to including an interactive version of Conway's Game of Life seemingly overnight.

</comment></comment><comment><USER31> So it's Flutter, but with ReasonML/OCaml instead of Dart.

<comment><USER27> So electric car, but from Tesla instead of Nissan. ;)

</comment></comment><comment><USER32> Size of executables?

<comment><USER27> See [https://github.com/jaredly/qmoji/releases/tag/1.0](https://github.com/jaredly/qmoji/releases/tag/1.0) for an apples to apples comparison between the same app implemented in Reasonml vs Electron.

* Reasonml App - 3.4 MB * Electron App - 121 MB

</comment></comment><comment><USER33> did all of this spawn from Phonegap? I remember when Phonegap first came out, it was a clever thing but rough around the edges. I used it when chasing the cross-platform mobile app dream with some success.

Then Apache picked it up as Cordova and the Ionic framework really helped to show what could be done with it. Ionic has come a long way and I'm, today, finishing up a client mobile project using that framework.

A while back I recommended Electron to a colleague who was tasked with implementing an old java applet as a stand alone application (we're all web developers) and it really saved him a lot of grief (client was happy with the price tag too).

To me, Electron is Phonegap for the Desktop. Is that how this all came about?

<comment><USER34> Not really. The idea of using HTML and Javascript to create apps isn't really new, and Phonegap and Electron are quite different architecturally. (Phonegap was really just a series of abstraction libraries that bundled in a webview into a native app; Electron couples a browser with a Node run time) One of the competitors to Phonegap in the earlier days, Appcelerator Titanium, was capable of targeting the desktop, and was released in December 2008.

</comment></comment><comment><USER35> The same problem - Javascript.

<comment><USER36> The repository is 95% OCaml, 3.9% cpp, 1.0% other mate.

I recommend clicking the link next time.

</comment></comment><comment><USER37> Sorry but I won't learn Reasonml in order to use this.

</comment><comment><USER38> Native? High-performance? Using Electron?! Something isn't right.

<comment><USER39> This isn't based on Electron. I think you misread.

<comment><USER38> I stand corrected. My bad.</comment></comment></comment>


$15 minimum wage hike is hitting, hurting NYC restaurants - <AUTHOR> https://nypost.com/2019/09/29/15-minimum-wage-hike-is-hitting-hurting-nyc-restaurants/ <comment><USER2> A version of the story was discussed a month ago. I believe it had a different conclusion.

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

I guess the story is hacker news worthy if we discuss the economics.

One thing to notice is that the New York Post is a conservative newspaper, so they take a conservative view. Of course the other sources may be more liberal.

Something to factor into the equation.

<comment><USER3> There is nothing "conservative" about the NY Posts view. They are reactionary rabble rousers.

The economic challenge for NYC restaurants in reality is the rent, full stop, end of story.

<comment><USER2> I didn't say anything about this particular viewpoint.

I said the New York Post is a conservative paper:

[https://mediabiasfactcheck.com/new-york- post/](https://mediabiasfactcheck.com/new-york-post/)

You should try to understand the biases of any given paper when reading their opinions.

</comment></comment></comment><comment><USER4> "The $15 minimum wage was supposed to hurt New York City restaurants — but both revenue and employment are up"

[https://www.marketwatch.com/story/the-15-minimum-wage-was- su...](https://www.marketwatch.com/story/the-15-minimum-wage-was-supposed-to- hurt-new-york-city-restaurants-but-both-revenue-and-employment-are- up-2019-10-28)

<comment><USER5> Yes.

It's not hard to find anecdotes about dying restaurants in NYC - the turnover is incredibly high. Nor is it surprising that some restaurants relied more heavily on large quantities of cheap staff than others did.

I have little sympathy for the restaurant though. "I'd love to pay my employees 1000$/hr, but our margins are down from 12-15% to 8-10% because we are now paying 15 instead of 8" is more or less direct quote from the article. That's not "going out of business", that's "we are more profitable than the average hospital, ... those servers are making too much".</comment></comment>


AWS Elastic Beanstalk - <AUTHOR> http://aws.amazon.com/elasticbeanstalk/?ref_=pe_12300_18337730 <comment><USER2> Here are a few submissions:

<http://news.ycombinator.com/item?id=2119122> <\- No discussion (yet!?)

<http://news.ycombinator.com/item?id=2119104> <\- Much, much discussion

<http://news.ycombinator.com/item?id=2119096> <\- One comment (currently)

<http://news.ycombinator.com/item?id=2119079> <\- No discussion (yet!?)

<http://news.ycombinator.com/item?id=2118778> <\- Some discussion

<comment><USER3> Great roundup. People are clearly excited!

</comment></comment><comment><USER4> I'm really excited about this. We were burned bad by building on top of App Engine and then eventually had to switch to EC2. If they add native Python support this will give us the best of both worlds.</comment>


Facebook Revenue Was $1.6B In First Half Of 2011, Net Income $500M - <AUTHOR> http://techcrunch.com/2011/09/07/report-facebook-revenue-was-1-6-b-in-first-half-of-2011-net-income-500m

<comment><USER2> I think comparing Google and Facebook's profits as the author does is kind of a misnomer. Google is incredibly more dynamic and has way more depth than facebook, which is well just facebook. Their list of acquisitions, while impressive, doesn't show a very big willingness to step outside of their comfort zone and try new things where as Google has done everything from a search engine, to a browser, cellphones, and even high speed broadband networks.</comment>


Introduction to asynchronous JavaScript - <AUTHOR> http://tutorials.pluralsight.com/front-end-javascript/introduction-to-asynchronous-javascript <comment><USER2> Hmm. An article in 2016 about async javascript without any references to async/await?

Also, using promises to make code look prettier is kind of missing the point, and can be achieved with callbacks too. The real reasons to use promises are:

1\. Error handling/bubbling

2\. No chance of 'double callbacks'

3\. Value-oriented code

4\. Easier composition of async tasks

5\. Ease of migration to async/await</comment>


Ask HN: What wallet and keychain do you use? - <AUTHOR> I'm 40 now and have never, ever, been happy with how I carry my keys and stuff.
For a while I got one of those phone cases that's also a wallet but it didn't carry enough.
How do you organize the stuff you carry around with you every day? <comment><USER2> I had the same dissatisfaction as you, both for wallet and keys.

3D printing allowed to me solve both of those problems. Thingiverse provides a plethora of different solutions on both fronts. The two that I settled on work great for me.

For my wallet, I use this minimalist one: [https://www.thingiverse.com/thing:2347625](https://www.thingiverse.com/thing:2347625)

Given that you mentioned that you tried a wallet that didn't carry enough, a minimalist one might not be your speed, but I encourage you to give one a try. I was skeptical, but learned that everything became much better when I dropped the habit of carrying everything I might possibly need in my wallet. Now I carry just 6 cards, a credit-card multitool, and some cash.

For my keys, I use this: [https://www.thingiverse.com/thing:2749745](https://www.thingiverse.com/thing:2749745)</comment>


Ask HN: Statistics on startups - <AUTHOR>

Hello everyone
As part of my research, I am trying to gather information of the life cycle of a web-startup:
Things like:
* Average time to seed, to VC money, to profitability.
* State (users/revenue) when raising money.
* Average amounts raised * Success rates and investor returns.
Can anyone recommend additional sources of information ?
Will post back here once its all compiled. <comment><USER2> Take a look at Crunch Base, should give you most of what you're looking for. <http://www.crunchbase.com></comment>


JavaScript: The (Un)covered Parts (2017) [pdf] - <AUTHOR> http://salt.ece.ubc.ca/publications/docs/icst17.pdf <comment><AUTHOR> Snippet from the abstract:

> We scrutinize the (un)covered parts of the code under test to find out root > causes for the uncovered code. Our results show that JavaScript tests lack > proper coverage for event-dependent callbacks (36%), asynchronous callbacks > (53%), and DOM-related code (63%).</comment>


PhysicsJS Examples - <AUTHOR> http://wellcaffeinated.net/PhysicsJS/examples/showcase.html#demo-1

<comment><USER2> I think this has been featured on HN like three times since it first was created. It's a really cool demo though, really enjoy the bounciness of "fruitcake on wheels".

</comment><comment><USER3> There is a dramatic performance difference in "Newton's Revenge" between Chromium and Firefox (Linux). I wonder why.

</comment><comment><USER4> I like the falling leaves. :)

<comment><AUTHOR> The trees actually look a little d3js-like [http://prcweb.co.uk/lab/d3-tree/?utm_content=buffer14589&utm...](http://prcweb.co.uk/lab/d3-tree/?utm_content=buffer14589&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer) :)</comment></comment>


Eugene Kaspersky frustrated by Apple's iOS AV ban - <AUTHOR> http://www.theregister.co.uk/2012/05/22/kaspersky_ios_antivirus/

<comment><USER2> Bit of an interesting problem to have.

If the iOS platform was filled with malware threats, the platform itself should be fixed, not intentionally adapted and modified so another company can come in and fix it instead, that makes very little sense.

But there doesn't appear to be a huge malware threat in the first place, in part _because_ Apple is the one controlling the platform and dealing with it, they planned in advance and to some extent made these AV companies unnecessary.

</comment><comment><AUTHOR> I can see his point but at the same time I really don't. Phones should be a huge target with the amount of personal information stored on them, but the sandbox that Apple puts every app in really means they can't get at much of it. Sure there are vulnerabilities in lots of pieces of code, but it's up to a malware developer to find them.

<comment><USER3> Who can't get what?

[http://venturebeat.com/2012/02/07/developers-ask-why-path- is...](http://venturebeat.com/2012/02/07/developers-ask-why-path-is-grabbing- names-numbers-and-emails-from-users-phones/)

iOS was designed to allow this. AV won't fix this, either. Users _will_ share any data to use a certain app.

</comment></comment><comment><USER4> He wants to sell an antivirus app that scans iOS for nonexistent viruses, looks like some kind of malware)</comment>


Every company was once a single person with an idea - <AUTHOR> https://innovationanarchy.com/heres-why-im-hopeful/#.Wj8HZd-nF3g <comment><USER2> Every company was once a single person with an idea, as were every company that never came to be. While it's humbling to think that these large companies used to be just in the brains of a few individuals, it's so easy to not look at the graveyard filled with individuals with the same idea but the stars didn't align. When you focus where the light shines, you forget how dark the room is.

<comment><USER3> Success bias. Exactly what I thought :)

</comment></comment><comment><USER4> This is a nice motivational piece.

That said, I would have liked to see some acknowledgement that the original idea is rarely the one that generates value. The "single person with an idea" by itself places too much emphasis on the value of the idea versus the dogged persistence and willingness to throw that idea out the window as needed.

<comment><USER5> >the original idea is rarely the one that generates value

Roger. The individual with dogged persistence is where the value comes from. More so from persistence of potentially rewarding ideas rather than pursuing fickle sources of capital.

Nicely motivational and it looks like an advertisement to attract midwestern entrepreneurs, too bad this particular group is not about to even consider an individual or even a small team unless they have already attracted overwhelming interest beforehand:

"iSelect identifies and invests in promising early-stage, private companies with more than just an idea. Our companies have already raised at least $250,000 through the "friends and family" round or received significant non- dilutive financing through grants or other sources. The entrepreneurs we work with are moving beyond concept to commercialization, but require more capital for further development."

Then again they are not about to show interest unless the "single person with an idea" has already attracted interest from even more elusive capitalists whom they can ride the coattails of:

"iSelect does not lead transactions. We only co-invest alongside sophisticated investors such as venture funds, reputable angel groups or family offices with domain experience. Prospective companies must already have, or be in discussions with, a sophisticated lead investor willing to set the price and terms of the round."

Looks like they have the perfect formula to exclude individuals like Jobs, Zuckerberg, Ford, or especially Edison unless the individual has already gotten the momentum to devote more effort to fundraising than actual development of their winning ideas.

Typical.

<comment><AUTHOR> Yes, it should all be so easy.

I manage iSelect. I too have to get money from others. Those investors have a certain risk profile. iSelect works to find companies that fit their needs. We close a gap with iSelect, not all gaps. We have funded many companies that otherwise would not have been funded. Those companies are growing.

The gap between an idea and funding creates other challenges. Success comes from execution and listening to customers, not an idea. It is not just about funding.

I have spent a long part of my career working on the early stage gap. Succeeding and failing. In time I will close that gap. If others wish to help, please join the effort.

Thanks for your comments.

<comment><USER5> Good to see you here.

I did get the idea from this article exactly that you would like to have the option to invest in promising individuals to enable one of their cherished ideas to bloom from an almost blank page.

That's what made me look at your website, and was disappointed that the firm as a whole can not realistically do that any more so than the average VC's. You've got to have similar guidelines that avoid the extra risk that would entail if you want to swim with the sharks without running out of air.

I expect you realize better than most that these limitations have kept your group from getting in closer to the ground floor on some of the very companies that you have successfully capitalized.

I guess to me I expect superior execution ability and customer satisfaction technique to be part of a winning idea.

</comment></comment></comment></comment><comment><USER6> "When I started Reynholm Industries, I had just two things in my possession: a dream and six million pounds."

</comment><comment><USER7> Usually it takes more than one person to come up with a good company.

</comment><comment><USER8> And sometimes, but not always, a financial safety net or a boatload of funding.

<comment><USER9> It doesn't hurt to have a few friends or relatives higher up.

</comment></comment><comment><USER10> OK, I came here actually wanting to read the article.

First thing that happens is a chatbot pops up wanting god knows what with an annoying notification sound. I find its quasi-transparent X close button and click it, only to have a huge popup show up literally a second later, asking me to fill in my email for god knows what other reason.

I left the site. Fuck this.

<comment><AUTHOR> Sorry about that. I think it is now fixed.

</comment></comment><comment><USER11> Most companies were started because someone needed something fairly mundane done.

Even most inspirational companies were started more or less along these lines.

Extremely few companies were started with a highly aspirational 'world changing' premise. Even the most aspirational brands we recognized, early on - they had no idea they would be as big as it they are.

</comment><comment><USER12> ...Or a Delaware corporation as a vehicle to avoid taxes ;)</comment>


Log Alerting, Anomaly Detection and Scheduled Reports - <AUTHOR> http://blog.sematext.com/2015/06/23/log-alerting-anomaly-detection-scheduled-reports/

<comment><AUTHOR> Its like ELK + watcher but with UI - SaaS, on-prem as well. Kibana runs as well on it. Security RABAC. API is hidden in the docs: [https://sematext.atlassian.net/wiki/display/PUBLOGSENE/Logse...](https://sematext.atlassian.net/wiki/display/PUBLOGSENE/Logsene+API+Reference)</comment>