Open fibre

One of the big telecom operators in Sweden, Telia, has started to offer “fibre to the house”- called “Öppen Fiber” in Swedish – and I’ve signed up for it. They’re investing 5 billion SEK into building fibre infrastructure and I happen to live in an area which is among the first ones in Sweden that gets the chance to participate. What’s in this blog post is information as I’ve received and understood it. I will of course follow-up in the future and tell how it all turns out in reality.

Copper is a Dead End

fiber cableI have my own house. My thinking is that copper-based technologies such as the up-to-24mbit-but-really-12mbit ADSL (I have some 700 meters or so to the nearest station) I have now has reached something of an end of the road. I had 3 mbit/sec ADSL almost ten years ago: obviously not a lot of improvement is happening in this area. We need to look elsewhere in order to up our connection speeds. I think getting a proper fibre connection to the house will be a good thing for years to come. I don’t expect wireless/radio techniques to be able to compete properly, at least not within the next coming years.

Open

This is an “open fibre” in the sense that Telia will install and own the physical fibre and installation but they will not run any services on top of it. I will then buy my internet services, TV and telephone services (should I decide that TV and phone over the fibre is desirable) from the selection of service companies that decide to join in and compete for my money.

Installation

They’re promising delivery “before the end of the year”. I won’t even get an estimated installation date until around mid August. If an existing tube doesn’t exist for the copper or electricity that they can use to push the fibre through, they will dig. From the road outside my house to my building, across whatever land that exists there. They need to dig roughly 40 cm deep. The fibre is terminated inside the house (a maximum of 5 meter inside the building) in a small “media converter” box which basically converts from fibre to a RJ45 network plug. It is the size of a regular small switch or so. It is claimed to be possible to get a different “box” that provide a direct fibre plug of some sorts for the people who may already have fibre installed in their houses. I currently have a burglar alarm in my house that uses the current phone connection which I’ll need to get either just dumped completely or converted over to use a telephone-over-fibre concept. I don’t plan on paying for or using any copper-based service once the fibre gets here. (There’s however no way to use the Swedish tax deduction “rot-avdrag”.)

Price

dlink DIR 635There’s no monthly fee for the fibre, I only pay a one-time installation fee of 16700 SEK (roughly 1800 Euros) to get it. I then of course will have to pay for the services if I want to actually use the installation but until I do there are no fees involved. This price is actually fixed and the same for all the houses in my area that got this deal. At August 15th the deal ends and they’ll increase the installation price to 26700 SEK. Given the amount of work they have to put in for each new customer, I don’t really consider this price to be steep. A lot of money, sure, but also quite a lot of value.

Speeds to expect

The physical speed between my house and the other end (some kind of fibre termination station somewhere) will be exactly 1000mbit/sec and no more “up to” phrasing or similar in the contract. Of course, that’s just the physical speed that is used and with this equipment the network cannot be any faster than 1000 mbit. There will then be ISPs that offer an internet connection, and they may very well offer lower speeds and even varying different speeds at different tariffs. Right now, other fibre installations done by Telia seem to get offered up to 100/100 mbit connections. As this is then not a physical maximum, it should allow for future increasing without much problems. The 1000 mbit/sec speed over the fibre is a limitation in the actual installed hardware (not the fibre) so in the future Telia can indeed replace the media converters in both ends and bump the speed up significantly should they want to and feel that there’s business in doing so. My current D-Link wifi router only has 100 mbit WAN support so clearly I’ll have to replace that if I go beyond.

IPv6

Seriously, I believe I may be closer to actually get a real IPv6 offer using this than with ADSL here in Sweden. I haven’t really investigated this for real though.

Update

December 16th: I got a mail from Telia today that informed me that the installation in my area has been delayed so it won’t happen until Q2 2012! 🙁

Rockbox Devcon 2011

Rockbox

Hoards of hackers in similar-looking t-shirts with funny logos having the b in front of the K (see below for some sort of explanation) were seen on the streets of London on Friday June 3rd 2011.

Thanks a lot to  Google UK who hosted our Rockbox developers conference this time in central London.

We had some short-time visitors but we were 16-18 reverse engineering happy persons in a single room most of the weekend, where we hacked away on code, whined on the amount of outstanding patches and bugs and generally made a large amount of bad jokes and Monthy Python references.

