Tuesday May 22, 2007
grist.org
Thinking Outside the FoxToday, the fast-growing cadre of corporate leaders pressing for climate
action welcomes a new member: Rupert Murdoch, CEO of News Corporation,
the media empire that encompasses Fox News, 20th Century Fox,
HarperCollins, MySpace.com, and dozens of newspapers in Australia, the
U.K., the U.S., and beyond.
[..]
... Murdoch launched a company-wide plan to address climate change that
includes not only a pledge to reduce the company's emissions (which has
come to be expected at such biz-greening events) but also a vow to
weave climate messaging into the content and programming of News
Corp.'s many holdings.
[..]
So what's motivating Murdoch?
While he voiced concerns that "climate change poses clear, catastrophic
threats," his emphasis was on opportunities to fatten the bottom line.
"Our advertisers are asking us for ways to reach audiences on this
issue," Murdoch said. He also argued that the new climate strategy
would reduce energy costs, help the company recruit top talent, and
provide "a chance to deepen our relationships with our viewers,
readers, and web users."
[..]
I think it is great news that Murdoch has made this move and its not because he cares about the environment, its because he is a business man and his customers and partners want it. I continue to be amazed how quickly this environmental issue is being picked up and how much influence public opinion have in steering these huge multinational companies.
It remains to be seen was News Corp will actually do, but this current high profile trend for companies to go green can't be a bad thing for publicising the issue to the masses.
For more information on Sun's stance on the green issue I recommend Dave Douglas blog.
Friday May 18, 2007
It's been a while since I last posted. I've been working on a number of projects relating to Eco friendly IT over the last few months. There is huge interest in how to reduce the impact on the enviroment from IT and there are many aspects to the problem and to potential solutions. I've learned a lot recently and I hope to share some of it here.
To that end I've decided to adopt a new green theme for this blog. I'm not sure if anyone actually reads the content from the site or whether, like me you use a news reader, but since I'm trying to put being green at the center of my work I thought I would do it anyway!
Monday Mar 12, 2007
Simon
It seems that for various reasons that a lot of people want to be able to run 2 machines back to back with an IB interconnect.
While this should be a fairly simple operation to perform, life in the IB world makes it quites hard to achieve.
[...]
What if Sun made the Solaris SM open source ?
I get asked about this about once a month.
Them: "I have two systems back to back with a single IB cable between them, how do I use the link?"
Me: "Are you using Solaris?"
Them: "Yes"
Me: "Ah. You are going to need a switch or use Linux ."
Them: "Why?"
Me: "IB isn't like Ethernet. It needs a Subnet Manager (SM) to enable systems to talk to one another. Without it no connections are permitted - nothing works. Almost all IB switches include a SM but when you have a two node configuration with no switch you need to use a host based SM. As the only other time you need a host based SM is in really ,really big configurations (1000's of nodes) there isn't much interest in making a host based SM available for Solaris.
The only free host based SM I'm aware of is OpenSM which is part of Open Fabrics. That only works on Linux as far as I'm aware."
Them: "Oh. So I can't use Solaris then"
Me: "No. Well not officially anyway. There is one written, but its not available outside Sun. It is only available as SPARC binaries too."
It's not a good situation, but until there is significant demand this situation is unlikely to get resolved.
Let Simon know about your requirements!
Tuesday Jan 09, 2007
I'm delighted Sun is taking a leading position and setting a good example:
sun.com
The notion of sustainable computing had been quietly brewing at Sun for
several years, but in 2006, Sun embraced it as a company priority. This
year, Sun complied with the European Union's Reduction of Hazardous
Substances Directive (RoHS), ramped sales of the UltraSPARC T1 processor, named a vice president of eco responsibility, and unveiled Project Blackbox.
[..]
- Sun Ray 2: next-generation thin client consumes as
little as four watts of energy — the energy of a nightlight — and has a
much longer lifespan than a PC
- Global product take-back program: Sun's commitment
to reclaiming, then recycling, reusing, or disposing of more than 95
percent of Sun's products in an eco-responsible way.
- Open Work program: encourages Sun employees to telecommute, rather than drive, to work. More than 20,000 employees currently work from home.
- RoHS compliance: includes plans to quickly comply with future regulations. Sun encourages harmonization across U.S. states and countries.
[..]
You can't dispute these are great steps towards a more responsible industry. I'm looking forward to getting my new Sun Ray at home very soon.
For more information on Sun Eco responsibility take a look at: sun.com/aboutsun/environment/
Thursday Dec 21, 2006
I've been a fan of diskless boot in Solaris for a long while. Building a large grid (read: datacenter) with hundreds or thousands of servers each with one or more local disks seems, to me, to be fundamentally broken. The cost of the disks themselves isn't my main issue, nor is it the heat and power they use (although it does add up: Sun X2200 server (2 CPU's, 4 1GB DIMMS) without disks 248 Watts, with disks 278 Watts), nor is it the wasted storage on each system that isn't usable (how much of that 500GB disk are you using per system, and what about mirroring?).
No my concern is about having data and configurations strewn throughout your network. How are you going to achieve a flexible data center fit for the future if you are having to provision and manage the operating systems installed locally on all your servers?
With diskless booting you can centralise all of your storage and make all your servers stateless.
Diskless boot is possible in a number of ways, you can use Fiber Channel, Ethernet or InfiniBand and you can boot using storage and/or network protocols. In my mind the general purpose datacenter of the future doesn't include Fibre Channel, perhaps thats narrow minded, but if you object and want me to explain why leave a comment 
That leaves us with the increasingly common Ethernet vs. InfiniBand debate. Without going down that rat hole too much I'd like to compare the two in terms of their ability to do network consolidation, that is, to reduce the number of network technologies in the datacenter.
Until recently I would have told you InfiniBand (IB) is king for network consolidation and Ethernet doesn't really play in this space. Recently I'm staring to think differently.
You see the advantages of IB are great on paper, and for many HPC clusterstoo, but in real commercial datacenters the requirements are different. The advantages in the commercial space for potential performance improvements from the faster, lower-latency and RDMA capable interconnect are hard to make use of in practice.
I'll leave speed and latency for another time and take a look at RDMA. The appeal of RDMA is to take CPU cycles away from processing network traffic and put them to use for the application you are running. This is a worthy goal, but today very few commercial applications are written to take advantage of RDMA (Oracle 10g being a very notable exception), and changing customer code to make use of RDMA is very expensive.
Although utilizing RDMA is hard, emerging standards such as NFS/RDMA and Oracle's support for IB make it interesting to keep an eye on. More promising is the not-RDMA-but-not-TCP/IP-either set of protocols which can run over IB. Here SDP (Sockets Direct Protocol) is the best example as it has the potential to transparently provide a sockets interface to applications but actually bypass the host Operating System TCP/IP stack. Other examples of interest are RDS (Reliable Datagram Service), SRP (SCSI RDMA Protocol) and iSER (iSCSI Extension for RDMA). The last two are two competing protocols to run SCSI over IB and provide an option to replace Fiber Channel.
To date to uptake of either SRP or iSER has been fairly slow. There are many reasons for this, but the main ones are a lack of one single standard and lack of Operating System support. Today Solaris, Linux and Windows support SRP but Linux and Windows require commercial drivers from Cisco or QLogic (SilverStorm's new owner). iSER is supported in Linux and Windows but only by Voltaire (Solaris support is planed with support from Sun). I should also note that the OpenFabric stack purports to support both SRP and iSER but is widely regarded as not ready for production (read: buggy). I'm not sure if this is true or simply vendors spreading FUD to make their own stack more appealing (I suspect its a bit of both).
In order to boot over IB you need special firmware on your HBA, or do you? ...
I'll post the second part to this once I've written it.
Monday Dec 18, 2006
Consolidation is usually the aim of Virtulisation projects. Saving on infrastructure costs is usually one of the aims of consolidation. It's rare to see some actual numbers:
Power savings through virtualization
As we finally shut down our old SAN we were able to see the effect
of virtualization on our power consumption today and we were quite
amazed by the results. So far, 33% into our project, we have been able
to reduce our power requirement in datacenter 1 by 3.7 KiloWatts (18.7
down to 15.0) and in datacenter 2 by approximately 1.5 KiloWatts.
Unfortunately I am not able to calculate a true cost savings from this
as I don’t have the pricing for our energy but when we finish it will
be significant.
Because we are virtualizing everything to one production datacenter
we will eventually be able to shut down datacenter 2 for production
(which will mean less stringent requirements on cooling, UPS etc.). It
will be interesting to see what the final outcome is for the project.
Tuesday Nov 21, 2006
Last week I was at the marvelous SC06 conference in Tampa, Florida. I had a great opportunity to talk with many customers, partners and competitors. I learned a great deal about emerging technologies and who is offering them.
I was pleased to see that the issues of power and cooling that we hear about so often with our large enterprise customers were also visible at a show about large super computers (its hardly surprising considering how similar these systems are becoming). Lots of interesting power and cooling products to follow up on.
I had a most interesting discussion with some folks at Rackable about DC power and how their systems are more power efficient. There seemed to be two big advantages to their solution.
Firstly they claimed that the newer very high efficiency (90%+) server power supplies on the market only achieve this efficiency if they are very highly utilised. Their solution to this it to install larger rack level power supplies and share power between server which this enables them to load the power supplies much closer to their maximum ratings.
Secondly they claimed that by moving the AC to DC conversion to outside the server and putting at the top of the rack reduced failures since the power supplies in each server didn't require moving parts. A stated secondary advantage is that less heat is generated in the server.
I was really impressed with their solution and resolved to look further into the benefits of DC power in the data center when I got back to the UK.
Now I'm back I'm no longer impressed, although their technology is still interesting its not as good as I was lead to believe:
The claim that efficient power supplies are only efficient with high loads is simply not true. Take a look at 80plus.org (a site which champions efficient power supplies), look at any of the power supplies they have tested. If you pick any wattage and any form factor they all look pretty much like this:
80plus.org Efficiency of the Enhance ENH-0840A power supply
Notice that this supply is most optimally efficient around 50% load, quite the opposite to what the Rackable folks told me.
There is also an extra loss in efficiency by having an extra power conversion in the top of the rack:
News.com.com
Sun's Bechtolsheim is unconvinced of the merits of DC, though. The crux
of his argument is that DC requires two conversions: one from outside
AC to 48-volt DC for distribution within the building, and a second,
within servers, from 48 volts to 12 volts. Even if each conversion is
90 percent efficient, wasting 10 percent of power as heat, the
combination makes the overall process 81 percent efficient.
By contrast, a single AC-DC conversion with the server uses power supplies rated at 90 percent efficiency, Bechtolsheim said.
I've not yet had a chance to look at the heat output from an normal power supply, but I'm willing to bet its not that great when compared to the CPU and memory of a system. Further I expect that the sum total energy loss from power supplies from a rack of normal 1U servers would be about the same or less than an equivalent number of DC supplied systems and their proportion of the loss for a shared power supply.
With respect to moving parts there is a lot to be said for getting rid of them. Perhaps this is the best feature of the Rackable design ...
One thing I have realised is that blade chassis designs which can benefit from a shared power supply but that distribute all the required voltages (12V, 5.5V, 3.3V etc) throughout the chassis directly to the blades actually would be more efficient and more reliable.
I know what server form factor I'd buy if I were a customer
Tuesday Nov 07, 2006
Simons Networking Blog, lead me to this excelent Network World article:
What's the biggest, fastest LAN switch?
This isn't a trick question, but one with a lot of tricky answers depending on how you define "big" and "fast.">
Ethernet switch vendors such as 3Com, Force10, Cisco, Extreme, Foundry
and HP ProCurve constantly tussle with claims of the highest
performance, density and latency. But keep in mind that what's
available right now from such vendors is three-year-old technology, on
average. Meanwhile, a host of hungry start-ups such as Raptor Networks
and Woven Systems have a new take on how to build the "biggest"
Ethernet switch. Their approach diverges from single big-iron chassis,
and more resembles clustered supercomputing, or InfiniBand networking
topologies.>
[..]
"We're looking at the next-generation machines and everything is going to go up by a factor of 10," says Dave Wiltzius, network
division leader at the lab.
"Everything
will be 10G. So we're looking for a switch, or switch fabric that can
give us on the order of 2,000 10G ports… We're basically interested in
building a federated switch environment using fat tree topologies and
things like that."
[..]
The approach Woven is taking is similar to the trend of grid or
distributed, clustered computing, where large, symmetric
multi-processor (SMP) servers are being replaced by single- or
dual-processor nodes coupled together over a network.
"The same thing is
going to happen to LAN switching in the data center, with respect to
scale out," Quackenboss says. "The big [LAN] switches are expensive,
and the biggest non-blocking switch you can buy for data center
applications is a 64-port Foundry system."
[..]
This ties in with my earlier comments on pod based grid designs. I've wondered for a while why someone doesn't make a better IB/Ethernet gateway that could be used to provide a fast, non-blocking IB based core but connected to regular Ethernet servers and switches at the edge. It will be interesting to see how fast this technology develops - Arastra and Woven Systems are worth keeping an eye on.
Thursday Nov 02, 2006
I'm load testing between two x64 servers (a V20z server and an X4100 server). I've got a Gigabit Ethernet network and an InfiniBand network which connects them. I'm looking at the maximum throughput and cpu load using ttcp and netperf.
I'm using Solaris 10 update 2 (6/06) with no patches (for now). I'm using PCI-x 4x SDR HCA's and the Sun IB switch. The server is an X4100 with two single core 254 Opteron processors and 8GB of memory. The client is a V20z with two single core 940 Opteron processors and 3GB of memory.
Running IP over IB I can get just over 200MB/s with 50% cpu utilisation (I observed 30% utilisation of one CPU and 70% utilisation on the second with mpstat):
bash-3.00# netperf -H 10.0.0.1 -f M -p 5001 -i 20,5 -cC -I 95,5 -n 2
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to ::ffff:10.0.0.1 (10.0.0.1) port 0 AF_INET : +/-2.5% @ 95% conf.
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. MBytes /s % K % K us/KB us/KB
49152 49152 49152 10.00 203.45 48.98 51.38 4.703 4.933
Doing the same with regular Ethernet I get 112MB/s with 17% CPU utilisation (I observed 28% utilisation of one CPU and the other was practically idle with mpstat).
bash-3.00# netperf -H 192.168.100.65 -f M -p 5001 -i 20,5 -cC
TCP STREAM TEST from ::ffff:0.0.0.0 (0.0.0.0) port 0 AF_INET to ::ffff:192.168.100.65 (192.168.100.65) port 0 AF_INET : +/-2.5% @ 99% conf.
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. MBytes /s % K % K us/KB us/KB
49152 49152 49152 10.00 112.13 17.05 15.53 2.971 2.705
With the Ethernet its clear the limiting factor is the wirespeed of Gigabit Ethernet, but with the InfiniBand its less clear. I had expected the IPoIB performance to be CPU bound but that doesn't appear to be the case. I wonder what it is?
Wednesday Nov 01, 2006
I've just read my colleague and good friend's new blog about Pod based grid designs vs centralised switch designs. it's unearthed a torrent of thoughts on the subject and I need to dump them on you:
Tony Marshall[...]
Pods are great as a modular system that allows growth in specific unit
sizes. They need to be spec'ed to be the right size from the start, if
they are too large then there is a lot of waste of nodes not being
used, if they are too small then the core switch will run out of ports.
There is a limit on when it makes sense to have Pods as opposed to
the nodes all connecting into a large core switch. Also it depends on
the segregation required between Pods/Nodes which again comes back to
the requirements of the grid.
[...]
However with pods there are more network devices to manage which brings
its own issues and proper management tools for grids are a must.
Tony touches on several essential issues here to managing a large (or small grid).
Firstly you need really good management tools. This is kind of obvious to anyone who's built a grid before, but if you want your 1000 systems to be useful you ought to have a good handle on them. You'd probably want to be able to provision an operating system, upgrade firmware, monitor hardware etc on all your systems from a single centralised place - otherwise you'd have such a hard time managing the system (think staffing costs) you'd be better off spending your money on large SMP servers and having far fewer OS instances to manage.
The same principals are true for switches and grid network designs in general. Swap SMP servers for large chassis based switches (e.g. think the larger 1500 port Force 10 switches as an example) and swap 1U general purpose servers for 1U general purpose switches (like the Summit 400). You end up with the same cost trade-offs - if you don't invest in decent management tools, you might as well invest in a big chassis based switch.
Just as large SMP servers are expensive and going out of fashion, so, in my opinion, are large centralised switches.
With SMP servers you get the advantage of a pre-cabled mid plane so you don't need to connect up all the processors yourself and you'd hope the manufacturer made it easy to share the resources between multiple users and applications (Solaris is pretty darn good at this).
However with large chassis switches you still have to cable up all the nodes yourself, and these cable runs are long! Growing your data center involves cabling guys standing on site, pulling hundreds of cables past all your production systems and most critically fiddling with your core switch. Or is it switches?
As more and more types of applications become grid enabled and more and more computer users realise the savings of a flexible, scalable, low cost infrastructure (think VMWare), grids move from dedicated clusters for a specific workload to
THE DATACENTER. I don't know about you, but I wouldn't build a data center that relied on a single core switch, no matter how resilient the manufacturer says it is (how many computer products are resilient to fire and floods?).
If you connect all your servers to central switches you create one big SPOF (Single Point Of Failure). You could connect each system to two identical separate switches, you could put these in separate rooms, you could do an awful lot, but what you can't do is avoid the need for double the amount of cabling, and if you got a 1000 systems that's a big load of cable ... unless ...
Yes, you've guessed it ... unless you use pods. If you use a 1U general purpose switch in each rack you can connect each server into that local switch. You can have your rack full of general purpose servers connected to your general purpose switch with no cabling outside the rack. You can order this pre-built and have it delivered as a complete unit. That should be your building block.
You can arrange these racks into Pods of, say 4 racks (so at 32 1U systems per rack that's 128 systems) and you can base your network design around this. You can use 10Gb Ethernet to link racks and connect them up to your core switches. Your core switches can be separated as I described earlier, but the big difference is the number of cables you need to run, perhaps two or four fibres per Pod depending on your requirements. Think how much less screwing about that is in your production datacenter.
To return to Tony's remark about proper tools for management. Yes Pods give you more switches to manage, but grids are all about using lots of cheap fast devices as one, why should the network design be any different?
Management of switches is particularly important for a requirement for utility computing grid where it may be desirable to segregate one customer from another. To return to my SMP analogy it might be argued that its easier to use the expensive chassis switch because its easier to partition groups of systems off (lets be blunt here, we are talking VLANs and ACLs (Access Control Lists) here, not rocket science), but I'd disagree.
Any automated or at least human operator friendly tool to dynamically partition any network is going to have to understand the concept of their being more than one switch in a network. Heck even a tool to manage a single chassis based switch is going to need to understand the concept of different switch blades. So if you need flexibility in your network, don't base this decision on what you can do through the CLI of a single central device. Instead go talk to your network vendor, there is plenty out there to choose from Force 10, Extreme, Cisco, Nortel, Foundry etc.
Say, to your vendor "I need some tools to manage a large number of switches", and see what they say. Look at what they offer look at the costs, maybe even consider developing or extending some existing internal or open source tools, but don't seriously constrain your whole datacenter unless you really know what you are doing!
Oh and finally, if you find all this rather daunting and just want to buy the solution from people who have to understand this for a living, do drop Sun a line, we're happy to help
Thursday Oct 12, 2006
I've been advising some internal folks on how to connect our new Sun Blade 8000 Modular System to a customers network in a resilient configuration. While looking for information on how they should configure a resilient network I happened across this page of documentation.
I thought it was pretty amusing! I think our customers are smart enough to figure that one out!
An overall resiliant network design takes a little more thought. Here is a summary of my advice:
Each NEM (Network Express Module) gives two pass-through ports per blade. A customer concerned about resilience should use two NEM's. They should run at least one link from each NEM to each external switch.
Because each NEM is independent of each other there is very little difference between this config and multi-homing 10 regular servers. IPMP[1] can be used to fail over between the two (or more) interfaces on each blade.
If the customer needs more bandwidth than 1 Gigabit Ethernet and they still want to keep resiliency they could consider two trunks[2] per blade, one to each external switch and then using IPMP between them.
[1] IPMP is Solaris specific. Bonding can be used in Linux to achieve a similar effect. Windows alternatives likely exist to do the same thing.
[2] Trunks or Trunking is referred to as Link Aggregation by Cisco and others. All sensible switches should support this functionality, the official standard is called 802.11ad, but the customer should check how many trunk groups are supported per switch as this tends to be less than the number of ports divided by two.
Solaris 10 supports trunking natively on the Sun Blade 8000 Modular System using Native Link Aggregation (dladm). Linux can support this using Bonding (but with a different config to that which mimics IPMP). Windows also supports this with free add on drivers from Sun/Intel.
Friday Oct 06, 2006
I've been using internal Sun builds for about a week now (since I found them!) and its shaping up pretty good. Today its usable, fairly stable and the UI is bareable, but clumsy. I'm using it as the primary client of my internal
Sun calendar account with Thunderbird on Solaris and Windows which isn't recomended in the release notes, but hey ho we'll see how it goes!
I'm glad there is now a
publicly available release that supports WCAP, but as yet the SPARC builds linked aren't actually there, I guess they'll be there in the next few days.
From past experience with Mozilla projects I'm hoping it should be in pretty good shape in about six months and very good within a year. I'm going to try and be helpful and file bugs when I find them, which is something I've failed to do for the last 6 years of using Mozilla and its later incarnations (despite much advocacy). We'll see how I fair.
Update: Douglas Toombs was kind enough to point out that the links in the release notes don't actually work. Since this post it looks like a second 0.3 release candidate has been made available. These links should work now:
Windows/Linux/Mac,
Windows/Linux/Mac with WCAP. As for Solaris builds they still don't seem to be available, I'll update this post when I spot them.
Update 2: Sunbird & Lightning 0.3 ReleasedFormal 0.3 version is now available!
Wednesday Oct 04, 2006
QLOGIC TO ACQUIRE SILVERSTORM TECHNOLOGIES
Aliso Viejo, Calif., October 3, 2006 – QLogic® Corporation
(Nasdaq:QLGC), the leader in Fibre Channel host bus adapters (HBAs),
stackable switches and blade server switches, today announced that it
has entered into a definitive agreement to acquire SilverStorm
Technologies, Inc. Pursuant to the terms of the agreement, the Company
will pay approximately $60 million in cash.
[...]
Well, I can't say I'm surprised what with Cisco buying Topspin last year and QLogic's earlier purchase of Pathscale. I think this will give customers much more confidence in IB technology. QLogic have clearly realised that IB is cheaper and faster per port than Fiber Channel (including cabling and switches) and that customers are increasingly looking for a single consolidated and standardised infrastructure where every system has fast, low latency, RDMA access to every other machine as well as block level access to storage, plain old IP and plenty more besides (DAPL, SDP, RDS etc.).
QLogic are now in a good position as they are less dependant on Mellanox than Cisco and Voltaire to supply their chips what with having their own HBA's from Pathscale and now an established line of switches. It will be interesting to see how well QLogic integrate IB into their other products and if they build their own IB switch silicon. They could also bring some much needed improvements to the current generation of IB to FC gateways.
As the only small IB vendor left, Voltaire must be wondering if they are in anyone else's sights.
Wednesday Aug 16, 2006
Last week I spent a good few hours getting Ubuntu Linux installed on a Sun Fire T2000 Server for a customer benchmark. It proved a pretty good learining experience ...
If you haven't already heard, the Sun Fire T2000 Server is based on the UltraSPARC T1 processor (codenamed Niagara) which provides 8 cores each capable of running 4 threads in a single CPU. This means it is amazingly fast for workloads that can be broken up into lots of seperate processes (e.g. Web Servers). The really neat thing about the system is it is very power efficent, which makes for cooler data centers and if, like me, you have stood behind a rack full of x86 servers and felt rather sick after a few minutes from the heat output (I'm not going on about the morality of energy effency here, just human biology), you'll apreciate cooler servers. Anyway I'm wandering off topic: check out sun.com for more technical details on the T2000 systems, they're good.
From experience, installing any Linux distribution on very new hardware is always painful, so I was expecting a tough time getting Ubuntu onto a T2000 system. I've installed several Linux distributions on a variety of platforms before, but never on a Sparc based system. This was definately going to be a bit of a learning experience.
Having searched about on the net (and a little inside Sun) for a while I was supprised that I couldn't find a clear set of instructions on how to install Ubuntu (not least as the boss is talking about it so prominantly).
To cut a long story short once I realised that you must have internet access working to install the OS and that you must stick http:// in front of your proxy server address I got the installer working fine and now have working system.
One really cool thing about the Ubuntu website is that anyone can edit the online instalation manual. Having spent the time to get the thing working I added my notes.
I was amazed how easy this was, there was nobody required to aprove my changes, it just went straight up first time. I hope someone finds it useful, I've rather enjoyed giving something back for a change.
|
|
|
|
