Cisco to release BSD-licensed H.264 stack - <AUTHOR> https://brendaneich.com/2013/10/ciscos-h-264-good-news/ <comment><USER2> That's the "Good News". Now for the rest of the story:

The open source part of this is nearly useless, if not completely so, as evidenced by the fact that Firefox won't be using the source code. The "you don't have to pay the MPEG-LA" part only applies to the binary module. If you want to pick up this code and ship it in your own software, you'll still need to pay the MPEG-LA.

The reason they are doing this is to put more weight behind H264 in the political battle in the IETF over the MTI video codec for WebRTC. But if they succeed in making H264 the MTI, and you want to write a mobile app that interops with WebRTC for doing some form of realtime video, you'll won't be able to use their source code without paying the MPEG-LA. You'd have to use their binary module, downloaded from their servers, which, as they mention in the Q&A, is impossible on iOS.

The announcement seems to try hard to smudge this distinction and push it into the fine print, but there's still a patent "elephant in the room".

TL;DR: This doesn't solve the patent issues surrounding h264, and doesn't make it anymore suitable as an MTI for WebRTC.

<comment><USER3> Yes this sucks, it's obviously MPEGLA's (of which Cisco is a member as a h264 patent holder) move to prevent WebRTC from standardizing around VP8/VP9 (which is already supported in Firefox and Chrome), so instead we are to rely on a binary blob from Cisco for royalty free WebRTC (Flash all over again).

The big stink is how Firefox is supporting this, it's like a huge betrayal of the principles of an open web which is what I directly associate Mozilla with.

As a long time Firefox user and promoter I feel betrayed.

<comment><USER4> We "betrayed" by not doing what, exactly?

