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.
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.
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 [email protected] -r [email protected] 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.
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.
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.