I can’t help but think that the advent of impulse buying on-line has made consumers forget a useful skill – picking products from a provider with proven track record, or stated customer service guarantees.
An email from Oftel this morning announces,
From 14 February 2007, [...] Service Migrations will require broadband providers to supply consumers with a migration authorisation code upon request and free of charge. The new rules will also make it the responsibility of all broadband providers to ensure that technical and operational problems such as tag on line do not hinder consumers’ ability to switch.
Why must bad providers (the sort who would block users from migrating if they want to) be supported by regulation like this ? If users have to think carefully about who they buy connectivity from, the bad providers will either have to improve, or will fail as users avoid signing up. The new regulation is well intentioned, but counter-intuitive.
I am now quite the sunos fan. I do think that admins should strive to always start working with the ‘tiny install’ option offered in the install process, though.
This leaves you with a system that you can’t use for building software on though ! My personal advice is to run over to Sun Freeware and install :
SMCautoc SMCautom SMCbzip2 SMCcoreu SMCdiffu SMCgcc SMCgzip SMCliconv SMCmake SMCncurs SMCzlib
and from your install cd :
SUNWbtool SUNWsprot SUNWtoo SUNWcpp SUNWhea SUNWarc SUNWlibm SUNWlibmf SUNWdfbh SUNWcg6h SUNWxwinc SUNWolinc SUNWxglh SUNWlibC SUNWscpu
You should then find your software will build (unless there are less generic dependencies for your software too.) From Sol 10 onwards, remember the packages appended with an ‘x’ containing 64 bit libraries are deprecated.
When I first installed OS/X 10.4, I thought that Dashboard was incredible. Now, just like Front Row, I’d much rather not be running it all the time (I found that nomatter how useful it looked, I could not ‘integrate’ it with the way that I liked to work with my computer.)
OS/X is great, but I always admit that it’s a memory hog; anything I can strip out of a running system, I do. After a reinstall (reason why this was needed coming up in a later post), I always cut out Dashboard. So as a reminder for myself how .. this is the best way.
sudo defaults write com.apple.dashboard mcx-disabled -boolean YES
killall -1 Dock
You can then remove Dashboard from the dock..
(only performed after a check that killall has the same effect as on Linux rather than Solaris!)
I still think dashboard is great, but I can’t find a use for it with the way I personally work. I am sure many Apple users feel the same way. I wonder how many Windows Vista users will feel the same way when they install the upgraded MS Operating System…
Frustrating does not being to describe a bug I had to work through today.
HTTP 1.1 supports request multiplexing. This technology allows you to send multiple HTTP requests through a single connection – when one http request is answered, the connection remains open to allow user-agents (“browsers”) to send more requests without having to go through the pains of tearing down the connection, and opening a new one. RFC 2616 says “persistent connections are the default behavior of any HTTP connection“.
RFC 2616 also implements a system to ensure user-agents can understand when a http reply has been fully communicated. In fact, this is a requirement, “….all messages on the connection MUST have a self-defined message length“.
Microsoft Internet Explorer claims to support HTTP 1.1.
Given a set of well known internet standards, and such commonly used software, you’d expect no issues with decisions on ‘where a reply boundary’ exists’ and ‘whether to close the connection’.
Well, you’d be wrong. Firstly, HTTP 1.1 also allows the server-side of the connection to signal that the message must not be multiplexed; where the signal wants to indicate that the connection will be torn down following the reply, the server should send the ‘Connection’ header and populate it with the token ‘close’. Sounds easy ? Well, HTTP 1.1 also says : “The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections“. What about when the proxy is actually implemented at the application/web server end, as a reverse proxy ?
This distinction, I presume, is designed to allow the client side to maintain the persistent connection to the proxy. But in this example, the proxy is actually a reverse proxy that is close to the web-server infrastructure and not the browser. What if this is important to the application ?
You may wonder, why should it matter ? A proxy is expressly forbidden from changing the Content-Length header, because this header is used to establish where the boundary between different requests in the multiplexed http 1.1 connection exist. Can anyone therefore explain the following :
A packet sniffer was used to identify what was happening. On both occasions, the XML document containing the data which should be dropped into the textarea was downloaded. When passed through the proxy the ‘Connection:’ header was stripped as per http 1.1. The Connection header exists when we contact the server directly. The Content-Length was identical for both replies.
MSIE refused to use the Content-Length header to verify where the reply boundary exists. Firefox works just fine.
The fix was to break the effectiveness of the proxy and
Neither of which I wanted to do.