moreentropy

I've been a Unix admin for a long time, so for me depending on all those external services with unpredictable performance/colocation/reliability sounds risky and complex.

Is it considered that hard and expensive to just run a full backend stack on your own machines, be it on dedicated servers or AWS etc.? I guess it might even be cheaper to have someone do a professional server setup for you instead of having to deal with all those service providers.

I think it's good when it hurts.

It's better to struggle with the hacker news treatment early on and learn to cope with traffic spikes than have the same problems when your site gets mainstream coverage.

Great stuff. Came to post that one.

Wow, great guide to some seemingly awesome tools I didn't know until now.

I love posts like this, well written and easy to understand. This show that finding vulnerabilities is not magic for some ubergeeks but straightforward analysis with a bit of trial and error.

Add http://openvolte.org/ and you have a voice network as well.

A real response would be "we blocked this app because $reason". This is just corporate BS. Great experience my ass.

You might want to read that linked statement again. The BSI criticizes the sensationalist wording and generalization ("bad for all users") in the Die Zeit story, but emphasizes the key point that it's unacceptable for critical infrastructures to give up full control over your own systems by being forced to use TPM 2.0.

Apart from the Adaptive Media Streaming feature, all the "plus" features seem to be stuff that anybody can have with the open source version and some external scripting/integration:

* Application Health Checking -> Nagios * Monitoring -> stub_status_module + Munin/Nagios * Advanced Load Balancing -> Chain Varnish / Nginx * Dynamic Configuration -> Seamless configuration reload without service interruption is possible in the open source version * High Availability -> Pacemaker or whatever...

That's stuff that high traffic sites have covered themselves. But: Many normal Enterprise IT ops won't touch Nginx with a stick if they can't pay for it and have someone to blame should things go wrong. Plus, managers love shiny dashboards, buzzword features and fact sheets like http://nginx.com/media/cms_page_media/21/nginx_plus_datashee...

Everybody wins.

I also feared I'd have a problem switching between vi(m) and other editors, but if you use both regularly, It's not a problem at all, at least for me. I'm heavily using Sublime Text for software development. Sublime has a "vintage" vi mode which I don't use, just to train my muscle memory on modeless editors.

It's the same with keyboard layouts. I've been using german keyboards all my life and just decided to switch to us layout a few years ago, because basically the keyboard layout had a huge influence on programming languages, stuff like []{}/<> is way easier to type on us layout. I feared i will never be able to use a german keyboard again after switching layouts, but this is not the case. I can now use both layouts blind. The only problem are the () parentheses which are offset by one key on the german keyboard, i'll always press the wrong key for them.

Yes, it's this one: http://en.wikipedia.org/wiki/File:Connector_USB_3_IMGP6033_w...

The socket is compatible to normal Micro USB plugs while the plug is not.

Another point: AFAIK the Mico USB connector is designed so that if you apply force from the side to a plugged in connector, the plug will deliberately break and the socket/pcb will stay functional.

Edit: I can't relate to those who say Mini USB is more reliable than Micro USB. I've had a lot of trouble with Mini USB connectors and especially cables, especially if I move a connected device i've had lots of short disconnects. This never happened with Micro USB. So.. go Mico USB!!1!

He should have skipped all the effort to enable SSL in Tomcat and put the certificate in his front-end webserver. Cause that's where it belongs.

This.

I expect my ISP to never, ever fuck with the application layer. Do your job and route my traffic, thanks.

There is no valid reason to pass traffic through the filtering system if a customer has opted out and won't be filtered. This costs real money to the ISP, so I presume they analyze that traffic. It doesn't matter if they pretend to do this to train the filter or feed some agency's data warehouse, this is madness.

Guys, Git and Github are just tools. Even if Git nerds would like you to think that software can't be developed without github, it worked before.

We had sourceforge, berlios, tigris.org etc. for years if you like your project hosted. Then there's Trac, Redmine etc. Otherwise you'd set up a Mailman for mailing lists and subversion as source code repository. If someone attaches good patches to mails and/or gives valuable input to the project, he usually got write access to the svn repository.

I'm not even sure that the Github way of developing OSS is that much of an improvement. Too often people rather fork than contribute. You'll find a dozen forks of the same software where different people fixed various things, half of them abandoned a long time ago and none of them usable.

As today seems to be advertising day, I'll plug HostEurope, http://www.hosteurope.de/, another large german datacenter operator from Cologne.

I've got a virtual server running there flawlessly for the last five years. Customer service is amazing (all communication is english and german), and I can only remeber one single downtime for a few hours in all the years.