The happy core team was caught on a picture:

Rockbox team Devcon 2011

On the Saturday we plowed through a lengthy list of discussion points to really make the most of all of us gathering physically. Among the outcomes from that is that we decided we want to change to git, we think a lot of future of Rockbox lies in the app for Android, we keep the Archos support and more. The Android builds are going to get into the build system ASAP and we’re gonna setup a system where (only) trusted build clients will participate in the building of Android builds that will be distributed to users – this since applications on phones will have a much greater risk of causing harm if some “bad guy” would try to infect our system with stupid things.

Dominik “bluebrother” Riebling brought up the very interesting point that none of us had noticed: we have two different logos being used in the project: one with the K being in front of the b (like the one on the web page) and one with the K being behind the b – which is used in SVG logos and on just about all Rockbox t-shirts made so far! If you zoom in on the tshirts on the group picture you’ll see!

We will also start allowing GPLv3 code into Rockbox in order to be able to use espeak, but all our code will remain GPLv2 or later. I could only find a single USB header file left that comes from the Linux source tree and has a GPLv2 only license.

Even more than this was discussed but I figure the rest of the details will be posted properly on rockbox.org for those seriously interested.

All in all, it was a very enjoyable weekend with a lot of fun and great friends. We stayed at a hotel just a few blocks from the devcon office which was really convenient. even though its wakeup routine was a bit non-standard. Peter “petur” D’Hoye took a lot of pictures as usual.

We also managed to break the Tower of Rockbox record.

Daniel "Bagder" Stenberg Rockbox Devcon 2011

The group picture was taken by a Google person I don’t know the name of who helped us out, and the one of me was taken by Peter D’Hoye.

Rockbox bridge and tower

Keeping to the tradition and subtle arts of Rockbox Towers, but doing it with a twist to celebrate the place we have Rockbox devcon 2011, we decided to make a Rockbox bridge.

We started out by gathering all devices we had in the room that can run Rockbox and distributed them on the construction floor area. As the Android app runs fine on tablets now there’s actually a rather good way to get some solid base into the construction…

Many Rockbox devices

Once all material was known, the construction started with a large amount of eager engineers contributing with good and bad ideas and at times very shaky hands:

constructing a Rockbox bridge

(wods, scorche, gevaerts and paumary)

The result, involving an iRiver beneath the bridge catching the digital flow, became what might be the longest Rockbox construction done so far:

Rockbox bridge

Rockbox bridge closeup

After the bridge, the work started on the real stuff. Building the tallest Rockbox tower ever made. After a couple of accidents and crashes, the tireless team managed to break the previous 104 cm record and the new Rockbox tower record is now officially 117cm:

Rockbox devcon 2011 tower 117cm

(Pictures in this post were all taken by Peter D’Hoye.)

Binary mittens

Binary mittensI just want to show off my awesome new mittens that my dear mother gave me as a present when I turned 40 (at least at the party I held for my birthday, I actually turned 0x28 already back in November). To help you decode them I’ve framed a line of digits. The left one is supposed to be read before the right one.

As a bonus design detail, the digits on the thumb are made the same as on the part which the thumb covers on the photo.

The backside has nothing to decode but instead features a tux image, the same one on both mittens so the enclosed picture only shows the left-hand one.

Binary mitten backsideI’ll admit that I didn’t immediately decode the mittens myself when I gave it a first glance, and I blame the fact that no lowercase letters were used!

I used my mobile phone to take the pictures, so they’re not really top-notch quality.

This will make the coming winter much more appreciated and I hope to impress a lot of friends when the few warm days of the Swedish summer have passed.

foss-sthlm, the sixth, the controversial one

I’m happy to say that I was the main planner and organizer of yet another foss-sthlm meetup, the sixth. Last week we attracted about one hundred eager FOSS hackers to attend to this meeting to which I had found and cooperated a somewhat controversial sponsor.

We have had a discussion within foss-sthlm now due to this event’s sponsor: what kinds of companies are acceptable as sponsor for FOSS events and what are not? It is obvious that we have a lot of different opinions here and several people have expressed that they deliberately didn’t go to meetup #6 simply because of the sponsor’s involvement and relationship to the Swedish defence industry. Do you think a defence manufacturer or weapon systems creator can also have its good sides and sponsor good activities or should we distance ourselves from them?

