agranig

„Ok Glass“

Strange for a country where you can legally smoke (and buy?) weed at every other corner.

mermaid-filter is also a great part in the tool-chain, especially with pandoc.

In Europe, there is http://specialisterne.com helping to hire people with Asperger‘s. Pretty good experience so far, can certainly recommend.

Edit: actually seems they’re on pretty much all continents.

I'm using one since over a year, can't recommend. No proper support for the docking station (which goes via USB3 and doesn't support video output), power plug wears out really fast and causes ubuntu to reboot quite often when plugging it due to some short circuiting, disk is really slow for an ssd and working with vagrant sucks due to it, 802.11n driver doesn't work properly, etc etc.

It looks well, feels well, but it's not suitable for devs. I'm a long time lenovo x200 line user, and the X1 is really bad compared to those models.

Can't recommend.

Could you elaborate on that? fail2ban seems quite popular for blocking malicious IPs.

Well, mojo seems to try to escape catalyst's dependency hell by providing everything by itself. That's considered a pro or con depending on the view point. The websocket integration is definitely a plus.

If you enjoy writing open source Web Apps and REST APIs in Perl/Catalyst for the Telco segment: we're hiring! See my profile for contact infos.

Wait, what?

Most likely related to the OSX issue described here recently: https://github.com/HackerNews/HN/issues/19

You've one copy of the file, encrypted with N public keys. Each of the corresponding private keys can decrypt the files.

Assuming you've all the public keys in your keychain, then for each key you pass "-r <email>" for the encryption, like "gpg -e -r foo@bar.com -r baz@bar.com plain.txt", and for decryption you do something like "gpg --output plain.txt -d plain.txt.gpg".

We use plain GPG-encrypted files stored in our version control system (git/svn). The files get encrypted with all the public keys of the users who have access to these files, and can be decrypted with their private keys then. Not perfect, but works.

Since you can pack ANY reasonably short text into QR codes, it works well for encoding a vCard (e.g. at the back of your business card), and we even encoded pure Perl code once for a job campaign.

So, there might be good reasons and use cases for using QR codes, but just encoding a URL probably isn't, looking at the conversion rate.

Oh, we've done a little Perl code challenge to win some free beer lately: http://www.sipwise.com/news/jobs/hiring-by-curiosity-part-1/

The free beer event is already over, but it's still fun to try if you can make it :)

A reachable version of the post is here: http://www.sipwise.com/news/doutgrowing-desktops/

It's not about Ubuntu in particular. Ubuntu just used to combine the concepts and tools in user-friendly way without the need to "tinker".

Where do you turn to for a modern Desktop if everything is going the same (=OSX) direction? The whole point is that staying with Gnome 2.x will put you into an entrenched situation, whereas everyone else is moving on, but in a way which just doesn't fit your way of working, and without perspective that it'll ever fit?

An option would be to connect via websocket to a server and react on the disconnect event (doing some simple ping-pong to keep the connection alive). That would require an always-on websocket server though, which is a different story. Still could be good enough for a gimmick like this.

We've currently 5 people who've solved this quiz... nah, is it really too hard?

Another hint, in case you're getting "400 Bad Request" errors: this is NOT a REST API, read the code again!

In the good old ISDN/SS7, both the network-provided caller-id as well as the user-provided caller id are transported, even in case the caller wants to perform an anonymous call. Usually the last hop before delivering the call to the called party is responsible for removing the relevant information. In SIP, the same exists with From- and P-Asserted-Identity headers.

The SS7 interconnection partners usually go through extensive tests before allowing you to hand over signaling traffic via SS7, but this is not so much the case for SIP interconnects, where we're lacking a bit of clear standards (however working groups like http://www.sipforum.org/sipconnect exist and are taken more seriously nowadays).

If you are allowed to do "CLIP no screening" - which means you can set arbitrary caller ids in the user-provided part, the terminating system (the hop delivering it to the called party) is still able to check both fields, so this could be a way to pin down the real calling party, even if it "spoofs" its caller id.

Doing a simple " svn co https://svn.java.net/svn/jitsi~svn/trunk jitsi" works perfectly fine for me. Same with the source snapshots at https://download.jitsi.org/jitsi/nightly/src/ . We also had no issues getting our bugfixes into their upstream while we did all the testing. I was wondering about the "observer/member" thing they mention on the website as well, doesn't seem to be relevant though.

The real work-horses are actually Kamailio and Sems, which are quite little known but power a LOT of your ISPs' VoIP systems.

Provisioning is built on top of Apache/Perl/Catalyst with a MySQL backend. The billing system is in C and Perl, and the Media Relay is in C with an own kernel module on top of iptables.

Asterisk is pretty insignificant, but it's surely the best known part in the VoIP world.

The only thing Asterisk does in our system is acting as a voicemail server.

The real secret sauce is their dead-simple way to sign up and use the client. As you can see in the post, the setup process with the Jitsi client is still a bit awkward, because it is supposed to be a provider-agnostic multi-protocol client. There is still a huge potential in stream-lining this process to get a broad end-user adoption. Flexibility really isn't key in this case, rather than proper UX.

The Jitsi guys are currently working on an Android version, let's see what comes out of that.

In general, the reason for the slow adoption of SIP beyond just pure voice telephony is that the SIP/SIMPLE standard with its companions for buddy lists etc. is really crappy, and as a result so are most clients (or the interoperability between them). It doesn't make it better that the mobile device/equipment vendors forked off their own OMA standards, so the situation is pretty bad in that regards.

I still don't give up all hopes to see a proper Android/IOS SIP client supporting voice, video presence etc. while at the same time adhering to the standards.

There is a "next steps" section at the bottom of the post pointing this out. You can check the handbook at http://www.sipwise.com/doc/2.6/spce/ar01s04.html#_creating_p... to learn how to do it.

The post warns about NAT on the server-side (like Amazon EC2 does). Client-side NAT works just fine.

One of our customers serves north of 1 mio overall provisioned subscribers on two servers with this software, so it's quite scaleable vertically already. It's easier when UDP is used though, because with TLS things add up quite quickly.

To go big, we've horizontal scaling mechanisms using subscriber partitioning by load-balancing SIP and provisioning requests over multiple pairs of such servers (usually placed in blade-center servers).

The key here is to keep as much CPU heavy things like media relaying end-to-end where possible, because the signaling part is pretty light-weight in SIP. To scale out and keep reliability up while keeping complexity low, we have a shared-nothing approach wherever possible. Works well for us.

You are just jealous of our plan :)

If you go lean, revenue is everything. You start with something small, you fight to get every single customer, you grow with every project, staffing up another developer or sysops engineer paid from your own pocket to do a bigger project than the past one, trying to get your "side-product" ready to not be dependent of more projects at some point...

And then, you've the Double Stealth. Why bother with revenues, if VCs are throwing money at you? Why bother with customers at all? Why bother with products? Hell, why not just completely hiding what we do, as long as the money is flowing? Problem? :D