Tell that to my ISP. :(

You can't call it "everything" if you keep Gmail.

Personal email would be the most important service to get under your own control, and it's the hardest of all problems to solve.

I'd blame the building's electrical and HVAC systems. Steam pipes, AC condensers, engines, pumps etc.

This is hardly news now is it?

I'm afraid the actual definition of "meta-data" is up to interpretation in the context of IP communication.

What if the NSA considers not only IP source & destination as "metadata" but also anything down to the application layer that is not strictly content? Like the HTTP GET line or HTTP headers.

Data on intra-european transactions and matters is often deliberately shared with the US for intelligence purposes OR is processed by companies in the US, which automatically means that it is used by the US for intelligence.

So, if I use Gmail as a non US citizen, I have to assume that the US government will read/analyze my emails. That's a well recognized fact that I've also been told by people working with classified (German) government data on multiple occasions.

Examples: http://epic.org/privacy/intl/passenger_data.html http://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank...

I guess I'm used to a more technical definition of "can't" than politicians nowadays.

Apart from that, I'm German, and every time I read this "not to US citizens" excuse, all I understand is that they'll happily rape all my data without any questions asked.

[citation needed]

Been there. Great talk. It wasn't whiny at all, more like this is stuff we have to work on.

Mmm Belgian beer.

Nothing free that i know of. But that's certanly a good idea.

The whole industry is going crazy about automated deployment and devops stuff. So maybe someone could create a repo containing puppet configs that can set up a "best practice" full stack modern mail server. Don't even have to call it a distro.

I don't get most of the stuff myself. PKIs are overwhelming. There are thousands of flags you can set when creating a certificate it's not funny anymore. I did a lot of trial and error until i had a VPN using my certificates running successfully (that's what i needed the CA for in the first place).

Maybe look for CA stuff in general or some TinyCA tutorial. I've used TinyCA, it's exactly the same complexity as XCA, although I like XCA's UI better.

I'm in the process of moving more stuff to a self hosted server right now. Sadly, this is almost impossible if you're not a seasoned sysadmin or willing to learn a lot.

My setup looks like this:

Mail: Postfix/Dovecot/Roundcube

Setting up a Mail server is the hardest part i think. It's essential to implement measures against spam and abuse. In my setup, this includes: - Get a valid certificate for your mail host and enable opportunistic TLS for SMTP and SMTPD. - Implement DKIM and SPF (and DMARC, http://dmarc.org/) - Use Blacklists: policyd-weight, but look out for changes to public RBL services - Reject Spam in the SMTP session using Milters, never bounce SPAM. - Use spamass-milter and clamav-milter to Filter unwanted stuff. - Use http://sanesecurity.com/ ClamAV signatures, in Debian use the clamav-unofficial-sigs package

Instant Messaging:

http://prosody.im/ is a breeze to configure and it just works.

Telephony / Video calls:

Repro is a secure and simple SIP proxy: http://www.resiprocate.org/About_Repro

But: Resist the urge to install a VoIP PBX like Asterisk and connect it to your phone line & the internet. It will most likely be hacked and abused.

Security:

I've set up a self-signed CA using XCA (http://xca.sourceforge.net/). With a client certificate on a smart card which i embedded into a USB token (http://www.gemalto.com/products/usb_shell_token_v2/), i can run around and plug this USB token in random machines and instantly have my client certificate available in Chrome. This is especially nice if you (like me) don't trust PHP software like the Roundcube Webmailer.

The problem can't just be solved by simply pointing people to (random?) open source software.

We still need servers as rendezvous points, and we can't expect everybody to run their own services. Properly setting up a mail server is hard.

So, everybody who can should run XMPP and/or SIP servers and hand out accounts to their friends. Both telephony/messaging protocols have inherent capabilities for federating with other people's servers similar to what email does. And with OTR and ZRTP we have real end-to-end encryption without relying on (broken) SSL certificates.

The technology is ready, now it's time to make it usable. Let's help people to move their lives back out of the cloud.

For a technology preview project the name is fine, albeit not googleable. I don't think that a project like this has to choose a name people can sell to the management.

From my own experience, really chose something that is googleable. It's frustrating when you never have a change to be found when people type your project's name into google because it's an artist's name or a common word. And yes, i think finding a good name for a project is hard.

This. If you don't want to and/or are unable to properly operate your systems, please stay on Heroko, AppEngine etc., otherwise this is a disaster waiting to happen.