Pages

Saturday, November 5, 2011

My blogging for I' Been to Ubuntu basically stopped a couple of years ago, and it changed its tone the year before that. There are several reasons.

First, I started this blog as a way to write non-tech friendly howtos for a couple of friends who had decided to try Ubuntu. I chose to use version numbers instead of code names and GUI methods instead of CLI ones for just that reason. Once the apt: standard came, I used that wherever possible. These friends are no longer using Ubuntu, and I had no reason to keep writing generic howtos that probably already existed in the documentation, anyway.

Next, I used my need to keep up with FOSS news to write about changes in the next version of Ubuntu. This was the Digg era, and my blog got several front page placements and hit 100K visitors a month, despite the fact that I never promoted it at all (or submitted those links to Digg). I was one of the few blogs dedicated to talking exclusively about Ubuntu. I did amazing things that others weren't doing ... like checking links, verifying assertions, and proofreading my posts before they went live.

At this point, I was spending my normal three or four hours a day reading tech news, and another one or two setting topics and writing. Once OMGUbuntu and a couple other blogs (WorksWithU and Webupd8, I think) started up and knew how to play the Digg game, I realized that I had competition and needed to step up my game. I needed to learn to promote. I needed a real blogging platform. This blog was going to become another job, and I needed to go big or go home.

So I went home. I didn't want another job. I didn't even try to compete. I just wrote the same kind of stuff I had been writing before, but tried to avoid the topics that OMGU wrote on. The blog became a little more technical and I started writing about more general topics like federated social networking, dogfooding, and Ubuntu spinoffs. Oh, yeah, and then there was that "Screw Ubuntu!" phase where I renamed to blog to "I Been to Debian."

So many times, I wanted to keep this blog going, but I never felt I had anything to offer that other sites weren't already offering, and I didn't want to just add to the noise or waste anyone's time. I didn't do Twitter. I didn't submit to Reddit. When I was on vacation, though, I often still blogged, but my heart wasn't in it.

The kinds of things that I wanted to say belonged on social networks, so that's where I put them. I still put them there. I'll go so far as to say that casual blogging in general should die the same death this blog has.

Tuesday, October 18, 2011

I've been running Oneiric (now 11.10) as my primary desktop since pre-alpha so I thought I had a good handle on it. Well, it turns out that I didn't.

This morning, I stumbled upon Online Accounts in the Me Menu. This appeared to be something that I have been asking for for some time now. Gnome 2 had the About Me dialog, which had the potential to offer all kinds of information about yourself to other applications, meaning that you potentially wouldn't have to enter your account information separately in your mail and chat clients. Unfortunately, security concerns meant that the About Me dialog was never used for that purpose.Online Accounts came up promisingly. I happily entered my email addresses for Google (the only provider supported at this time), and left Mail, Calendar, Chat, Contacts, and Documents all turned on. I mostly live in the browser these days, but desktop integration sure is nice. I opened Empathy to check that IM was working and was prompted to enter my account details. Hmm. I Tried Thunderbird. No joy.

It turns out that Online Accounts just offers an API. There aren't any applications that actually use that API at this point. Yay! Another half feature from Ubuntu (well, officially it's GNOME's, but Ubuntu shipped it in 11.10). It gets more and more frustrating every year.

Saturday, October 15, 2011

What do all these things have in common? They control(ed) the platform, and companies and individuals gladly changed the way they did business or ran their lives . Some of them are gone, and I'm certain that in another ten years, the rest will be footnotes on the Internet.

URL shorteners are kind of unique in that list -- they exist to serve Twitter, mainly. They exist so that we can talk more in our 140 bytes. Unlike the real URL, they don't last as long as the page and they break. We need special browser extensions so that we know where we are clicking through to.

URL shorteners have become the masks for phishing and spam. How awful, just so that we can get our 140 characters.

I can't help but think that in ten years, we're all going to look back on this with a collective "WTF were we thinking?!?" Right now, the average connection speed for developed countries is right around 10 Mbps. Yet, we're limiting communication more than we were in the 90s. And we're stuffing the Internet full of temporary workarounds to this artificial limit. Youtube videos at TBs a day, though? No problem.

It's all rather silly. Let's get a communication platform that allows expression and permanent, discoverable links.

Wednesday, May 18, 2011

"For example, Iptel, Ekiga.net, and ippi are all fine SIP networks, but if youre only on one of them you cant talk to other SIP VoIP users on the other two and vice-versa. The same is true of XMPP/Jingle networks, and, for that matter all the other VoIP networks." -- http://www.zdnet.com/blog/networking/beyond-skype-voip-alternatives/1061

Huh? SIP supports peering and XMPP supports federation. That means that different networks can talk to one another.