I’m honestly still interested in more opinions on this. We have not formed a policy around this subject because I simply don’t think that’s a good idea. We’re not a formal organization and we all have our different views. I think we have our members hand around and participate as long as we stay within a reasonable “boundary”. If we would get involved with the wrong kind of companies, a larger portion of the group would boycott the meeting or just plainly leave foss-sthlm. But why would we ever? I’m the one who’s mostly been in touch with sponsors and I would certainly not get involved and ask for money from companies that I believe have crossed the magic line in the sand.

The meeting was perhaps the most techy and most advanced of them all so far, and I found the talks very inspiring and educating. I’ve not had time or energy to put up a page with pictures or descriptions of them, and I think I’ll just skip it. You should probably try harder to attend next time instead!

Remove your software

Your software needs to be removed from my work computer. I did not install it,
do not want it and did not request it.

Another one of those emails arrived in my inbox today:

Subject: Remove:

Your software needs to be removed from my work computer. I did not install it, do not want it and did not request it.

[name redacted]

No mention what software or indication of what platform or what might’ve happened when my software allegedly ended up in the person’s computer. Not very friendly either.

Again I suspect that there’s some software that uses curl in some way, but I can’t tell for sure…

I replied to it, saying that I didn’t install anything on his computer.

Pointless respecifying FTP URI

There’s this person wiIETFthin IETF who seems to possess endless energy and a never-ending wish to clean up tiny details within the IETF processes. He continuously digs up specifications that need to be registered or submitted again somewhere due to some process. Often under loud protests from fellow IETFers since it steals time and energy from people on the lists for discussions and reviews – only to satisfy some administrative detail. Time and energy perhaps better spent on things like new protocols and interesting new technologies.

This time, he has deemed that the FTP a FILE URI specs need to be registered properly, and alas he has submitted his first suggested update of the FTP URI.

From my work with curl I have of course figured out a few problems with RFC1738 that I don’t think we should just repeat in a new version of the spec. It turns out I’m not alone in thinking this work isn’t really good like this, and I posted a second mail to clarify my points.

We’re not working on fixing the problems with FTP URIs that are present in RFC1738 so just rephrasing those into a new spec is a bad idea.

We could possibly start the work on fixing the problems, but so far I’ve seen no such will or efforts and I don’t plan on pushing for that myself either.

Please tell me or the ftpext2 group where I or the others are wrong or right or whatever!

11 years of me

On May 11th 2000 I posted by first blog entry that is still available online on advogato.org. No surprise but it was curl-related.

The full post was:

I was made aware of the fact that curl is not really dealing well with the directory part of an ftp URL.

I was gonna quote the appropriate text piece from RFC1738 (yes, it is obsoleted by RFC2396 although 1738 has more detailed info about particular protocols like ftp) to someone when I noticed that I had interpreted it wrong when I read it before.

The difference between getting a file relative the login directory or with absolute path. It turns out you have to get a path like ftp.site.com/%2etmp/ if you want have the absolute path “/tmp”. Oh well, I have it support my old way as well even if that isn’t following the RFC just to allow people using that way to be able to use the new one unmodifed…

… which I guess proves that even though lots of time has passed, I still occupy myself with the same kind of hobbies and side- projects…

US patent 6,098,180

(I am not a lawyer, this is not legal advice and these are not legal analyses, just my personal observations and ramblings. Please correct me where I’m wrong or add info if you have any!)

At 3:45 pm on March 18th 2011, the company Content Delivery Solutions LLC filed a complaint in a court in Texas, USA. The defendants are several bigwigs and the list includes several big and known names of the Internet:

  • Akamai
  • AOL
  • AT&T
  • CD Networks
  • Globalscape
  • Google
  • Limelight Networks
  • Peer 1 Network
  • Research In Motion
  • Savvis
  • Verizon
  • Yahoo!

The complaint was later amended with an additional patent (filed on April 18th), making it list three patents that these companies are claimed to violate (I can’t find the amended version online though). Two of the patents ( 6,393,471 and 6,058,418) are for marketing data and how to use client info to present ads basically. The third is about file transfer resumes.