H.264 won the HTML5 video battle, as noted at [http://brendaneich.com/2012/03/video-mobile-and-the-open- web...](http://brendaneich.com/2012/03/video-mobile-and-the-open-web/). If anyone betrayed someone then, it was Google for not doing as they explicitly blogged they would by removing H.264 support from HTML5 video in Chrome. (But I understand why they didn't; they're realists.)

For WebRTC where there is no extant/legacy content reason for us (not speaking for Cisco) to require H.264, we prefer VP8 over baseline H.264, but do not at this point want to rule out either. And on mobile devices, especially at the low end, the h/w codec advantage for H.264 is material.

Even next-year-announced chipsets with VP9 support tend to have only h/w VP9 decoding and at best s/w encoding (perhaps on an extra ARM core!).

Your fancy camera with video short-take capabality has boiled H.264 encoding as well as decoding into even low-end SoCs. How much this means for battery life, we are still digging into, but it's not trivial for long WebRTC calls.

Instead of dramatic talk about betrayal, where you seem to expect Mozilla to fall on the nearest sword stood up and aimed at our gut (probably by a competitor), and die a glorious but pointless death, think about the long run. H.264's price ceiling is now $0.

This matters for future codecs. Between our work on Daala, and downloadable codecs such as OTOY's ORBX.js, there is a better and unrestricted future to invent. Join us, if you can be realistic about H.264 h/w advantages.

/be

<comment><USER3> You already knew about how much more/better support h264 had long before you embarked on what now comes across as nothing but a charade as you turn coat ONE WEEK before the WebRTC future is being voted on, you KNEW this so what has changed?

Oh, what has changed is that now you, Mozilla, can use h264 royalty free, that is what has changed.

So suddenly open source royalty free standards aren't that important anymore. I threw up a little in my mouth when I read -'we lost the fight' from Monty, you didn't fight!

Instead you switched sides one week before the vote because MPEGLA threw you a bone.

And if all it boils down to in the end is 'hardware advantages' then you can just drop the pretense of Dalaa right now, it will NEVER be anything but much less supported than the latest offering from the MPEGLA cartel, so from that very perspective it's nothing but vaporware.

MPEGLA was terrified of WebRTC and HTML5 standardising under a truly royalty free open source codec which could be used anywhere by anyone, so they gave you the 'flash'-style binary plugin for 'free' and you swallowed it, hook, line and sinker.

This was the chance to break the royalty-laden video technology monopoly of MPEGLA by getting a truly free codec standarised, and despite you having made a show of 'carrying the torch' for royalty free open source web standards you sold out one week before showdown when Cisco called with an offer.

They got you cheap.

<comment><USER4> You are not making any sense.

First, MTI votes in IETF are tricky to predict, but here is a safe bet: VPx was never going to win sole MTI. Not ever.

Second, if we had not been fighting -- and holding to only WebM for HTML5 video until last year -- while our competition was shipping H.264 for HTML video, you might be able to say that we didn't fight. If we had not tried to make s/w VP8 perform on lower-end mobile phones ahead of others including Google, you might make that charge.

But we did those things and failed. We learned from those negative results. What have you done? What have you learned? Where is your skin in the game?

Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA. Taking H.264 to zero price is a net public good and a prerequisite for getting RF licensing of part or all of H.264 for all desktop systems (since rents there, as opposed to on mobile devices, are running low).

When we do that in the next year (or sooner) based on taking the price to zero, and gain free as in speech licensing, will you thank us? Not likely.

Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec, because HTML5 was never going to do any such thing. Now you're just confabulating. Again, read

[http://brendaneich.com/2012/03/video-mobile-and-the-open- web...](http://brendaneich.com/2012/03/video-mobile-and-the-open-web/)

and wake up and smell last year's coffee.

As for "they got you cheap", if I were about money, I would have gone to Google ages ago. If Mozilla were about money we would have sold out in any number of ways.

This is not about money, it is about interoperation and zero-price ceiling for H.264 now, and RF licensing for desktop next -- and after that, better codecs that are defensibly unencumbered and/or downloadable in JS and WebGL2 or better (probably both).

None of this is easy to pull off. Rejecting interoperation is a sure way to die fast for no good end. Shouting about betrayal on HN is cheap and easy by comparison. Try doing something productive for a change.

/be

<comment><USER3> >Third, MPEG LA has not thrown us a bone. Cisco != MPEG LA.

Oh please, Cisco is part of MPEG LA and you'd have to be incredibly naive to believe that this was Cisco striking it out on their own to offer a 'solution'. This is MPEG LA's offering, brought to you by one of it's members.

And likewise it doesn't take a genious to realize that you switching sides one week before the vote came as a result of discussion with Cisco, to offer broader support for h264 as the WebRTC standard.

So yes, I say you sold out.

>Fourth, MPEG LA was not terrified of HTML5 standardizing on a truly RF codec, because HTML5 was never going to do any such thing.

Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due to the kindness of their hearts.

Of course they were terrified, because even if this was just for WebRTC and not HTML5, it would have set a precedent for a fully open source and royalty free codec, with all the benefits that come along with it, which in turn would increase demands for fully open web video solutions in all areas.

Also you totally avoided the question I posed regarding your 'hardware support' argument, and where that leaves Dalaa as anything more than a toy project.

I held you guys to much too high standards it seems (much higher than any others in the web industry), I was obviously wrong.

<comment><USER4> > Oh I'm sure this royalty free h264 binary blob offering from MPEG LA was due > to the kindness of their hearts.

That's not from MPEG LA to us. That is from Cisco to everyone who wants to use a blog, and it's permitted by the licensing, just the same as Flash today can be downloaded from Adobe as a binary blob and neither I (as a user) nor Mozilla needs to pay MPEG LA.

I still see lots of anger, as well as confusion. Anger leads to the dark side.

A hopeful sign, kind of: you started with "betrayal" (Harold Pinter play!) and now you are faulting Mozilla for being confused, or for not reforming All The Things instantly. A bit of a climb-down -- just sayin'.

Please note that we don't like any of the bad patent-pooling, rent-seeking behavior either. Failing to overcome it all at once, finding an incremental path to what we believe will be a better future, not throwing ourselves on all the swords, is part of how Mozilla operates. If you want purity, there are prefs you can set and add-ons you can install in Firefox. If that's not pure enough because you have to set prefs or use add-ons, there are tiny share browsers you can use instead.

I'm not saying "there's the door", rather I'm explicitly reaffirming that Mozilla does not consider every bad reality imposed on competitive browsers to be a make-or-break principle test (Monty made it sound like that; Mitchell and I do not agree), which we can pass only by rejecting reality and therefore very likely shrinking to tiny market share.

/be

<comment><USER4> s/use a blog/use a blob/, LOL.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I __really__ __really__ don't get the mozilla stance here. It just doesn't make _any_ sense to me.

Mozilla has been resisting Googles libre codecs even though they come with full source code and a patent pledge. Google has already even paid to eliminate potential threat from the evil MPEG LA. It is as free(libre) as you can get in this space.

On the other hand, the Cisco plugin is no solution at all. A binary module that has to be downloaded by each user? How can Mozilla justify recommending/requiring a binary module whose source it can not view/audit/share? This approach wouldn't be permitted under Debian Free Software Guidelines, thus ensuring that WebRTC-Firefox won't work on debian and its derivatives.

Cisco benefits from H.264 winning the standards battle. They also have patents in the MPEG LA pool. Apple, MS and Cisco - none of them are under any obligations to provide a libre implementation of WebRTC. Only Google and Mozilla have that responsibility. And they can make it happen today by just agreeing to go with VP8 and VP9 when it lands (both are covered by the patent pledge as well as under the MPEG LA agreement).

H.264 is a defacto standard already, I understand. But google, with its control of youtube and Android, can make a serious dent in that. If Moz and Google ensure that VP8 becomes the de-jure WebRTC standard, a Free software implementation of that can be released by mozilla _today_. No need to wait for Dwolla to come to fruition.

I'd really like to understand what I am missing here.

<comment><USER6> Mozilla has implemented WebM playback, but WebM hasn't gained enough traction to matter.

> But google, with its control of youtube and Android, can make a serious dent > in that.

Uninstall Flash and try using a browser without H.264 codec. I have, and it sucks.

YouTube is the only major site that supports WebM, and even there WebM it's a second-class citizen (videos with ads are not allowed to use HTML5 player, and not all videos are transcoded to WebM).

Google dropped the ball here. Android still has better support for H.264 than WebM. YouTube is half-broken with WebM. Chrome broke promise of dropping H.264 — they know that a browser cannot survive without it.

<comment><USER7> And by the way, it is not possible to use Youtube without Flash Player. Some videos simply are not played with HTML player and Youtube tells you to download Adobe Flash Player :( Hope there will be some new competitor, who will offer video services without third party plugins. Maybe Vimeo?

<comment><USER8> I haven't had flash installed for years. For videos, I made a key-binding that extracts any URL's in XA_PRIMARY, launches [https://github.com/rg3/youtube- dl](https://github.com/rg3/youtube-dl) and then plays the video with mplayer. Looks better (because the vid is full res) and never skips.

<comment><USER9> There is almost always a way. But explain that to my mom/room mates/friends who don't even know what a key-binding is.

<comment><USER10> Don't explain it, just do it for them. Then they'll be the cool ones whose YouTube works better than everyone else's.

<comment><USER8> Code: [https://github.com/jakeogh/youtube-dl- wrapper](https://github.com/jakeogh/youtube-dl-wrapper)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> If you live in a country which doesn't allow patents for software, this is great news. I wonder why no one cares about it in this thread. Foreign laws is how we got DeCSS, VLC and Handbrake to name a few.

Mozilla could simply ship different packages for different countries, based on their patent laws. For example, US version could use binaries distributed by Cisco, while EU binaries could be built from source code maintained by Mozilla. IANAL but I think it would be completely legal as long as the company which distributes the EU version is a subsidiary or a separate legal entity located in EU.

You are free to use whichever package you wish. Of course it would be illegal if you live in a country that has software patent laws. But legality never stopped us from using VLC or Handbrake. Why should it now?

<comment><USER12> Mozilla already supports (in code, not principle) H.264 by leveraging non- Mozilla code. It's not usually a problem on Windows on Mac since the user has already paid for a license when they bought the OS, but on Linux (gstreamer) it can cause patent violations within US.

I hope (an believe) Mozilla will keep that functionality to use one of multiple backends (Windows's fedia framework, gstreamer etc.) when it adds this Cisco binary.

<comment><USER4> We will need WMF at least until OpenH264 does High Profile, and I believe we are not going to be able to use only the OpenH264 binary blobs. Therefore we'll support other back ends (but not necessarily all possible back ends).

/be

</comment></comment></comment><comment><USER13> This just seems like the worst of both worlds for Mozilla:

1\. You can't guarantee the code will remain open.

2\. You still can't build and distribute modified works even with the code you already have, because of patent constraints and licensing.

3\. You're using binaries from Cisco which you can't verify (unless they're going for deterministic builds).

We already have mature, high quality, open source implementations of H.264. Why can't Cisco just build and license one of those?

I for one will not be installing the binaries.

<comment><USER14> Cisco already promised to permissively open source this implementation (though not the binary fees-paid bit), because people were complaining they'd need to pay for an H.264 implementation (as well as patent fees) in non-GPL projects (GPL would allow you to use x264), which was another good reason to not vote for this codec to be MTI in WebRTC.

Which Cisco was pushing for as it makes it easier to inter-operate with all their existing video-conferencing gear.

Also, it costs them nothing since the H.264 licences are designed to not annoy the big players too much, because they could shift the market if they wanted too, and so cap out at about $6 million a year which I assume Cisco already pays.

<comment><USER13> You can use ffmpeg/libav's decoder in non-GPL or even proprietary projects, since it's LGPL.

<comment><USER14> This is in the context of WebRTC, i.e. standardized video web chat, which needs an encoder as well.

<comment><USER13> I'm not a video codec enthusiast, but it seems natural to me that low latency/real-time constraints on the encoding process is going to mean you're not benefiting from H264s full potential anyway. High profile H264 encodes are incredibly slow, and there must be other codecs that fill the streaming niche.

This may benefit hardware and corporate conferencing gear manufacturers (aka Cisco?), but I don't see how the encoder specifically benefits Firefox users.

<comment><USER14> Well it'll help interoperate with those legacy systems. It seems that VP8's libvpx implementation is likely to be better quality than this solution for a while, since it only supports Constrained Baseline (and even x264 roughly ties with VP8 when limited to that level) and won't even be available for months.

Also, if they get an AAC decoder from somewhere it'll provide H.264 decode of HTML5 video to Firefox users on XP.

I'd still like to see VP8 as the MTI in WebRTC, and I'm somewhat surprised by the timing of this announcement (i.e. nothing seems set to happen for months, so why are they talking about it other than to influence that decision?) but there's definitely pragmatic benefits for Firefox and its users.

<comment><USER13> Interoperating with legacy systems? What legacy systems? The majority of Firefox users currently don't use WebRTC with H264 streaming at all. This is a very new thing. Maintaining legacy only seems to benefit Cisco.

> if they get an AAC decoder from somewhere it'll provide H.264 decode to > Firefox users on XP.

aacdec.c and friends in ffmpeg git seem to be LGPL also...

<comment><USER14> Although it's called WebRTC, and the billion or so installs of the two existing Web browsers that actually implement it both use only VP8, there's a lot of moneyed interests (like Cisco) that want to be able to inter-operate with legacy systems outside the browser. Video transcoding would really put a crimp in their plans.

And when I said "get an AAC decoder" I mean in the same sense that they get the H.264 encoder/decoder from Cisco, or the AAC and H.264 encoder/decoder from later versions of Windows or Android, with the key feature being not paying any patent fees for it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Who maintains the open source code?

What if a source change is accepted and Cisco does not want to release binaries based on that code?

What if the code contains a security issue that is exploitable, but only in remote cases and the maintainers do not want to accept changes to the code for whatever reason?

How many attacks will there be trying to redirect the Cisco DNS in order to let Firefox download a malware-ridden binary?

Will the binaries be available as deterministic builds?

Will the binaries be signed and checked by Firefox? Who has access to those signatures?

How is this a victory over using GStreamer and using the encoders/decoders available on the OS?

<comment><USER16> This isn't necessary for systems that already have H.264 decoders provided by the OS, but it's useful for platforms like Windows XP (which still accounts for 20-30% of web usage) that don't have built-in H.264 decoders.

Firefox already uses cryptographic signatures to verify other code that it downloads (including updates to Firefox itself); it could do the same for the Cisco H.624 decoder.

Windows XP users already need to download a third-party binary plugin (e.g. Flash) to play H.264 videos in Firefox. Cisco's code has the advantage that it is open source and could be signed and distributed by Mozilla.

<comment><USER16> Correcting myself: it looks like Mozilla can't distribute the binary itself (while still benefiting from Cisco's end user licensing), though it could still publish its own signature for verification.

</comment></comment></comment><comment><USER17> Cisco owns WebEx. Along with Microsoft (Skype), and Nokia, they are fighting WebM in WebRTC as a mandatory to implement codec, so I am deeply skeptical of this move.

This seems basically about preserving investments in WebEx and Skype IMHO.

I also feel a tinge of Mozilla trying to kill WebM/VP8 to favor their own vaporware codec. Are we being told, forget VP8, use H264 for now until Daala?

<comment><USER6> It's unfair to call Daala vaporware. The source and documentation are released, and you can see it's making progress: [http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml](http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml)

> Are we being told, forget VP8, use H264 for now until Daala?

We're told Mozilla can't win battle against H.264, but will be fighting the next battle with Daala.

<comment><USER17> Ok, I take it back, vaporware is a little harsh. But in order for Daala to win, it will not only have to beat H.264, but also H.265 and significantly. Otherwise, the argument of the powers that be is that H.264/265 are the established standard, widely deployed, low-power hardware implementations, and here is this spec, which doesn't meaningful improve on quality, bandwidth, or battery life, but is license free.

In other words, Daala will have to hit a homerun out of the park to convince all of the major players to endorse it over their existing deployed infrastructure.

If they do, I will be the first one cheering in the streets. But I'm skeptical, hence again, like with WebP, we see Mozilla opposing something that offers immediate offers benefits now in favor of something that in a few years might be.

This Cisco blob, what if it significantly underperforms x264 in encoding quality and CPU. Would we then be stuck with crappy WebRTC video quality because you can't drop in better implementations?

<comment><USER4> WebP does not offer immediate benefits by our measurement:

[http://people.mozilla.org/~josh/lossy_compressed_image_study...](http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/)

[https://groups.google.com/forum/#!topic/mozilla.dev.platform...](https://groups.google.com/forum/#!topic/mozilla.dev.platform/9NKc7OeEFLM)

If you work at Google, please point out errors in our methods or data, give us better metrics, or otherwise correct us.

> This Cisco blog, what if...

"What if?" What if Google fails to get VP9 codecs into h/w? (See my response above; half-way [decoder only] does not count.)

Lots of what-ifs here, but I believe OpenH264 is Cisco's best s/w codec. Let's see, shall we, and not speculate idly.

/be

<comment><USER17> That's for JPEG, I had a long discussion on HN with someone, apparently from Mozilla, over what I meant by this. My social network streams are more and more filled up with multi-megabyte animated GIFs, and WebP is a reasonable replacement for both animated GIFs and transparent PNGs. Today, we have three formats to serve three needs: lossy, you choose jpeg, transparency, you choose PNG, animated, you choose gif. Animated and transparent? Out of luck. Lossy animated? Out of luck. Lossy and transparent? Out of luck.

I don't care so much about replacing JPEG as replacing GIF and PNG. APNG might fit the bill for animated, but given how much information GIF throws away, and given the 2M-5M GIFs I see out there already, it's likely to exacerbate the bandwidth problem, not make it better.

I don't really care if WebP is the replacement, maybe the replacement of mjpeg, or some other format so that people post short 5-6 second clips using <video> instead of <img>. But animated GIFs are chewing up a lot of mobile bandwidth and there is no solution out there right now that mitigates the problem.

<comment><USER6> > My social network streams are more and more filled up with multi-megabyte > animated GIFs, and WebP is a reasonable replacement for both animated GIFs > and transparent PNGs.

It's only slightly better than _lossy_ PNG:

[http://pngmini.com/vs-webp/](http://pngmini.com/vs-webp/)

It doesn't appear to be good at beating GIF, and loses to APNG in compression (and I suspect also decoding speed):

[http://littlesvr.ca/apng/gif_apng_webp1.html](http://littlesvr.ca/apng/gif_apng_webp1.html)

and I find it highly questionable whether a new format that is exactly as expensive as WebM intra frames should be used instead of WebM.

</comment></comment></comment></comment></comment></comment><comment><USER18> Am I misunderstanding something? Cisco is releasing source code to something heavily patent-encumbered, but is doing so under _BSD_ , an open source license with no patent release. What value is the source code then? I can only imagine it's to allow others to verify the correctness of their implementation. You certainly can't use that source code in your own binaries.

<comment><USER19> It will be just another H.264 decoder and encoder, like in libavcodec and x264 respectively. It's actually pretty exciting since no competing (with x264) open source H.264 encoder ever managed to reach maturity. And it's licensed more liberally than x264's GPL+commercial.

> You certainly can't use that source code in your own binaries.

Obviously you can, but then it's up to you to work it out with the MPEG-LA. Or not, depending on where you live.

</comment></comment><comment><USER14> Interesting parallel to EME. They've taken the paid for codec licences and the DRM out of Flash and built them into two smaller plugins (one binary based on secret DRM code, one binary based on open source code).

I wonder how this stacks up quality wise to x264. I thought it was a bit suspect that a few months back Cisco announced they would release this under a permissive open source licence only _after_ H.264 was accepted as Mandatory To Implement in WebRTC, while also continuing to argue for H.264 vs VP8 using the highly regarded (though GPL/dual-licenced) x264 encoder.

Also, how can this possibly be legit according to the patent license? Or do the patent owners turn a blind eye, like Microsoft in China, and Adobe with student piracy with their eyes on not losing control?

<comment><USER20> It's legit because Cisco are paying the license fees (mentioned in the article)

<comment><USER14> Yeah, but that's like someone paying for an all-you-can-eat buffet and then smuggling in a few bus loads of hungry people. Just because you paid for it doesn't mean it's what the people you bought it from were intending.

<comment><USER21> They're licensing per user - just that MPEG-LA has a upper bound of what to pay annually (currently $6.5 million). That's something that Cisco can probably better manage than not being able to move forward with their plans.

Question is if MPEG-LA closes that loop hole the next time they revisit licensing payments (but then, how? Microsoft and Apple profit from the same provisions, for example).

</comment></comment></comment></comment><comment><USER22> The Cisco paid MPEG LA license fees only cover the Cisco delivered binaries. Doesn't sound like this completely free plug-in method would work for say, iOS apps which can't download external binaries. You'd still have to cover the MPEG LA licensing. According to [http://www.openh264.org/faq.html](http://www.openh264.org/faq.html) "In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints. "

<comment><USER14> Does iOS not already provide the equivalent encode and decode capabilities to app developers?

<comment><USER22> I may be wrong, but I don't believe you can access the H.264 stream to send to a remote location, say for a video conference application. I believe the API only allows for saving to a file.

</comment></comment></comment><comment><USER23> NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!

nothing is being released as BSD-license! NOTHING! take down this title! it will only harm the public perception of webM and make webM supporters sound as crazy as i am sounding here (i am the exception guys, everyone else is pretty sane)

CISCO is releasing header files and such so that you can compile their still- patent-encumbered binary blobs into a few major platforms. NOTHING even slightly relevant is being given out as BSD-license. Nada. Zero.

This is nothing but harmful propaganda against open standards.

<comment><USER24> > NO! WRONG! tl;dr NO CODE IS BEING RELEASED AS BSD!

Then please cite a source that backs that up. Bothering to follow the links from the Mozilla post indicates you are dead wrong:

        We plan to open-source our H.264 codec, and to provide
        it as a binary module that can be downloaded for free
        from the Internet. -- [1]

        [...] The source code will be open source and distributed
        with a BSD lIcense. The binary module is separate and
        when the users software downloads it from Cisco, that
        is when we are responsible for paying the MPEG LA
        royalties. – Nadee Gunasena, Cisco PR [2]

[1] Cisco blog: [http://blogs.cisco.com/collaboration/open- source-h-264-remov...](http://blogs.cisco.com/collaboration/open- source-h-264-removes-barriers-webrtc)

[2] Comment on same: [http://blogs.cisco.com/collaboration/open- source-h-264-remov...](http://blogs.cisco.com/collaboration/open- source-h-264-removes-barriers-webrtc/#comment-966417)

<comment><USER23> you even cite the source but can read the paradox on "open source [...] and provide a binary blob"? Read the response from Firefox to understand. If you are not a coder, than i apologize and provide a car analogy :) they are giving out cars with the engine bay shut, but they are providing 3D files under BSD license so you can print a glove and a shoe to use when driving the car. And the shoes and gloves are so bad, the the mozilla driver said he will just sew his own and use the car for free, which he still has no idea which engine it is using or what fuel it takes.

as i said, no "significant code" will be provided. The code they are open sourcing is HEADER FREAKING FILES for the entry points on the binary blob.

It is the exact same thing as nvidia provides. and nvidia even provides the header files as GPL! so let's all go buy nvidia drivers as they have GPL OPEN SOURCE DRIVERS PROVIDED BY NVIDIA! huray!

<comment><USER25> I think you're confused here. Let me try to explain with an example. Mozilla provides sources and binary blobs both. The latter in no way negates the former.

Cisco will be providing sources and binary blobs both, and the latter in no way negates the former.

Yes, there's "a catch". The catch is, though you get a BSD code license on the source that allows you to redistribute the the source, you do not get a patent license for shipping products based on that source. The only patent protection you can get from Cisco is from their specific binary.

Cisco's isn't the first open source H264 codec and it won't be the last, but it's the only one that comes with patent help and that's what makes it different from the others.

</comment></comment></comment></comment><comment><USER14> Announcement to WebRTC list: [http://www.ietf.org/mail- archive/web/rtcweb/current/msg09269...](http://www.ietf.org/mail- archive/web/rtcweb/current/msg09269.html)

The project website: [http://www.openh264.org/](http://www.openh264.org/)

</comment><comment><USER26> I see no source code. And until I do see the source code, this isn't news, this is just hot air lies from a big corporation.

</comment><comment><USER19> An interesting aspect of this announcement is that it has the potential to cut into x264's bottom line. For several years now the authors have dual licensed the encoder under the GPL and a commercial license[1], meanwhile enjoying an uncontested position among H.264 implementations. I don't expect Cisco's offering to be able to compete on speed or quality of implementation, but the BSD license also means that it may be "good enough" for some potential x264 licensees. I'm curious to see how this plays out.

[1] [http://x264licensing.com](http://x264licensing.com)

</comment><comment><USER27> Meanwhile you can enable native H264 support on linux with the about:config setting "media.gstreamer.enabled". This requires gstreamer with the respective plugin to be installed.

</comment><comment><USER28> Very sad that software patents are strangling any type of forward progress in this area (webm/webrtc). I almost want to say a mti is impossible to dictate in this arena, and just leave it to the protocol to handshake... if it fails so be it, no video.

</comment><comment><USER29> Are they saying that WebRTC is going to standardize H.264, or they are saying just that Mozilla will have an easy way to implement it in cases where nothing else is possible?

It would be better if WebRTC standard remained ambiguous about video (like it is now), but in practice H.264 could be implemented by everyone, rather than making any such encumbered codec mandatory. The big failure here is of course not making VP9 mandatory, but it looks like before Daala comes, we won't have a mandatory free codec for the Web.

If H.264 will become a mandatory part of the standard - then it will be pretty bad.

</comment><comment><USER30> I just read this:

[http://www.zdnet.com/blog/bott/if-vlc-can-ship-a-free-dvd- pl...](http://www.zdnet.com/blog/bott/if-vlc-can-ship-a-free-dvd-player-why- cant-microsoft/4962)

What's the deal with VLC and H.264? Is it along the same lines?

Also I don't really get why you'd stick with the non-free codec if there was a free better alternative. What's so good about H.264, and is it better than the free competition?

</comment><comment><USER31> This is probably a RTFM question on my part - but how does VLC play back H264? I presume it's part of the x264 library, but is this essentially a reverse- engineered H.264 codec?

The weirder thing is that I have some handbrake encoded videos from ~ 2008 or so that don't play "Error: codec 'h264' not available. Yet other videos with the exact same codec/media information play fine...which is spooky.

<comment><USER32> There is no need to reverse engineer H.264. The spec is not secret. VLC operates out of France--not the U.S.

<comment><USER33> France or U.S. doesn't matter for this - the patent laws are more or less the same.

</comment></comment></comment><comment><USER34> If they get an AAC decoder as well... does this mean we'll finally have one video and one audio format for the web that plays everywhere?

</comment><comment><USER35> I'd like to see the binaries released as deterministic builds. This would avoid quite a few concerns for Mozilla supporters.

</comment><comment><USER36> Incoming Stallman "this is not free software" rant in 5, 4, 3, 2...

</comment><comment><USER37> Sad face.

</comment><comment><USER38> Great news but will we be paid by karma now or how should it work this whole opensource thing?

<comment><USER39> Please go look at the members list of the Linux Foundation [1]. And convince yourself that pretty much every single company on this planet uses open source software. It's not some new fad or hippy communist thing. It's serious multi billion dollar business.

[1] [http://www.linuxfoundation.org/about/members](http://www.linuxfoundation.org/about/members)

<comment><USER38> I was asking if people should expect to be paid when contributing to OSS or how is the busines model set up?</comment></comment></comment>


Startup job openings - <AUTHOR>

Other than offline local networking - What are the other channels to looks for jobs in a startup? Google wasnt a big help to me. I know there are openings on Joel on Software Forum and startuply.com. Any other options people might want to suggest. Thanks in advance <comment><USER2> "Who's Hiring" threads on HN: <http://bit.ly/cPTz5Q>

<http://craigslist.org/>

<http://indeed.com/> [aggregator]

<http://jobs.37signals.com/>

<http://careers.stackoverflow.com>

<http://authenticjobs.com/>

Tech-specific boards like:

<http://jobs.rubynow.com/>

<http://djangogigs.com/>

<http://www.python.org/community/jobs/>

<comment><AUTHOR> Great Resource.. Thanks!!

</comment></comment><comment><USER3> <http://ventureloop.com/ventureloop/home.php>

<http://startuply.com/>

<http://linkedin.com/>

Looking myself and these are what I use. Also read TechCrunch and similar sites. Then just contact the CEO of the company directly, don't apply to the job posting. This is the first time I have ever created a resume or interviewed so I'm learning as I go.

<comment><AUTHOR> Thanks Curt. I like your innovative way to contact CEO. Good Luck to you on job hunting.

</comment></comment><comment><USER4> The "Ask HN: Who's Hiring" posts are great. Lots of really great shops post on those threads. We're one of them, btw. Link's in my profile.

Good luck on your search!

<comment><AUTHOR> Thanks a lot !!! I will check out your website :)

</comment></comment><comment><USER5> This website has a huge list: <http://www.startupshiring.com/>

</comment><comment><USER6> ventureloop.com</comment>


8 Apps Apple Killed Today At WWDC - <AUTHOR> http://www.cultofmac.com/231121/seven-apps-apple-killed/

<comment><USER2> Based on the various reports of issues with iCloud losing data, I think 1Password is safe. If Apple took the time to make iCloud more robust, useful and transparent it could definitely be a killer feature.

<comment><USER3> Also, you know, the possibility of the NSA having all your passwords is kind of uncool.

</comment></comment><comment><USER4> Yahoo! Weather was a winner of The Apple Design Awards this year: [https://developer.apple.com/wwdc/events/awards/](https://developer.apple.com/wwdc/events/awards/)

</comment><comment><USER5> 1Password, last time I checked, is not only for OSX and iOS. But yes, to stay relevant and in business they shall have to show their love all the platforms(they are hardly noticeable outside of iWorld) they are on and maybe they need to tweak the price a little. No, they are free to price it at whatever amount they wish but LastPass is almost everywhere and it works like charm and on iDevices there's iCloud KeyChain now.

Pandora, Spotify share the same fate. The entire world is not buying iDevices. Well, it's a small portion actually. So if they also focus their energies to lesser worlds maybe they have a better chance and if they make it a point that "no, we are going to cater to the class only" then they will have to compete against Apple on Apple's turf and within Apple's rules and laws and one fine day Apple can simply them to get out which it has done before.

Instapaper might be killed actually depending upon how many Mac users actually use Safari as their full time browser. I don't know any and among the people I know - pocket and Pinboard are the services they mostly rely upon and this kind of service(Instapaper included) are not much dependent on Safari either.

I don't really think any app or service is going to be killed until and unless they become totally dependent on iOS and OSX and I don't think there's any except like Instashare.

The author either assumed there isn't an ecosystem without an _i_ in their names or with an _X_ in the end; or it was directly towards iWorld which despite of being a MBA user I am not a member of.</comment>


Ask HN: Time for a beer or coffee - <AUTHOR>

I will be in Burbank ca next Tuesday and Wednesday meeting with a client. Would be interested in meeting up with anyone for a beer or coffee in the morning.  I run a consultancy and am building a product business. So whether you want to pick my brain or we can share I don't care, happy to buy you a drink and talk shop <comment><AUTHOR> Should say morning or evening.</comment>


Apple Delays iOS SSL Requirement Indefinitely - mark-ruwt https://developer.apple.com/news/?id=12212016b <comment><AUTHOR> What was supposed to happen on January 1st: [https://datatheorem.github.io/ios/ssl/2016/08/14/ats- enforce...](https://datatheorem.github.io/ios/ssl/2016/08/14/ats- enforced-2017/) .

"The overall approach the App Store review team will take when it comes to ATS exemptions was summed up on the Apple developer forums:

        "The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed."

Hence, for a given App going through the App Store review process:

* An easy policy to justify is to have NSAllowsArbitraryLoads disabled and a list of domain-specific exemptions for third-party domains the App connects to.

* A policy that will be harder to justify is to have NSAllowsArbitraryLoads enabled and a list of domain-specific "un-exemptions" for the domains you control.

* Lastly, a policy that will definitely trigger a rejection, as stated by Apple, is to have NSAllowsArbitraryLoads enabled with no additional ATS settings. "

Since most Apps are not compliant yet, the App Store review team would have had to review every justification for every App and make a decision on whether to allow the App on the Store or not.

</comment><comment><USER2> The apps at my F50 employer are in no way compatible with these requirements, and getting all the VPs to care about this is unlikely to ever reach even the minimal level of concern. Of course this is sad and stupid and shortsighted but unless Apple enforces it and our apps were refused updates nothing will ever change.

</comment><comment><USER3> This does not sound like the Apple I know about.

I mean, these guys forced every app to be able to handle IPV6-only network operations last year. And this was after making all apps switch to 64 bits a bit earlier. Why did they back up off SSL?

I feel like this is kind of a turning point, where Apple, instead of driving the market with innovative APIs and having a vision, now tries to compromise and removes innovative features to keep its immense app market happy, and oblige for it.

What a let down, especially after a very nice 2016 year, where they stood against the FBI and published their open letter about privacy of their customers.

<comment><USER4> > Why did they back up off SSL?

Go try and buy something on [https://apple.com](https://apple.com) \- you will once you go to view your cart you will be redirected to plain vanilla HTTP. There is no way around this. If they can't get their own SSL support in order...

<comment><USER5> Why is there no way around this? This is surprising to me and I'm super curious.

<comment><USER6> The exchange of payment or authentication information is undoubtedly done over TLS so it's probably just not a priority. That said there seems to be some obvious security issues with it since a bad actor could, as far as I know, inject malicious javascript in the vanilla http page to do all kinds of fun stuff.

<comment><USER7> Yeah but the checkout button on the insecure cart page could be changed so that it instead points to [http://www.apple-payment.com/..](http://www.apple- payment.com/..). or any random malicious "checkout" page which then steals your CC. They've compromised the security of credit card details users will at some point enter by doing this. It's insane if that isn't a priority.

<comment><USER8> It also exposes all of your cookies for apple.com since not a single cookie is marked secure/HTTPS only.

</comment></comment></comment></comment></comment></comment><comment><USER9> The title at the time of posting reads: "Apple Delays iOS SSL Requirement Indefinitely."

"Indefinitely" while technically accurate also implies "unlimited period of time." The article says there will be a deadline, it just hasn't been determined as of yet.

A better title may be "Apple Delays iOS TLS App Requirement." Just simply chop off the word "indefinitely." And throw in App to differentiate it from a e.g. Safari TLS requirement. Also TLS instead of SSL.

<comment> mark-ruwt Indefinitely means "for an unlimited or unspecified period of time".

[http://www.dictionary.com/browse/indefinitely](http://www.dictionary.com/browse/indefinitely)

<comment><USER9> I know. Which is why my post reads:

> "Indefinitely" while technically accurate also implies "unlimited period of > time."

It has two meanings. But is more often used to mean unlimited period of time.

<comment><USER10> Yep I read the title and assumed that the first meaning was meant.

</comment></comment></comment></comment><comment><USER11> They probably just don't want to break a bunch of applications that haven't updated yet. It would be nice if they could make it a configurable option for those of us who don't use / care to use apps that are still not using HTTPS. "Allow Secure Connections Only" checkbox in Settings or something.

<comment><USER12> Having a configurable option to disable a security setting is a pretty bad idea. Users who don't know anything about security will just disable it forever the first time an app tells them to.

<comment><USER13> I think you missed the idea, It could be temporary thing for a while, after a year or two and with continues beforehand notification, apple could disable non-secure connection apps definitely.

kind of like transition period.

<comment><USER14> No there shouldn't be a configurable setting; giving users a choice just creates problems; giving developers a way out just delays implementation.

As long as there is a way for an App to make non-SSL connection you'll have to run a non-SSL enabled endpoint; which in effect can put users at risk even if they haven't configured their own devices/apps to use it.

</comment></comment></comment></comment><comment><USER15> It was always a nice way to force my customers to implement HTTPS, the threat of Apple rejecting or removing the app. It's pretty easy to implement and inexpensive so why people still don't do it is a complete mystery to me.

<comment><USER16> Think of IoT Devices. For example, Sony's NEX Cameras have a build in HotSpot. You connect your phone to it and you have remote control to your camera. This has no HTTPS by now. Apple would break all those remote control apps. And it can't be fixed by releasing a new app version, because you also have to update the cameras.

<comment><USER17> There are allowances made for local networking.

From the Info.plist key reference ([https://developer.apple.com/library/content/documentation/Ge...](https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW54)):

App Transport Security (ATS) applies only to connections made to public host names. The system does not provide ATS protection to connections made to:

* Internet protocol (IP) addresses

* Unqualified host names

* Local hosts employing the .local top-level domain (TLD)

To connect to an unqualified host name or to a .local domain, you must set the value of the NSAllowsLocalNetworking key to YES.

<comment><USER18> That's assuming you're using bonjour (zero config). I have 2 clients with thousands of in home devices which are using NetBios to resolve a local ip address and directly connecting over http. I imagine there are many other hardware vendors still using this method out there.

<comment><USER17> Sounds like the HTTP connection is being made to an IP address, in which case you should be fine.

</comment></comment></comment></comment></comment><comment><USER19> Glad to see this. I'm about to release a new version of my app (a news reader, which makes extensive use of webviews), and I was sweating about this. I don't control any of the news sites that we interface with, and I was surprised to see that most don't support SSL.

While we could request exceptions for every single one, this would require updating the app every time we enable a new HTTP site through our back-end. I was not looking forward to this, and I wondered how many others were similarly dreading the transition.

On a related note, does anyone know how Firefox, Chrome, or other browsers are handling this? Don't they need to have a universal exception for HTTP, which is not supposed to be allowed under the new rule?

<comment><AUTHOR> Apple introduced an ATS exemption specifically designed for the browse-to-any- website-in-a-webview use case. You can also use the Safari ViewController which doesn't enforce ATS (by design). Hence you don't need to list all these third party domains in your Info.plist.

<comment><USER19> Unfortunately, the Safari ViewController doesn't do everything that the old UIWebView and WKWebView did. I think in our case we needed to be able to increment the cache size (to be compatible with Kindle Cloud reader), and this was only available on UIWebView. I could be mistaken here, and regardless I hope the Safari ViewController is updated to support this feature.

Forgive me if I've misused terminology here—I'm the non-technical founder—so my understanding of why we couldn't use the Safari WebView (which I assume is the same or closely related to what you referenced) is a bit fuzzy. All I know for sure was that our dev team was not looking forward to pleading for ATS exceptions.

</comment></comment></comment><comment><USER20> I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense.

It's annoying to have to audit your apps and enumerate the endpoints, but as long as Apple didn't require justification for explicit domain exceptions, everything should've been fine.

<comment><USER21> > but as long as Apple didn't require justification for explicit domain > exceptions

The previous plan was they they _were_ going to require justification for _every_ domain exception.

Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's _own_ protocol which is written to use AES encrypted segments over plain HTTP.

They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times.

I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.

<comment><USER22> You really shouldn't do HTTPS if you can't complete the chain of trust with a peer.

If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.

<comment><USER21> In my case, your peers are your friends. You use a pairing code (part of the SHA256 fingerprint) to accept the certificate (so you need to see the other person's screen and have agreement with the fingerprint) and then you can use indefinitely. It's great until the whole connection fails because some element in the system works with Certificate Authority certs-only – issues we're still working on and certainly won't be finished by Jan 1.

<comment><USER22> The finger print is public. There is literally zero security in this system anyone can hijack it

<comment><USER23> Public keys are public. Just because _you_ don't understand cryptography doesn't make a system bad.

There's nothing magical about certificate authorities. There are many ways to establish secure connections without them.

</comment></comment></comment></comment></comment></comment><comment><USER24> How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect?

Would ATS have enforced that there could only be a few centralized cloud servers?

And can I simply bypass ATS by linking in curl+openssl?

Are iOS apps even allowed to open raw TCP sockets?

<comment><USER25> > How would ATS affect apps which don't just talk to one server of the > developer of that app? What if an app should talk directly over wifi to a > device in your local home network via HTTP?

iOS 10 adds the key NSAllowsLocalNetworking which disables ATS for "connections to unqualified domains and to .local domains". So this can continue to work.

However, treating local networks as secure isn't generally a good design! If the home network has an open Wi-Fi hotspot, or a WPA hotspot with WPS PIN enabled or where the attacker knows or can bruteforce the password (and in many other cases), it is possible to sniff other users' traffic. Instead of using an unencrypted connection, whether HTTP or otherwise, you should design the initial pairing process between the app and the device to set up encryption keys. For HTTPS this can be in the form of having the device generate a self-signed certificate and send it to the app to use as a custom root. You need some sort of pairing or setup process anyway for the device to know how to connect to the user's network, so you might as well do security properly.

> Or to a system that each company who buys it hosts on their own and in the > app the customer has to supply that hostname or IP in order to connect?

In that case you should probably just require the companies to have a domain and a certificate for it; build in Let's Encrypt support if you want.

> And can I simply bypass ATS by linking in curl+openssl?

From a technical perspective, yes, though I can't say whether Apple would reject an app because of it.

> Are iOS apps even allowed to open raw TCP sockets?

Yes.

</comment></comment><comment><USER26> Apple's own services make extensive use of plaintext HTTP. Even if they're only doing so in ways that are safe (due to other application layer encryption mechanisms like in iMessage) it's hypocritical for them to enforce a requirement on 3rd parties that they themselves cannot meet.

<comment><USER27> Can you give an example of this? I've been using charles proxy for various tasks a bunch on my iPhone, and so far it seems that all the calls to Apple that I've noticed are HTTPS.

<comment><USER26> Here's a partial list from my Little Snitch config on macOS Sierra:

\- com.apple.geod.xpc tried to establish a connection to gspe19.ls.apple.com on port 80

\- App Store / softwareupdated uses port 80 to download updates from swcdn.apple.com

\- helpd uses port 80 to fetch help docs from the web

\- IMTransferAgent tried to establish a connection to ussjc.ce.apple-dns.net on port 80. This is used by Messages.app when picture messages are received.

\- iTunes uses port 80 all over the place to fetch content from the mzstatic CDN and others

\- nsurlsessiond uses port 80 to fetch from apple-dns.net, blobstore.apple.com, icloud-content.com, aaplimg.com

\- photolibraryd via com.apple.photomoments.xpc tried to establish a connection to gspe21.ls.apple.com on port 80

\- Photos Agent tried to establish a connection to s3-w-a.us- west-2.amazonaws.com on port 80

\- storeaccountd tried to establish a connection to sandbox.itunes- apple.com.akadns.net on port 80

\- storedownloadd tried to establish a connection to osxapps.itunes.apple.com on port 80

\- SpotlightNetHelper tried to establish a connection to wu- calculator.apple.com on port 80

<comment><USER28> FYI, some of those are due to content being non-secret + already digitally signed and wanting to assure they can be served from the "Cache Server" within enterprises to help speeds.

</comment></comment></comment></comment><comment><USER29> Speaking of Transport Security, last night I got bitten by the removal of OpenSSL headers in Xcode in favor of their own "-framework security" aka Secure Transport.

<comment> X-Istence Apple has had deprecated on the OpenSSL headers for a couple of releases now...

</comment></comment><comment><USER30> Friend of mine works at a really REALLY big bank. Works on their iOS app and their SSL cert is long expired.

The iOS client does certificate pinning, so it isn't a huge security concern (although revocation would be a nightmare), but it does not surprise me that people are afraid of supporting TLS only for their apps.

<comment><USER28> That is fine though. ATS just ensures you are using TLS v1.2 and such, but doesn't enforce expiration / CRL / trusted roots / etc. That would be done in app, usually using default built-in frameworks but sometimes with custom logic to do things like certificate pinning.

</comment></comment><comment><USER31> I think at least NSURLSession is forcing HTTPS currently.

<comment><USER20> You can disable that by adding a key to your Info.plist.

They mean at the App Store submission point. In January, they were going to start rejecting apps that didn't provide a justification for completely disabling ATS.

</comment></comment><comment><USER32> I expect the likes of Facebook, Microsoft to already be ATS-ready. But it has been my experience that Unreal Engine 4 and Unity are not. Its probably the big game makers of the App Store that are influencing this delay.

<comment><USER33> Try media companies. We have been working to make our television companion apps ATS-compliant. All our advertising / analytics / streaming endpoints had to be HTTPS. We ended up with a list of dozens of domains from over 10 external companies (mostly related to video ads / streams) that still had to be made available over HTTPS, or we'd have to get exemptions for those domains.

We're still going on with our efforts to make everything go over HTTPS always, but this does take the pressure off a little. We were really fearing not being able to submit updates in early 2017 because of ATS.

<comment><USER20> We have similar clients. They insist every app must have at least 5 different analytics/ad providers and god knows what else.

I was honestly kinda looking forward to January because it would force them to re-evaluate some of the shittier providers so they could get app updates out.

</comment></comment></comment><comment><USER34> In other news, rumours report that the next iMac will reintroduce the floppy drive</comment>


Grouparoo: Open-source app to sync customer data with 3rd party tools - <AUTHOR> https://www.grouparoo.com <comment><USER2> Thanks for checking us out! Co-founder here, happy to answer any questions. There is so much to do in this space, but we're excited to be getting started.

No engineer wakes up in the morning excited to sync data to Marketo, so we started there - `npm install` and so you can get back to building the core product. We make data self-serve for your non-technical colleagues and we handle all the exhausting integration stuff you don't want to think about (API nuances, rate limiting, retrying, batching, etc).

<comment><USER3> First, thanks for providing the `npm install` way to run it. Too many apps require Docker and that's it.

Question: Could we use Grouparoo to replace mixpanel? Would we need to build the client side to collect events and dump that into Grouparoo?

<comment><USER2> At the moment, it depends what you are using Mixpanel for. If it's about collecting events and storing them, then we have a JS web library [1] for that and we'll happily store them in our database and let you do things with them. It will handle anonymous users and convert/merge them when they log in.

[1] [https://www.npmjs.com/package/@grouparoo/client- web](https://www.npmjs.com/package/@grouparoo/client-web)

</comment></comment></comment><comment><USER4> Wow, this is exactly what I started looking for at the start of the day.

Unfortunately I can't use it yet as there's no Postgres SSL support - filed a GitHub issue here: [https://github.com/grouparoo/grouparoo/issues/734](https://github.com/grouparoo/grouparoo/issues/734)

<comment><USER2> Thanks! That should be an easy one. What was your goal when you started the day? :-)

<comment><USER4> Syncing our customer user data to Zendesk without having to write our own syncing service.

<comment><USER2> Sounds perfect for us. We have some questions on that issue. Let's make it happen!

</comment></comment></comment></comment><comment><USER5> At a glance, this looks cool - im in the middle of designing an internal Customer Data Platform/Single Customer View to serve as a single data source for various internal & external marketing tools. Looks like this might be worth looking at.

Does it have an API to access the user profile and group data ad-hoc?

Can you stream data in?

Can it trigger a destination sync when the underlying data changes?

Can it do profile merging (visitor -> known customer stitching)?

How can you do reporting/analytics?

<comment><USER2> Great questions, thanks!

> Does it have an API to access the user profile and group data ad-hoc?

We've seen a few approaches here. 1) Yes, there are APIs 2) The Postgres database this runs on is in your data center, so you can read it directly 3) You can write back to your own product database as a "destination"

> Can you stream data in?

We support events via an API. We'll store the vents and allow your to create profile properties from them. I'm very interested in creating a Kafka or other message bus sort of integration too that brings in data and/or triggers recalculations. No one has needed that yet, though, so it's just on our eventual list.

> Can it trigger a destination sync when the underlying data changes?

We have schedules, table queries, and events to know profile data has changed. When it changes, it then recalculates groups. Then properties or groups change that are being sent to a destination, it automatically exports there. "Hey Mailchimp, the user changed their first name and should now be tagged as VIP."

> Can it do profile merging (visitor -> known customer stitching)?

We have the concept of anonymous id before login. When we realize two profiles are the same (usually after logging in from another device or something), the profiles are merged and everything recalculated.

> How can you do reporting/analytics?

This hasn't been a focus so far outside of our ETL mechanics. You can see who has been imported and exported and with what and when and all of that.

Things get more interesting around properties and their values, but we haven't gotten there yet. We've seen some success at pointing tools like Metabase at the Grouparoo database.

<comment><USER5> Cool thanks, just installed it now to have a look. Any timeline for when S3 and Redshift will be available as a source & destination?

<comment><USER2> Let me know how it goes: brian [at] grouparoo.com

Redshift is available now. We've talked about S3, but were looking for input on what kind of formats to read/write. Email me or make an issue [1] with what you were hoping for.

[1] [https://github.com/grouparoo/grouparoo/issues/new?assignees=...](https://github.com/grouparoo/grouparoo/issues/new?assignees=&labels=enhancement&template=feature_request.md)

</comment></comment></comment></comment><comment><AUTHOR> I worked with the Grouparoo guys years ago at TaskRabbit. They're a super impressive team. Excited to watch their progress with Grouparoo!

</comment><comment><USER6> Oh wow, this reminds of Hightouch ([https://hightouch.io](https://hightouch.io)) and Rudder ([https://rudderstack.com](https://rudderstack.com)). It's interesting that all of these are positioned around data warehouses, which is generally very messy to deal with.

<comment><USER2> Thanks for the links.

Overall, there's an interesting organizational dynamic that we've seen around data enablement. Marketing and other operational teams need it and it's often locked in the product space. It's usually not a priority for the eng team because they are focused on the core product, but the data is there. The important stuff (ETL copy of the product db) is usually not a huge mess.

We are inspired by warehouse tools like Looker that made that accessible to more people, giving them autonomy to be successful. Grouparoo takes that one step further to add on top of the data and make it actionable in all the other places that people want it.

<comment><USER7> In my experience this scenario is very accurate. Add to it the growing usage of tools like Pipedrive, Pipefy, Airtable, that sometimes prod-eng team is not even aware.

As a Rudder and Fivetran user, I can see a very complementary use case for Grouparoo. Where the first two are responsible for unifying events and external data in the DW and Grouparoo to sync user data to other tools.

Two other tools that I saw in this space (not Open Source): [https://www.calixa.io/](https://www.calixa.io/) [https://windsor.io/](https://windsor.io/)

<comment><USER2> Overall, we believe events are an overused approach in this space. They clearly have their place for impression data, but product dbs or data warehouses have lots of good stuff that isn't being used enough to drive goals. Then there's all the issues with getting that right in these other tools that no engineer wants to deal with (rate limiting, formatting, schedules, idempotency, etc).

So I hope there's a place because it's the gap we saw and are hoping to solve and share with the community. Email me if you want to chat more: brian [at] grouparoo.com

</comment></comment></comment></comment><comment><USER8> Grouparoo made it dead simple to connect a mysql database and generate information. Easy to Install and Integrations make it easy to send the right data to each tool you use. No code is necessary to change what data gets sent.

</comment><comment><USER9> Very cool to see. A lot of folks (Notion, Figma, Loom) use our service ([https://getcensus.com](https://getcensus.com)) for this purpose if folks are curious to check out a SaaS version of the concept.

We support all the major data warehouses (incl. straight Postgres), connect to a bunch of different applications, and don't store any of your customer data!

Bonus: we recently added native support for dbt :-)

</comment><comment><USER10> I had a demo of Grouparoo a few weeks ago -- super cool platform that solves so many ETL / integration challenges.

</comment><comment><USER11> This was such a massive problem at the large company where I used to work. Excited to see the progress!

</comment><comment><USER12> Congrats guys from the team @ RudderStack. Glad to see more open-source products in this broad customer data space.

Is it fair to say this is more like the Segment personas's product? We see a bunch of use cases for personas (which we don't have in RudderStack) so can point to you guys.

Congrats again on the launch.

<comment><USER2> Yeah, the group-building part and syncing those (for example to Static Lists in Marketo) is like Personas. It was always funny to me that you had to pay quite a bit for Personas for Segment to actually, you know, segment.

The gap we saw was around understanding the user and segmenting in a way that could be shared across multiple services and the product. And doing so in a way where you controlled the data and the total cost was managed.

It's nice to see there are others open in this space. The trends are certainly in the open direction to provide a lot of value and control in a way that's good for everyone.

</comment></comment><comment><USER13> Can't wait to try this out sometime soon. I've worked with all the founders and they're awesome.

</comment><comment><USER14> What if I need to store all user data (not limited to profile information) in google sheets and I provide only an interface for an specific usage. I cannot see how good this scenario fits. Use cases are quite simple

<comment><USER2> Everything in Grouparoo is somehow tied to a user, so if you have a list of "locations" or something, that's not a good fit at this point. We basically need a "foreign key" to a property of the user.

If you do have that, we have support for google sheets[1]. You share a sheet with a service account and that allows it to be a source in Grouparoo. From there, you can make groups and send to destinations.

We'd be curious about your use cases. Feel free to make an issue[2] with what you are hoping for and we can discuss there.

[1] [https://www.grouparoo.com/blog/google-sheets- source](https://www.grouparoo.com/blog/google-sheets-source)

[2] [https://github.com/grouparoo/grouparoo/issues/new?assignees=...](https://github.com/grouparoo/grouparoo/issues/new?assignees=&labels=enhancement&template=feature_request.md)

</comment></comment><comment><USER15> I've worked with the founders in the past and they're legit! I'm excited to see where they'll go with Grouparoo.

</comment><comment><USER16> Looking forward to tracking this project. I totally get it.</comment>


Getting started with Tmux - <AUTHOR> https://linuxize.com/post/getting-started-with-tmux/ <comment><USER3> Some more resources for learning more about tmux:

\- The Tao of tmux [0]

\- A minimalist guide to tmux [1]

\- Benefits of using tmux [2]

\- tmux shortcuts & cheatsheet [3]

[0] [https://leanpub.com/the-tao-of-tmux/read](https://leanpub.com/the-tao-of- tmux/read)

[1] [https://medium.com/actualize-network/a-minimalist-guide- to-t...](https://medium.com/actualize-network/a-minimalist-guide-to- tmux-13675fb160fa)

[2] [https://blog.bugsnag.com/benefits-of-using- tmux/](https://blog.bugsnag.com/benefits-of-using-tmux/)

[3] [https://gist.github.com/MohamedAlaa/2961058](https://gist.github.com/MohamedAlaa/2961058)

<comment><USER4> I really liked the Tao of TMUX.

I also made a very succinct cheatsheet for tmux (along with a list of all the other key CLI commands for full stack engs):

[https://github.com/nemild/cli_for_full_stack#user-content- tm...](https://github.com/nemild/cli_for_full_stack#user-content-tmux- terminal-multiplexer)

</comment></comment><comment><USER5> Tmux is another one of those tools whose siren call I'd avoided for a good decade, continuing to rely on GNU Screen. Then, for the last time I reconnected to a split screen and screen lost my splits and tabs - it was enough for me.

Two years ago I finally changed over and I haven't looked back. At this point, when I encounter something where I only have screen I'm rather annoyed by it - and I've set my tmux key mapping to basically mimic what I've been using screen for the last 20 years.

For me, tmux replaced every single feature that I used in screen. On the other hand, I'd be genuinely happy if it existed on the older OSes I randomly have to frequent, even if it's understandably impossible.

<comment> another-cuppa Is tmux actually more reliable in this respect or have you just been lucky so far? I had a screen session running for three years with no problems.

<comment><USER6> I have a tmux session that's been running for almost a year with no problems. I don't know how long it will run, but perfect performance for almost a year is good enough for me.

My session has 8 tabs, and one of the tabs (my primary) has 14 sub windows (frames?) showing all kinds of good busy information.

</comment></comment></comment><comment><USER7> My favourite little tmux trick is in ~/.tmux.conf:

`bind r attach-session -c "#{pane_current_path}"`

All the terminals I open start a new tmux session (left as an exercise to the reader). I change directory to whatever project I'm working on, hit `C-b r` and from then on all panes and and windows in that session will start in the correct directory. Saves me a lot of cd'ing.

<comment><USER8> Ohhh, thank you! One of my biggest annoyances so far was exactly this - <USER2> time I split off a new pane, I'd have to cd back to wherever I was working.

<comment><USER9> If you want the directory to come from your current pane instead of the current session, it's a little easier:

      bind '"' split-window -v -c "#{pane_current_path}"
      bind % split-window -h -c "#{pane_current_path}"

[https://github.com/mfarrugi/.dots/blob/master/tmux/.tmux.con...](https://github.com/mfarrugi/.dots/blob/master/tmux/.tmux.conf#L24-L25)

</comment></comment></comment><comment><USER10> tmux was an absolutely game changer for me. At first I thought I was fine just being really comfortable with shortcuts and splitting commands with my favorite terminal emulators but tmux along with tmux plugins ecosystem[0] is really a world of difference, and much better.

I haven't gone so far as to change my default shell to tmux in the terminal emulator I use, for the sole reason that I imagine that I just don't need tmux _every single time_. In reality, 99% of the time the first thing I do when I restart my computer and open a terminal and run `tmux`, and start setting up my workspaces based on what I've been doing, naming windows, etc.

The top two features I use every day:

\- keyboard-only selection + cut & paste between panes (yes, piping to xclip is good, but it's nice when you can just enter the right tmux mode, use emacs/vim keybindings to go up and copy out some text)

\- easy/instant resizing and organizing of panes

\- naming/breaking/moving/combining panes, to focus my efforts (something as simple as naming a window appropriately focuses my efforts inside that window)

An example of this is working with tools like `kubectl` that generate randomly named components that I have to list out @ the command line and do operations on, most of the time when I watch people deal with this in talks, they have to go and double-click-select or type things out.

[0]: [https://github.com/tmux-plugins](https://github.com/tmux-plugins)

<comment><USER11> Check out tmux-fingers by morantron. It lets you copy any line that matches a pre-defined regex. I just recently got a PR merged that supports kubernetes resources. So now I don't even have to click the line (in mouse mode) and then hit shift+4 and yank, instead I just hit prefix+F and then the corresponding letters that appear.

Kinda hard to explain, but it'll make sense if you look at the gh repo.

[It's always driven my insane how kubernetes names its pods. They still haven't implemented regex matching - there's an issue on github related to that that went stale. For now I use a combjnation of selectors and old school unix regexes (awk, grep, etc) when I'm passing around kubectl commands that I need to work rgardless of whether the container has restarted or not]

<comment><USER10> Thanks for the tip! Usually since I've just run a `kubectl get pods` or whatever I use the keyboard navigation to go up a few lines, ctrl+a and use the emacs bindings to yank...

I just downloaded and installed tmux-fingers with tpm, but it's doing a pretty terrible job of picking up on the right things... I'm assuming i need to put in the predefined regexes that would match pod names/ lines of the get output?

<comment><USER11> It works for the output of kubectl get all, not kubectl get po unfortunately. [This is because without the resource name as a prefix, there's no general regexes that will work for everyone's situation] As a hack I sometimes end up doing kubectl get all | grep 'pod/', which is a little inelegant. You can add your own regexes (see the readme of tmux-fingers, you do @fingers-pattern-0 your_regex) and then reload the config

Realistically I suppose it's only marginally faster than kubectl get po -o name and then manually copying.

For any project I work on frequently I set up aliases that wrap it anyway. As you already know kubectl doesn't allow regex matching so I just do something like: kubectl delete pod "$(kubectl get po -l app=MY_APP_SELECTOR)", etc. naturally your deploy needs granular selectors otherwise you need to further pipe to grep or awk

</comment></comment></comment></comment><comment><USER12> I find both tmux and Gnu Screen difficult to config (haven't taken the time to learn) but I love the concept of them so I use Byobu ([http://byobu.co/](http://byobu.co/)) on top of tmux/screen to set common configuration for you. Byobu really lowers the amount of config and barrier to entry because Byobu uses common hotkeys. For example F2 for new window.

<comment><USER13> I never saw the need to configure tmux.

I have tried to configure bash for better use it (including launching it automatically) but then gave up due to not enough gain. But I never saw a need to configure tmux itself.

I can't say the same about screen. At a minimum, there's an inherent incompatibility between it and emacs.

<comment><USER14> Emacs works perfectly well for me inside screen, but not inside tmux. In tmux, many of the extended keys aren't quite right.

I run urxvt.

I also have custom fixes for rxvt that I've built up over the years, both a custom terminfo file, and fixes for emacs' terminal mapping.

I'm willing to bet your "inherent incompatibility" is a terminfo or similar terminal code interpretation problem.

<comment><USER15> I also run screen emacs and urxvt. For what it's worth I choose screen over tmux mostly because I've worked fairly hard at keeping most of my stack gpl.

</comment></comment></comment></comment><comment><USER16> I must admit I'm a screen guy. I feel not at home when I find a system without screen and I miss the "killer feature" of connecting to any tty at any baud rate

      screen /dev/ttyUSB0 9600

in tmux. But recently I tried to switch to tmux and found a few useful configurations.

1) I have alacritty as a terminal so no scrollback and no tabs (yeah there is a scrollback branch, but why duplicate functionality?) So my default setup right now is that alacritty (I use i3 so alacritty is bound to meta+enter) opens with this line (this way only one terminal can be opened and has always the same state)

      tmux attach -d -t alacritty || tmux new -s alacritty

So I got scrollback and tabs. Also I added

      bind-key -n C-t new-window
      bind-key -n C-PPage previous-window
      bind-key -n C-NPage next-window

to the config so I can use it like any normal terminal with ctrl+t (new tab) and ctrl + pgup/down to switch between them. In theory I could even add shift with (C-S-t), but this somehow doesn't work for me and I found conflicting information on it and some outdated infos so I just stopped looking.

The second configuration that I like to use is what everybody uses

2)

      unbind C-b
      set-option -g prefix C-a
      bind-key C-a send-prefix

to change the prefix to the sane ctrl+a screen default.

Also setting colors is a must for neomutt and co

      set -g default-terminal "tmux-256color"

I'm still experimenting with configs for my desktops and servers, but I'm feeling a bit more at home with tmux right now.

Oh and for anyone who doesn't know of byobu check it out [http://byobu.co/](http://byobu.co/) it's a wrapper around screen and/or tmux and is easy for beginners and a nice change for everybody else.

<comment><USER17> Just out of curiosity why is ctrl+a more sane than ctrl+b?

<comment><USER16> Like I said I'm a screen guy so I'm used to ctrl+a and I got my keymap remapped so that caps lock is ctrl so ctrl and a are right next to each other b is in the middle of the keyboard and I find it irritating having to press ctrl and b.

Also I don't use ctrl+a but the home key so I'm missing nothing.

</comment></comment></comment><comment><USER18> One feature that I really like on my Mac was iTerm2's persistence (tabs and outputs preserved across reboots). This is particularly important where I live because we have frequent electric outages.

I now have something on Tmux with [https://github.com/tmux-plugins/tmux- continuum](https://github.com/tmux-plugins/tmux-continuum) .

That's one of the best things about Tmux: there's generally a way to get it to do what you need it to do. Or something close enough.

<comment><USER19> Cool I didn't know ITerm2 was persistent across reboots. I like it because it supports inline matplotlib plots both locally and remote SSH connections.

</comment></comment><comment><USER20> One issue I have with tmux is that you can't resize the window to the current device. The developers seems to be very adament that it isn't implemented.

Currently tmux will adapt the size to the smallest (on each axis) client. This doesn't work well with persistent connections from a phone and PC since they typically have quite different window sizes.

In screen I hit ctrl-a + F to resize to current client and I miss it every time I use tmux.

Unfortunately I still prefer tmux, worth trying out if you haven't!

<comment><USER21> Maybe I'm not understanding, but if you attach to a tmux session with the -d flag, it will detach the session from any other clients and resize it to the window you're using.

<comment><USER20> Yes, and maybe that is the reasonable thing to do, but I don't want to detach.

<comment><USER13> When an application queries the screen size from ncurses or some other lib, what value do you expect it to get?

I don't think it's a reasonable requirement.

<comment><USER20> I'm very happy with screens implementation. It will stick to the size of the first client and you override it at will in any other client or if you want to update the size (maybe you changed the size of the window).

<comment><USER13> Oh, that's reasonable. Sorry.

</comment></comment></comment></comment></comment></comment><comment><USER22> I use a macOS laptop with iTerm2 to connect to a remote tmux server running on Linux, and the iTerm2-tmux integration [0] is pretty great if you like multiple panes per window. I don't have to mess with mouse mode for straightforward pane resizing, buffer scrolling, or copy/paste text in the buffer. I recommend taking a look if you're typing on a Mac.

[0]: [https://www.iterm2.com/documentation-tmux- integration.html](https://www.iterm2.com/documentation-tmux-integration.html)

<comment><USER23> I never learned the "real" tmux and always using `tmux -CC` and `tmux -CC attach` on a iterm. Anything else you do differently in your workflow?

<comment><USER24> Use it with autossh for automatically reconnecting during computer standby / internet drops. I used to use Mosh + TMux for super durable connections and that worked beautifully. Unfortunately Mosh doesn't play well with ITerm's native integration so you can achieve a poor man's Mosh by using [http://www.harding.motd.ca/autossh/](http://www.harding.motd.ca/autossh/).

All-together it looks something like this: Open iTerm. autossh -t myRemoteHost "tmux -CC -A"

</comment></comment></comment><comment><USER25> I'm using tmux myself for persistent shells on remote machines (mostly irc), but not much otherwise. Lots of people and guides make it sound like it's also very useful when you're working locally. Can someone enlighten me what tmux can do for you in this case that people are so excited about it?

<comment><USER26> I used it locally on a project where I really needed 5-7 shells opened in specific folders and some of them running specific things. Tmux made it easy.

</comment></comment><comment><USER27> My tmux conf: [https://github.com/EverettBerry/dotfiles/blob/master/ubuntu/...](https://github.com/EverettBerry/dotfiles/blob/master/ubuntu/.tmux.conf)

I especially like prefix + & to kill the whole window, prefix + , to rename window, and prefix + ":break-pane" to split the current pane into a new window.

</comment><comment><USER21> I like to be able to attach to my customary sessions quickly, or reinstantiate them quickly in case of reboot etc.

I use something like the following in my .bashrc:

      alias f='tmux attach -dt f || tmux new-session -s f'

That way I can recreate or attach to my usual session(s) without even taking my hands off home row.

</comment><comment><USER28> To those who use a tiling window manager: how do you incorporate tmux in your workflow? Since I've mainly used tmux to show multiple terminal sessions at once, I found it to be redundant in a tiling wm environment. But I'm sure I'm missing out on other features that my wm cannot provide.

<comment> another-cuppa I use a tiling WM and I use screen solely for the detaching functionality. It means I can restart X without restarting things like irssi.

</comment></comment><comment><USER29> Is it possible to have tmux allow mouse scroll in your active window? I always have to press CTRL+B to enable it which is such a pain. This is the only thing that slows me down when using tmux.

<comment><USER16> > set -g mouse on

I think in older versions it was called mouse-mode,

</comment></comment><comment><USER6> I probably know about 5% of tmux, but I freaking love it. I've had a tmux session with 12 sub-windows running on a server for 300 days. I connect to it daily, from different machines. It works. It does everything.

I have no desktop application that performs at this level. So my hat's off to the tmux developers. Like many other great open source tools, it's a critical part of my toolset.

</comment><comment><USER30> I do things like:

      - nest tmuxes (up to three levels, with different prefix keys for each level)
      - one tmux session per workspace (git clone, whatever)
      - cscope on window zero of any workspace session
      - use a CSCOPE_EDITOR that starts $EDITOR in a new, appropriately named tmux window in the same session, and returns control to cscope
      - script the setup of my main session

</comment><comment><USER31> My biggest complain about tmux is a change they made a few months ago, where they decided to show all the windows by default instead of only showing those in the current session. Even if you filter the sessions to show only those in the current session, it's still not the same way it used to be. For that reason, I have stuck with an older version. \rant

</comment><comment><USER32> > You can detach from the Tmux session and return to your normal shell by > typing:

> Ctrl+a d

Looks like someone uses 'Ctrl+a' as his personal prefix and forgot to replace it in that part of the blog post ;-)

Background: I use 'Ctrl+a' myself (and hate it that tmux uses Ctrl+b by default).

<comment><USER33> The trouble is that I use both the Ctrl-a (increment number under cursor) and Ctrl-b (scroll up) shortcuts in Vim pretty frequently. It gets annoying to remember to have to double-press that shortcut if and only if I happen to be using Vim inside Tmux.

<comment><USER34> Yep. Ctrl-a has been move-cursor-to-beginning-of-line forever. It was too bad that screen selected it at the beginning.

<comment><USER35> I rebound prefix to control-\ for this reason.

Yeah, it's two handed but seems to have a nice rhythm to it for me (caps lock is control).

</comment></comment></comment></comment><comment><USER36> In tmux, is there a way to make the logical screen larger than the physical screen - so you can (1) scroll around to see the whole screen, and (2) view different parts of the logical screen in different terminals?

Useful for mobile devices with small screens.

</comment><comment><USER37> Might as well take the chance to ask here:

Is there a way to get the count of total tmux sessions being run on any machine, for all users?

I can do "tmux ls" but that only returns for the current user.

</comment><comment><USER38> Wow conveniently enough I've been trying to get started on a Tmux & Vim environment and I've been running into walls on Tmux related guides.

</comment><comment><USER19> That was a really good write up on tmux. I have used tmux for years but use it simply, every few months looking up something on DuckDuckGo as needed.

</comment><comment><USER39> I only started using tmux like half a year ago, and now it is the first thing I start when opening my terminal.

Really improves development with cli tools.

</comment><comment><USER40> My favorite feature is the mouse support, which makes the window names in the status bar clickable, even while logged on remotely.

</comment><comment><USER41> What's everyone's preferred tmux prefix key?

I use Ctrl-J. So many C-* keys interfere with Emacs / readline.

<comment><USER42> C-o for me, for exactly the same reason

<comment><USER43> I have a nested setup with a "meta" screen session with escape key ^Z, which holds named "project" screen sessions with escape key ^O.

I background tasks in the shell seldom enough (because I'm always in screen) that I don't regret ^Z being slightly less convenient. ^O is a fairly unknown but very useful insert-mode binding in vim, but I use emacs these days so I don't notice it being escaped.

Before I used separate escape keys, it was maddening trying to remember how many times to hit ^A to send commands to which nested session.

<comment><USER41> C-o is moderately useful in emacs to move your current line down while the cursor stays on the newly created line.

</comment></comment></comment></comment><comment><USER44> Minor mistake, for detach, it's ctrl-b d by default, not ctrl-a d which is screen's shortcut.

</comment><comment><USER45> I've been using tmux and vim since 2012 and haven't looked back. it's wonderful!

</comment><comment><USER46> «tmux a -t 0» > «tmux attach-session -t 0»</comment>


Yes, you can now sue a 4-year-old for negligent bike riding - <AUTHOR> http://blogs.wsj.com/law/2010/10/29/4-year-old-not-too-young-to-get-sued-manhattan-judge-rules/

<comment><USER2> There's never such a thing as a coincidence, everything that happens is ordained and brought about by mystic forces.

There's never such a thing as an accident, someone always needs to be at fault and punished.

Some people tut, sigh, and shake their heads, but it seems inevitable that people will try to assign blame and receive reparations for what in earlier times would have been called accidents. Insurance companies get away with clauses about "Force Majeure," but they have money to make sure the law-makers listen to them.</comment>


Copyright questions as 3D printing comes of age - <AUTHOR> http://arstechnica.com/tech-policy/news/2011/04/the-next-napster-copyright-questions-as-3d-printing-comes-of-age.ars

<comment><USER2> Sometimes, I wonder if we should even be discussing this.

I'd hate to see the copyright industries manage to kill 3D printing research with crazy laws before it gets very far.

<comment><USER3> I doubt they could, actually - all they would be able to do would be to move the research out of the US and Europe. When the technology is good enough, the law makers will be forced to allow it back in again or the US will not be able to compete. Then ordinary people will demand access to these printers and it's over.

</comment></comment><comment><AUTHOR> Great article by Ars. I feel like they're one of the few blogs I read that regularly writes great original content. Virtually everything else I see seems to be weak journalists spinning on press releases spoon fed to them.

</comment><comment><USER4> I wonder how far are we from the inevitable clash of ideologies as shown in Cory Doctorow's Printcrime:

<http://craphound.com/?p=573></comment>


Ask HN: What would the most efficient manner to build an online dating site? - <AUTHOR>

Anyone know if there are any Rails, Django, or CodeIgniter premade packages which I could just theme, update and tweak? I'd even consider buying some code to make it faster. <comment><USER3> There are various premade dating site systems that can be found by googling (mostly non-free). Similarly, a search for "ruby on rails dating site" turns up an open source social network, <http://lovdbyless.com/> , which might be a good place to start.

However, the important question isn't how to get the code for the site working, it's how to get a community established. _No one_ wants to be one of the first people using a dating site, because then they can't find anyone else on it. The value of a dating site increases with the size of the community, because that makes it more likely that a user will find someone who is compatible with them. The market is pretty saturated right now, and it would be hard to compete with the larger players unless you have a very compelling secret sauce (which it doesn't sound like you do). There's probably still room for very niche sites, but if you're not a member of a niche it might be hard to get adoption.

If you don't have a compelling answer for how you're going to get users - <USER2> nothing with the words "viral marketing" in it counts - stop until you do.

<comment><AUTHOR> Thanks for the comment. I personally would never want to create one but somebody has offered me what i consider very good money to make one that would leverage the same code base an online dating site would. wondering how efficiently I could do it.

</comment></comment><comment><USER4> You might also take a look on Flippa for something which has been started and has potential. Perhaps you might find someone offloading a site which he/she simply doesn't have the time for but gets decent usage.

<comment><AUTHOR> Thanks - good idea!</comment></comment>