"No Extensions NecessaryBut what does SIP peering mean? Is there some new special protocol required for SIP peering? What problems does peering introduce that arent already covered by the existing specifications and products? Those are good questions. First and foremost, SIP peering does not require any new extensions to SIP. The ability to interconnect provider networks is built into the SIP protocol itself. There is a common misconception that SIP peering requires some kind of special profiling of SIP in order to provide interoperability. That is simply not true. SIP was designed to interoperate, even among implementations that support different extensions and capabilities. SIP networks are interconnecting today without additional extensions. SIP has built-in negotiation capabilities that allow fallback to a common baseline set of capabilities when there is mismatch between sides. As an example, SIP has an extension for preconditions (RFC 3312), which makes sure that a call proceeds only if a quality of service (QoS) reservation exists between the endpoints. What happens if only one side supports the extension? If implementations follow the specifications, they will correctly fall back to baseline operation without this feature. Now, some will argue that this is a problem. We need this feature to always be used between our networks! theyll say. The interesting thing is, the extension is implemented at the endpoints, not in the network servers. Thus, a SIP profile that mandates usage of the extension could not be applied to the SIP servers doing the interconnection. Fortunately, the SPEERMINT working group has recognized that SIP peering is not about SIP profiling. Its charter explicitly rules profiling as out of scope, in fact. So, if SIP peering is not about a SIP profile, what is it about?" --http://www.tmcnet.com/sip/0306/sip-columns-speaking-sip-0306.htm

Also:

"1. Introduction

XMPP Core [1] describes the client-server architecture upon which Jabber/XMPP communication is based. One aspect of such communication is "federation", i.e., the ability for two XMPP servers in different domains to exchange XML stanzas. There are at least four levels of federation:

Permissive Federation -- a server accepts a connection from any other peer on the network, even without verifiying the identity of the peer based on DNS lookups. The lack of peer verification or authentication means that domains can be spoofed. Permissive federation was effectively outlawed on the Jabber network in October 2000 with the release of the jabberd 1.2 server, which included support for the newly-developed Server Dialback [2] protocol.

Verified Federation -- a server accepts a connection from a peer only after the identity of the peer has been weakly verified via Server Dialback, based on information obtained via the Domain Name System (DNS) and verification keys exchanged in-band over XMPP. However, the connection is not encrypted. The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks. Verified federation has been the default service policy followed by servers on the open XMPP network from October 2000 until now.

Encrypted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) as defined for XMPP in RFC 3920 [3] and the peer presents a digital certificate. However, the certificate may be self-signed, in which case mutual authentication is typically not possible. Therefore, after STARTTLS negotiation the parties proceed to weakly verify identity using Server Dialback. This combination results in an encrypted connection with weak identity verification.

Trusted Federation -- a server accepts a connection from a peer only if the peer supports Transport Layer Security (TLS) and the peer presents a digital certificate issued by a trusted root certification authority (CA). The list of trusted root CAs is determined by local service policy, as is the level of trust accorded to various types of certificates (i.e., Class 1, Class 2, or Class 3). The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain.

The remainder of this document describes in more detail the protocol flows that make it possible to deploy verified federation, encrypted federation, and trusted federation. Protocol flows are shown for federation attempts between various combinations to illustrate the interaction between different federation policies." -- http://xmpp.org/extensions/xep-0238.html

Sure, they have to be turned on, meaning that Facebpook's XMPP doesn't federate, for instance, but most XMPP networks do, and it's the same for most SIP neworks. In fact, this is from Ekiga:

"Using the Ekiga.net SIP addressThe Ekiga.net service accept calls to its registered users without being registered to Ekiga.net. Just call the sip:user@ekiga.net address directly. " --http://wiki.ekiga.org/index.php/Peering

Peering and federation are the strongest selling points of SIP and XMPP. How could you miss them?

Am I misunderstanding you, SJVN? I hope so.

Personally, I'm waiting for a bunch of providers to step up and provide webmail / SIP / XMPP + social extensions all under one address.

Tuesday, April 5, 2011

"For the rest of the changes, we needed a video widget that was more flexible than the X-based one we were using. So from Totem 3.2, we'll start using clutter, and clutter-gst," said Hadess.

What does this mean for Unity, since it uses Compiz? Will Canonical's desktop become more and more divorced from GNOME standard, including the included apps? I'm betting it will. In fact, I've been encouraging Ubuntu to go this direction for quite some time.

Friday, April 1, 2011

As I've written before, I've been using Natty and Unity for about three months straight now, and I'm extremely happy with how it's shaping up. I'm always interested in other projects, though, especially ones with a philosophy which includes consistent look and feel. Elementary is a project like that, so I leapt on the release announcement and torrented the 614MB .iso.
Two words described the distro -- fast and elegant.
I first ran the live CD in Qemulator under Natty, but I knew the video drivers were holding me up so I wrote out a USB drive for it and rebooted. Even running from the drive, everything is extremely responsive. It works as expected.
Pros:

Fast

Limited, very consistent applications

Midori is awesome and is all that I wanted Epiphany to be for years

Postler only asks for your e-mail address and password to set up common mail options. Amazing and easy

Looks amazing and the applications take up little vertical space

Abiword and Gnumeric instead of OO.o or LO

Traditional GNOME app menu

I like that the Elementary devs have standardized on Vala and GTK+

Cons:

Postler had trouble connecting to my GMail account and gave no feedback for about fifteen minutes

Inconsistent configuration options for the non-eOS apps. I assume that they will be modified later

Midori lacks installed extensions (edit: open the sidebar to find them) and doesn't work with some web apps (e.g. Picasaweb)

There is a lot of turmoil about the installed apps and that has to be getting in the way of work

This is a 0.1 release, but it's based on Ubuntu 10.10 so it's already quite stable. If the choice of applications settles down (Elementary Nautilus or not?), eOS should be great by 0.2. Who can ask for more than that?