I was contacted by a person involved in the case at one of the defendants’. This unspecified company makes one or more products that use “curl“. I don’t actually know if they use the command line tool or the library – but I figure that’s not too important here. curl gets all its superpowers from libcurl anyway.

This Patent Troll thus basically claims that curl violates a patent on resumed file transfers!

The patent in question that would be one that curl would violate is the US patent 6,098,180 which basically claims to protect this idea:

A system is provided for the safe transfer of large data files over an unreliable network link in which the connection can be interrupted for a long period of time.

The patent describes several ways in how it may detect how it should continue the transfer from such a break. As curl only does transfer resumes based on file name and an offset, as told by the user/application, that could be the only method that they can say curl would violate of their patent.

The patent goes into detail in how a client first sends a “signature” and after an interruption when the file transfer is about to continue, the client would ask the server about details of what to send in the continuation. With a very vivid imagination, that could possibly equal the response to a FTP SIZE command or the Content-Length: response in a HTTP GET or HEAD request.

A more normal reader would rather say that no modern file transfer protocol works as described in that patent and we should go with “defendant is not infringing, move on nothing to see here”.

But for the sake of the argument, let’s pretend that the patent actually describes a method of file transfer resuming that curl uses.

The ‘180 (it is referred to with that name within the court documents) patent was filed at February 18th 1997 (and issued on August 1, 2000). Apparently we need to find prior art that was around no later than February 17th 1996, that is to say one year before the filing of the stupid thing. (This I’ve been told, I had no idea it could work like this and it seems shockingly weird to me.)

What existing tools and protocols did resumed transfers in February 1996 based on a file name and a file offset?

Lots!

Thank you all friends for the pointers and references you’ve brought to me.

  • The FTP spec RFC 959 was published in October 1985. FTP has a REST command that tells at what offset to “restart” the transfer at. This was being used by FTP clients long before 1996, and an example is the known Kermit FTP client that did offset-based file resumed transfer in 1995.
  • The HTTP header Range: introduces this kind of offset-based resumed transfer, although with a slightly fancier twist. The Range: header was discussed before the magic date, as also can be seen on the internet already in this old mailing list post from December 1995.
  • One of the protocols from the old days that those of us who used modems and BBSes in the old days remember is zmodem. Zmodem was developed in 1986 and there’s this zmodem spec from 1988 describing how to do file transfer resumes.
  • A slightly more modern protocol that I’ve unfortunately found no history for before our cut-off date is rsync, as I could only find the release mail for rsync 1.0 from June 1996. Still long before the patent was filed obviously, and also clearly showing that the one year margin is silly as for all we know they could’ve come up with the patent idea after reading the rsync releases notes and still rsync can’t be counted as prior art.
  • Someone suggested GetRight as a client doing this, but GetRight wasn’t released in 1.0 until Febrary 1997 so unfortunately that didn’t help our case even if it seems to have done it at the time.
  • curl itself does not pre-date the patent filing. curl was first released in March 1998, and the predecessor was started around summer-time 1997. I don’t have any remaining proofs of that, and it still wasn’t before “the date” so I don’t think it matters much now.

At the time of this writing I don’t know where this will end up or what’s going to happen. Time will tell.

This Software patent obviously is a concern mostly to US-based companies and those selling products in the US. I am neither a US citizen nor do I have or run any companies based in the US. However, since curl and libcurl are widely used products that are being used by several hundred companies already, I want to help bring out as much light as possible onto this problem.

The patent itself is of course utterly stupid and silly and it should never have been accepted as it describes trivially thought out ideas and concepts that have been thought of and implemented already decades before this patent was filed or granted although I claim that the exact way explained in the patent is not frequently used. Possibly the protocol using a method that is closed to the description of the patent is zmodem.

I guess I don’t have to mention what I think about software patents.

I’m convinced that most or all download tools and browsers these days know how to resume a previously interrupted transfer this way. Why wouldn’t these guys also approach one of the big guys (with thick wallets) who also use this procedure? Surely we can think of a few additional major players with file tools that can resume file transfers and who weren’t targeted in this suit!

I don’t know why. Clearly they’ve not backed down from attacking some of the biggest tech and software companies.

patent drawing

(Illustration from the ‘180 patent.)

curl, open source and networking