Sky+ is one of the most useful gizmos that I've ever bought. It really has changed the way that my family and I watch TV. Being able to pause and rewind live TV and the ease of recording stuff is just fantastic.
I've had relatively few problems with the box. Last year I had some severe picture problems, but a slight adjustment of the angle of the receiver dish solved that. Recently, however, our Sky+ box has started locking up whilst viewing live tv. Rewinding a few seconds seemed to resolve it. Until today that was, when even recorded programs were locking up, followed by the Sky+ box shutting itself down.
These days if I've got the choice between phoning customer support or checking on Google, customer support comes second. One thing that is obvious is that an awful lot of people are reporting the same problem.
Now, I'm assuming if you've read this far you are interested in how to fix it, yes?
Captain Obvious says: "Kids, if you follow instructions posted on websites and things go wrong it is YOUR PROBLEM, not theirs."
Step 1: Power off the Sky+ box at the mains, an leave it powered down for at least two minutes.
Step 2: Restore the power to the box and start up. If your box is like mine it may take a few minutes to start up.
Step 3: Click the "Services" button on your Sky+ remote and go into the "System Setup" menu.
Step 4: Press "0" on the Sky+ remote, then press "1" and finally press "Select". This calls up the "Super Secret Hidden Menu" (seriously, it does!).
Step 5: At this point there are two options you can use. One will remove everything from your system and wipe the internal hard drive, the other performs a disk check, fixes file-system problems and hopefully gets you back to a working state.
So, if this is the first time you've tried this, you will want to highlight the option "Sky+ Planner Rebuild" and then press "Select". This should run the maintenance routines on your box, which will power itself off once it has completed.
Once you go back into Sky+ you will need to check through your list of recorded programs as any recovered but corrupted programs will need deleting. It is also worth noting that some people report problems when their Sky+ box is over 90% full, so deleting some unwanted programs may not be a bad idea either.
If this doesn't work then you can try the final option which will wipe EVERYTHING from the planner, and that is "System Reset."
Luckily for me deleting some old programs and performing a planner rebuild seems to have fixed my Sky+ box, so I've not needed to nuke the system. Apparently this is the routine that Sky customer service will tell you, but seeing as I didn't phone them I can't confirm that.
So if you are having the same issues as I did (and assuming you've taken note of the sage advice of Captain Obvious) then this might be worth trying.
Saturday, 22 August 2009
Saturday, 1 August 2009
Chaos Caverns II - Dev Diary
Updated 21/08/2009
A couple of months ago there was a discussion on Retro Remakes relating to creating platform games. The discussion grew to the point that I got a bit carried away and added an early (very early in fact) version of the source code to Chaos Caverns, as well as writing some pseudo-code to demonstrate how simple it is to make a basic platform game.
The thing is that once I'd written the pseudo code I found myself wondering if it would actually work, and the only way to test this is to bloody well write it. And so, using my pseudo code as a template I wrote a basic platform game engine. It works too. In fact in some respects it works better than the code for the original Chaos Caverns.
So now I'm in a bit of a quandry as I'd already been planning an update of Chaos Caverns and was in the middle of fixing up the old code.
So on the one hand is the original Chaos Caverns, which has already been expanded to allow me to create a flip-screen arcade adventure in a similar style to Jet Set Willy and pretty much only needs the levels completing to make it into a completed game.
On the other is the new code sitting in the Testplatform2 folder. This isn't quite as complete as the other but has some important improvements:
1 - It has been upscaled to 640x480. This is double the resolution of the original and does look a lot nicer.
2 - I've written the new version using Object Oriented methodology, rather than the spaghetti code of the first one. It has taken longer trying to remove things like the level transitions from the old one than it has to write the new one from scratch. Also I've got the benefit of a couple of years experience compared to when I started writing Chaos Caverns.
3 - Even on the short test level I've created it feels rather nice to play.
4 - It should allow me to create a much better game, more in a 16bit retro style than the 8bit style of the first one.
Point 4 is the decider really. Even though I could knock out a quick game using the old code base I wouldn't be as happy with it as I think I could be with the new game engine. So I'm re-implementing the functions that are still missing, which is a slightly frustrating exercise, but the new features (such as animated tiles, and each tile being available in multiple states) already there makes up for this.
So here we are at the birth of what I'm currently calling "Chaos Caverns II".
I'll be updating this post with the development diary as time goes on, so stay tuned!
2/8/2009
Level switching code has been added to the game, so now I can start building the game proper. I've put together three screens as a test and it all works rather well. At this point it is starting to feel a bit more like a proper game.
Next step: Items and enemies.
12/8/2009
Summer time isn't the most productive time for programming, but have managed to track down and fix some bugs, including an extremely annoying one which caused the player to fall through the floor, but only when existing the screen to the left. Exiting from the right worked fine. Finally managed to fix it by re-arranging the movement code to make sure that the move down / platform checking code ran before the left / right movement and exit code.
I've also spent some time tidying the code up a tad, and starting to add in the code for the enemies.
I'm dealing with the enemies in a different way to how I did in Chaos Caverns. This time all the enemies from all the levels are read into a single array when the game initialises - rather than refreshing the list at each level change. This allows me to "kill" enemies and for them to stay "dead" between screen changes.
I'll be dealing with objects in the same way. Some objects will allow you to destroy enemies, so for example, collecting a pin will allow you to destroy the giant beach balls. More on that later...
To make the game feel a bit more like a game and less like a demo I've added a place-holder title screen.
OK, so that's a long way from brilliant, but at least it makes testing the game a whole lot easier in that once you've lost all your lives you return to the title screen rather than just quitting or jumping straight back to the first screen.
I've also added a music track for the title screen - again this will probably change before the game is finished - but for now I'm using Mozart's Rondo Alla Turca (thank God for classical music in the public domain).
As a side note - if any budding musicians are reading this and feel like donating a music track or two then please get in touch.
As of midnight I've got a moving enemy on screen (at last!) and can move onto the enemy collision detection routines tomorrow. *yawn*
13/8/2009
Oh no, Thursday the Thirteenth!
I'm not superstitious about the number thirteen, but today hasn't been a great day, work-wise.
At lunchtime we lost access to the internet, email, our advertising system AND our page transmission system - while we were half-way through transmitting a newspaper that had a 1pm deadline. It was down for a couple of hours due to an alleged power-cut in Oxford.
So we had three hours of dealing with complaints about something that we've got no control over.
Wonderful.
Follow that up with me being on call, and getting called back in twice (although as luck would have it I was able to deal with both calls remotely).
On the bright side I've got collisions with the first (and currently only) enemy in the game working. So that's nice.
15/8/2009
Motivation is often an issue when writing software for yourself. When things get tricky, I try and add "one feature a day". This at least gives some impression of the game developing rather than just lurking there waiting for me to complete it.
OK, so sometimes you miss a day - but today's feature is one that makes the game a bit more tricky - and that is allowing the player to die if they fall from too great a height. Not a difficult thing to add but something that I had deliberately left out of the original Chaos Caverns.
This time, however, if the level designs that I have in mind are going to work then this is a feature that I need - otherwise there won't really be any challenge.
Features remaining to be added (and this isn't a full list):
Other things to do:
16/08/2009
Today's new feature: Lifts. In getting the lifts working I've had a think about how I'm coding the game, and more importantly, how to reduce the amount of routines that I need whilst achieving the features that I require.
The lifts are a case in point. I'd considered making a new game object for the lifts, but then realised the obvious: "a lift is just a platform that moves." So by adding some new parameters to the platform object and creating a "move" method I've got a basic lift working with very little new code required.
I've still got to code the interactions between the player and the moving platform (ie. if the platform is moving left or right then the player's movement follows it). Easy for left to right, slightly more complex for up and down. Especially when I need to find a way of slowing down the lifts a bit as by default they are a bit nippier than I'd like.
I was also going to add another object for "traps" - basically killer objects. Thinking about it what is a killer object? In the terms of this game it is an enemy that doesn't move, so if I just use the existing enemy routines with a static enemy then job done!
18/08/2009
Still working on the lifts. As they were running a bit faster than I'd like I've added in some code to create a delay between each move - so the lift will only move every x number of frames. This works well and allows me to have fast and slow lifts as required.
Moving and jumping whilst on the lift works but... sometimes whilst jumping you fall through the lift, and I can't see why. Ah well, tracking down and squashing bugs is all part of the fun.
I've also been re-jigging the player movement code a bit so it should be a wee bit more optimised, as well as a bit smaller. For those interested, at present on a P4 2.8ghz the game uses around 4% of the CPU time.
Update: Bug fixed, so the lifts are now fully working (vertically at least). I've adapted the second screen so that it can only be traversed by using the lift - and it all seems to work nicely so far.
19/08/2009
Now that the lifts are working it is time to start expanding on the code to make this less of a demo and more of a game. With that in mind I've started adding a fairly basic score / level / lives display at the bottom of the screen.
The strange thing is that this revealed another bug: if you dropped from a height into water you'd lose two lives instead of just one.
After one hell of a lot of hunting through the code I finally realised that I was forgetting to reset the fall height, so when the water code killed you the fall counter still contained a value, and because you re-spawned on a platform it treated it as if you'd landed after a long fall, which kills you a second time.
An easy one to fix, but a bugger to track down.
20/08/2009
Today I've been expanding the code a touch (extra baddie movement types, horizontally moving platforms and some other bits).
I've also put together a short video showing the game in action. Not a lot to see so far, but you can get the general idea of the progress so far.
Tomorrow I'm planning to add the code for collectible objects into the game. Once this has been done then the game engine will be basically complete and it will be time to start adding enemies and designing some proper levels.
21/08/2009
Found and eliminated another bug - one that allowed you to pass through a solid block if you hit it precisely on the top corner whilst falling.
I've amended the second screen to add in a horizontally moving platform - which worked first time without problems. Mind you, once you've got the code working for the vertical lifts there really isn't a lot you need to change to get it working for horizontal ones.
I've also posted about this game on the Retro Remakes forum - so a big hello to anyone visiting from there.
Update: Collectible items are now working. Quite simple to add really, providing you remember to use methods rather than functions for your reading / drawing code. Why? Because functions can't access an objects fields (the variables that the object uses). This is a "it's too late at night for this shit" type bug.
22/08/2009
Today has been mainly spent "enjoying" a bout of either man-flu or hayfever. Either one gives the same result - my IQ has dropped so far that it now has a negative value, my nose and eyes are taking it in turns to drip, different parts of me are competing in the "most painful" competition (I think that my back is winning so far). Not surprisingly I've not been especially productive on the old programming front.
That said, I've started expanding the baddie routines a bit, so the beach-ball enemy now rotates as it bounces (which looks cool), I've added a balloon as another enemy, which is also semi-transparent. This also looks pretty cool in action.
I've also started tidying up some of the routines, and simplifying the code in a couple of places.
Continued in Part 2
A couple of months ago there was a discussion on Retro Remakes relating to creating platform games. The discussion grew to the point that I got a bit carried away and added an early (very early in fact) version of the source code to Chaos Caverns, as well as writing some pseudo-code to demonstrate how simple it is to make a basic platform game.
The thing is that once I'd written the pseudo code I found myself wondering if it would actually work, and the only way to test this is to bloody well write it. And so, using my pseudo code as a template I wrote a basic platform game engine. It works too. In fact in some respects it works better than the code for the original Chaos Caverns.
So now I'm in a bit of a quandry as I'd already been planning an update of Chaos Caverns and was in the middle of fixing up the old code.
So on the one hand is the original Chaos Caverns, which has already been expanded to allow me to create a flip-screen arcade adventure in a similar style to Jet Set Willy and pretty much only needs the levels completing to make it into a completed game.
On the other is the new code sitting in the Testplatform2 folder. This isn't quite as complete as the other but has some important improvements:
1 - It has been upscaled to 640x480. This is double the resolution of the original and does look a lot nicer.
2 - I've written the new version using Object Oriented methodology, rather than the spaghetti code of the first one. It has taken longer trying to remove things like the level transitions from the old one than it has to write the new one from scratch. Also I've got the benefit of a couple of years experience compared to when I started writing Chaos Caverns.
3 - Even on the short test level I've created it feels rather nice to play.
4 - It should allow me to create a much better game, more in a 16bit retro style than the 8bit style of the first one.
Point 4 is the decider really. Even though I could knock out a quick game using the old code base I wouldn't be as happy with it as I think I could be with the new game engine. So I'm re-implementing the functions that are still missing, which is a slightly frustrating exercise, but the new features (such as animated tiles, and each tile being available in multiple states) already there makes up for this.
So here we are at the birth of what I'm currently calling "Chaos Caverns II".
I'll be updating this post with the development diary as time goes on, so stay tuned!
2/8/2009
Level switching code has been added to the game, so now I can start building the game proper. I've put together three screens as a test and it all works rather well. At this point it is starting to feel a bit more like a proper game.
Next step: Items and enemies.
12/8/2009
Summer time isn't the most productive time for programming, but have managed to track down and fix some bugs, including an extremely annoying one which caused the player to fall through the floor, but only when existing the screen to the left. Exiting from the right worked fine. Finally managed to fix it by re-arranging the movement code to make sure that the move down / platform checking code ran before the left / right movement and exit code.
I've also spent some time tidying the code up a tad, and starting to add in the code for the enemies.
I'm dealing with the enemies in a different way to how I did in Chaos Caverns. This time all the enemies from all the levels are read into a single array when the game initialises - rather than refreshing the list at each level change. This allows me to "kill" enemies and for them to stay "dead" between screen changes.
I'll be dealing with objects in the same way. Some objects will allow you to destroy enemies, so for example, collecting a pin will allow you to destroy the giant beach balls. More on that later...
To make the game feel a bit more like a game and less like a demo I've added a place-holder title screen.
OK, so that's a long way from brilliant, but at least it makes testing the game a whole lot easier in that once you've lost all your lives you return to the title screen rather than just quitting or jumping straight back to the first screen.
I've also added a music track for the title screen - again this will probably change before the game is finished - but for now I'm using Mozart's Rondo Alla Turca (thank God for classical music in the public domain).
As a side note - if any budding musicians are reading this and feel like donating a music track or two then please get in touch.
As of midnight I've got a moving enemy on screen (at last!) and can move onto the enemy collision detection routines tomorrow. *yawn*
13/8/2009
Oh no, Thursday the Thirteenth!
I'm not superstitious about the number thirteen, but today hasn't been a great day, work-wise.
At lunchtime we lost access to the internet, email, our advertising system AND our page transmission system - while we were half-way through transmitting a newspaper that had a 1pm deadline. It was down for a couple of hours due to an alleged power-cut in Oxford.
So we had three hours of dealing with complaints about something that we've got no control over.
Wonderful.
Follow that up with me being on call, and getting called back in twice (although as luck would have it I was able to deal with both calls remotely).
On the bright side I've got collisions with the first (and currently only) enemy in the game working. So that's nice.
15/8/2009
Motivation is often an issue when writing software for yourself. When things get tricky, I try and add "one feature a day". This at least gives some impression of the game developing rather than just lurking there waiting for me to complete it.
OK, so sometimes you miss a day - but today's feature is one that makes the game a bit more tricky - and that is allowing the player to die if they fall from too great a height. Not a difficult thing to add but something that I had deliberately left out of the original Chaos Caverns.
This time, however, if the level designs that I have in mind are going to work then this is a feature that I need - otherwise there won't really be any challenge.
Features remaining to be added (and this isn't a full list):
- Collectible items
- Killer items
- Special items
- Lifts
- Conveyor belts
Other things to do:
- Add more levels
- Add more enemies
- Add more graphics and sounds
- Write a proper front-end to the game
- Add an end sequence
16/08/2009
Today's new feature: Lifts. In getting the lifts working I've had a think about how I'm coding the game, and more importantly, how to reduce the amount of routines that I need whilst achieving the features that I require.
The lifts are a case in point. I'd considered making a new game object for the lifts, but then realised the obvious: "a lift is just a platform that moves." So by adding some new parameters to the platform object and creating a "move" method I've got a basic lift working with very little new code required.
I've still got to code the interactions between the player and the moving platform (ie. if the platform is moving left or right then the player's movement follows it). Easy for left to right, slightly more complex for up and down. Especially when I need to find a way of slowing down the lifts a bit as by default they are a bit nippier than I'd like.
I was also going to add another object for "traps" - basically killer objects. Thinking about it what is a killer object? In the terms of this game it is an enemy that doesn't move, so if I just use the existing enemy routines with a static enemy then job done!
18/08/2009
Still working on the lifts. As they were running a bit faster than I'd like I've added in some code to create a delay between each move - so the lift will only move every x number of frames. This works well and allows me to have fast and slow lifts as required.
Moving and jumping whilst on the lift works but... sometimes whilst jumping you fall through the lift, and I can't see why. Ah well, tracking down and squashing bugs is all part of the fun.
I've also been re-jigging the player movement code a bit so it should be a wee bit more optimised, as well as a bit smaller. For those interested, at present on a P4 2.8ghz the game uses around 4% of the CPU time.
Update: Bug fixed, so the lifts are now fully working (vertically at least). I've adapted the second screen so that it can only be traversed by using the lift - and it all seems to work nicely so far.
19/08/2009
Now that the lifts are working it is time to start expanding on the code to make this less of a demo and more of a game. With that in mind I've started adding a fairly basic score / level / lives display at the bottom of the screen.
The strange thing is that this revealed another bug: if you dropped from a height into water you'd lose two lives instead of just one.
After one hell of a lot of hunting through the code I finally realised that I was forgetting to reset the fall height, so when the water code killed you the fall counter still contained a value, and because you re-spawned on a platform it treated it as if you'd landed after a long fall, which kills you a second time.
An easy one to fix, but a bugger to track down.
20/08/2009
Today I've been expanding the code a touch (extra baddie movement types, horizontally moving platforms and some other bits).
I've also put together a short video showing the game in action. Not a lot to see so far, but you can get the general idea of the progress so far.
Tomorrow I'm planning to add the code for collectible objects into the game. Once this has been done then the game engine will be basically complete and it will be time to start adding enemies and designing some proper levels.
21/08/2009
Found and eliminated another bug - one that allowed you to pass through a solid block if you hit it precisely on the top corner whilst falling.
I've amended the second screen to add in a horizontally moving platform - which worked first time without problems. Mind you, once you've got the code working for the vertical lifts there really isn't a lot you need to change to get it working for horizontal ones.
I've also posted about this game on the Retro Remakes forum - so a big hello to anyone visiting from there.
Update: Collectible items are now working. Quite simple to add really, providing you remember to use methods rather than functions for your reading / drawing code. Why? Because functions can't access an objects fields (the variables that the object uses). This is a "it's too late at night for this shit" type bug.
22/08/2009
Today has been mainly spent "enjoying" a bout of either man-flu or hayfever. Either one gives the same result - my IQ has dropped so far that it now has a negative value, my nose and eyes are taking it in turns to drip, different parts of me are competing in the "most painful" competition (I think that my back is winning so far). Not surprisingly I've not been especially productive on the old programming front.
That said, I've started expanding the baddie routines a bit, so the beach-ball enemy now rotates as it bounces (which looks cool), I've added a balloon as another enemy, which is also semi-transparent. This also looks pretty cool in action.
I've also started tidying up some of the routines, and simplifying the code in a couple of places.
Continued in Part 2
Tuesday, 21 July 2009
On the Road again - Part 6
On the Road (and off the road) and back on the road again!
The new bike arrived on the expected date. The absolutely HUGE box with the bike parts in it was sat in our dining room ready for me to build my trusty steed v2. Putting it together didn't take too long. I'm getting quite experienced at doing this now, so it only took around an hour to build.
I discovered the problems pretty quickly. First, the gears weren't set up correctly. This isn't that unusual - I've often had to "tweak" the gears to get them right with a new bike. These, however, were well out. The front gears were nearly impossible to change, the back ones were sticky, to say the least. More worrying was that the front wheel was slightly warped - giving it a distinct wobble when riding.
At this point I decided that rather than playing around with it myself I'd take it to a bike shop to make sure it was set up correctly. Twenty four hours, a couple of phone calls and £20 later and I had a fully functioning and safety tested bike with a straight front wheel. Or so I thought.
I hadn't ridden the bike too far, in fact I'd only done around six or seven miles over the following couple of days when something unexpected happened - the left crank fell off whilst I was riding to work. Luckily I was able to keep control and not fall into the oncoming traffic, but as accidents go this could easily have been very nasty.
Once I'd got my breath (and the crank arm) back I found that the nut that holds the crank onto the crank shaft had fallen off. Some safety check that turned out to be! I free-wheeled the bike home and walked to work - feeling a certain amount of animosity to bike engineers in general.
On my way home I managed to find the missing nut, so I was able to re-attach the crank before walking the bike back to the shop to have a gentle word or two about the quality of their service.
Luckily they were most apologetic (them: "that shouldn't have happened, we're very particular about checking that sort of thing", me: "no kidding!") and took the bike back in for another go. They were as good as their word and the bike was back in my hands within three hours - with the crank securely attached. At least I hope it is securely attached.
It's going to be a while before I can put my trust back in this bike.
Buying a bike from a catalogue can be a bit hit-and-miss. I've bought a couple this way and this is the first time that I've really had any problems. Paying a proper bike shop to safety check and tweak your build is a good idea, as long as you can be sure that they have actually checked everything properly. You might need to be prepared to re-check everything yourself, just in case.
I'll leave the last word to the bike shop, as the assistant said to me as I was pushing the bike out to take it home. "This is why we don't sell this kind of bike."
The new bike arrived on the expected date. The absolutely HUGE box with the bike parts in it was sat in our dining room ready for me to build my trusty steed v2. Putting it together didn't take too long. I'm getting quite experienced at doing this now, so it only took around an hour to build.
I discovered the problems pretty quickly. First, the gears weren't set up correctly. This isn't that unusual - I've often had to "tweak" the gears to get them right with a new bike. These, however, were well out. The front gears were nearly impossible to change, the back ones were sticky, to say the least. More worrying was that the front wheel was slightly warped - giving it a distinct wobble when riding.
At this point I decided that rather than playing around with it myself I'd take it to a bike shop to make sure it was set up correctly. Twenty four hours, a couple of phone calls and £20 later and I had a fully functioning and safety tested bike with a straight front wheel. Or so I thought.
I hadn't ridden the bike too far, in fact I'd only done around six or seven miles over the following couple of days when something unexpected happened - the left crank fell off whilst I was riding to work. Luckily I was able to keep control and not fall into the oncoming traffic, but as accidents go this could easily have been very nasty.
Once I'd got my breath (and the crank arm) back I found that the nut that holds the crank onto the crank shaft had fallen off. Some safety check that turned out to be! I free-wheeled the bike home and walked to work - feeling a certain amount of animosity to bike engineers in general.
On my way home I managed to find the missing nut, so I was able to re-attach the crank before walking the bike back to the shop to have a gentle word or two about the quality of their service.
Luckily they were most apologetic (them: "that shouldn't have happened, we're very particular about checking that sort of thing", me: "no kidding!") and took the bike back in for another go. They were as good as their word and the bike was back in my hands within three hours - with the crank securely attached. At least I hope it is securely attached.
It's going to be a while before I can put my trust back in this bike.
Buying a bike from a catalogue can be a bit hit-and-miss. I've bought a couple this way and this is the first time that I've really had any problems. Paying a proper bike shop to safety check and tweak your build is a good idea, as long as you can be sure that they have actually checked everything properly. You might need to be prepared to re-check everything yourself, just in case.
I'll leave the last word to the bike shop, as the assistant said to me as I was pushing the bike out to take it home. "This is why we don't sell this kind of bike."
Monday, 20 July 2009
On the Road Again - Part 5
There is a kind of bitter sweet element to this post. Originally it was intended to mark the one-year anniversary of my return to cycling - with a short update on general health, fitness, weight loss etc.
Unfortunately (as mentioned in my previous post) the biggest weight loss was the loss of my bike - now relegated to memory and a "crime reference number."
In a strangely ironic twist, my replacement bike should arrive on the one-year anniversary of my buying the original. Sadly I did need to spend a little over the £50 mark this time (the cheapeast budget bike I could get in a hurry was £139). This gives me an 18 speed, rigid frame mountain bike with front suspension.
The bike itself is a Townsend "Dark Mesa" mountain bike. Cheap (relatively speaking) but should get me to work on time. As I've recently been playing Half-Life 2 (XBox 360 Orange Box release) this has raised a smile. I may have to see if I can get a Black Mesa logo onto the frame somewhere. . .
Getting back on topic, my weight has stayed contant at 12 stone (as said before, down from 13.5 stone) and I'm feeling fitter than I have done in years. I don't really get out of breath on the ride to and from work (unless I REALLY push myself) and can comfortably make the journey in five minutes (traffic allowing, and yes, that's even including the hill on the way back).
After doing some rough-and-ready calculations I've cycled over 1000 miles in the last year (more or less) and I've developed some nice muscles where once was flab.
Speaking of flab, my "love handles" vanished at some point over the last six months. No idea when, but they've gone.
So overall (and without harping on about the loss of my bike too much) it's been a good year for my health and fitness, has given me more time at home, and has also given me some quality time going out on rides with my daughter.
So for anyone who may be considering getting a bicycle, I can honestly say I'd recommend it without reservation. Just make sure you keep it in a safe place.
Thieving gits.
Unfortunately (as mentioned in my previous post) the biggest weight loss was the loss of my bike - now relegated to memory and a "crime reference number."
In a strangely ironic twist, my replacement bike should arrive on the one-year anniversary of my buying the original. Sadly I did need to spend a little over the £50 mark this time (the cheapeast budget bike I could get in a hurry was £139). This gives me an 18 speed, rigid frame mountain bike with front suspension.
The bike itself is a Townsend "Dark Mesa" mountain bike. Cheap (relatively speaking) but should get me to work on time. As I've recently been playing Half-Life 2 (XBox 360 Orange Box release) this has raised a smile. I may have to see if I can get a Black Mesa logo onto the frame somewhere. . .
Getting back on topic, my weight has stayed contant at 12 stone (as said before, down from 13.5 stone) and I'm feeling fitter than I have done in years. I don't really get out of breath on the ride to and from work (unless I REALLY push myself) and can comfortably make the journey in five minutes (traffic allowing, and yes, that's even including the hill on the way back).
After doing some rough-and-ready calculations I've cycled over 1000 miles in the last year (more or less) and I've developed some nice muscles where once was flab.
Speaking of flab, my "love handles" vanished at some point over the last six months. No idea when, but they've gone.
So overall (and without harping on about the loss of my bike too much) it's been a good year for my health and fitness, has given me more time at home, and has also given me some quality time going out on rides with my daughter.
So for anyone who may be considering getting a bicycle, I can honestly say I'd recommend it without reservation. Just make sure you keep it in a safe place.
Thieving gits.
Tuesday, 14 July 2009
Off the road (for a bit)
Well, thanks to the twat that stole my mountain bike from outside my house last night I'm now a pedestrian again.
I'd claim on insurance, but by the time I've paid my excess it's just not worth it. I have, of course, reported it to the police and got a crime incident number, but let's be honest here - the chances of me actually getting the bike back again are somewhere between slim and none.
Ho-hum.
My bike - July 21st 2008 - July 14th 2009. R.I.P. (Rust In Pieces).
Small update: Out of sheer bloody-mindedness I checked with my insurers about claiming for the bike and found out the following:
I'm not covered for it.
Yes folks, pedal cycles (as they quaintly put it in the small print) are not covered by the homes and contents insurance. So if you do own a bike and imagine that your home insurance covers it you might want to double-check with them BEFORE it goes walkies.
I'd claim on insurance, but by the time I've paid my excess it's just not worth it. I have, of course, reported it to the police and got a crime incident number, but let's be honest here - the chances of me actually getting the bike back again are somewhere between slim and none.
Ho-hum.
My bike - July 21st 2008 - July 14th 2009. R.I.P. (Rust In Pieces).
Small update: Out of sheer bloody-mindedness I checked with my insurers about claiming for the bike and found out the following:
I'm not covered for it.
Yes folks, pedal cycles (as they quaintly put it in the small print) are not covered by the homes and contents insurance. So if you do own a bike and imagine that your home insurance covers it you might want to double-check with them BEFORE it goes walkies.
Friday, 26 June 2009
RIP: Michael Jackson
Pop Superstar Michael Jackson has died of a suspected heart attack, aged 50.
I'm not going to claim to be a big fan of his music, but I can't deny the impact he had on the music scene. He certainly had talent, even if he was a bit "odd" at times.
One thing that has already been mentioned in the press is the accusations of his alleged impropriety with minors. It is worth remembering that when this did go to court he was found innocent - and that allegedly one of the accusors is well known as a "grifter" (or con-artist) and has been sent to prison for it.
So was he guilty of anything? Probably only of being "different", and that should never be treated as a crime.
I'm not going to claim to be a big fan of his music, but I can't deny the impact he had on the music scene. He certainly had talent, even if he was a bit "odd" at times.
One thing that has already been mentioned in the press is the accusations of his alleged impropriety with minors. It is worth remembering that when this did go to court he was found innocent - and that allegedly one of the accusors is well known as a "grifter" (or con-artist) and has been sent to prison for it.
So was he guilty of anything? Probably only of being "different", and that should never be treated as a crime.
Friday, 29 May 2009
Thoughts on Unix File System Structure
There is a school of thought that believes that the Unix File System layout (or Filesystem Heirarchy Standard) is needlessly complicated. Some would go as far as to claim that it is fundementally broken.
The recent post on OSNews by Thom Holwerda (and especially many of the comments) provide some good examples of the perceived problems and the oft touted solutions.
There is a counter argument though, which goes something like this: "the Unix File System has been evolving for well over 30 years, isn't it strange that no-one noticed just how broken it is?"
Let's look at some of the arguments for and against the current system.
To make this easier, I'll pick up on some of the comments and see if they can be answered.
One quick point. In most cases I'm going to refer to Unix where this covers all Unix based operating systems. If I say something specific to GNU/Linux or another operating system then I'll name it.
I'm just trying to explain that many people are put off diving further into the intricacies of the computer simply because of how daunting everything is. By making a system easy to use and understand not only at the very highest level (the UI) but also all the levels below that, we might enable more people to actually *understand* their computers better, which would be beneficial to *all* of us.
I am of the strong belief that there is no sane reason WHATSOEVER why we couldn't make computers easier to use and understand on ALL levels, and not just at the top - other than geek job security.
This is a good place to start. The layout is there to simplify maintenance of the system, not to complicate it. This is nothing to do with "Job Security" - more to do with making a usable, maintainable system. Having people dipping into the OS structure (whether it be Windows, Unix or MacOS) would create MORE work for the support geek, not less.
I'll give you a real life example. Around ten years ago I installed Linux for a friend. This was back in the days that installing it was still a bit of an art. At the time getting XWindows up and running was cause for celebration, and as for working sound, IN YOUR DREAMS BUDDY!
After an hour or so of fiddling around with the config files, xf86config (remember that?), making sure that the correct packages were installed I gave him a quick run-though of how the system worked. As he had come from a DOS/Windows background I'd configured everything to look pretty similar, and showed how the basic commands worked (use "ls" instead of "dir", "cd" works about the same, "rm" instead of "del" and so forth) and gave a quick guided tour of XWindows, X11Amp and the other installed goodies.
He collared me the next day: "I thought you said this Linux stuff was stable. I restarted it and now I can't get back in! It's shit!"
On further investigation what he had done became apparent. He'd had a wander through the file system, picked some files that "didn't look important" (including /etc/passwd in this case) and deleted them to free up a bit of space.
This doesn't just happen with Linux. A year or so later the Telecoms manager at my company phoned me because his PC wouldn't boot any more. He'd been trying to upgrade Internet Explorer to the latest version and had run out of space on his C:\ drive. He'd managed to find a folder that didn't look that important but "had a lot of stuff in" it that he "didn't need" and deleted it. His PC had crashed part-way through and now it wouldn't start any more. Sadly the junk folder he'd chosen was called C:\WINDOWS.
OK, so these are vaguely amusing war stories but what is my point? Well, my point is this: Users don't understand operating systems. I'd go as far as to say that they shouldn't actually have to. In the majority of cases the best thing that a user can do is to not mess with the underlying OS at all. Hiding as much of it as possible from them is A Very Good Thing Indeed.
As is traditional at this point, lets turn to our old friend the analogy. Many people drive cars. You sit down, turn the ignition, grab the steering wheel, press down the accellerator and off you go (yes, I know that there is a little more to it than that, but you get the general idea). Now, how many drivers could strip an engine? How about the gears, know how they work? Could you strip the gearbox down if you needed to and reassemble it in a working condition afterwards?
The fact is that you don't need to know the mechanics of a car in order to drive one. Although anyone could pop open the bonnet and have a root around inside most people don't. If there is a problem, they take it to a garage.
Of course, some people DO tinker with their cars. They take a great deal of pride in being able to maintain and even customise their car. Is what they do easy? Of course not. Can anyone do it? No. Only an idiot would imagine that everyone can do everything, some degree of knowledge or learning may be required. This isn't meant to be an insult, but it is a fact.
To come back to the point of the analogy, is the Car any less useful because people don't understand how it works? Of course not.
This follows through to computers. Most people can use their computer quite happily with no idea of the underlying mechanisms. If they have problems then they can get in touch with their friendly neighbourhood technician. There is nothing stopping them learning about it if they want, just don't expect it to be easy. Just like a car, an operating system (and its component parts) is made to fulfil a function, not to be played around with.
pulseaudio is yet another layer on top of a broken audio foundation. Adding layers does not make things better, it just hides it a little longer.
Another good example of mistaken thinking. Abstraction can be a very good thing, and pulseaudio is an excellent example of this. Let's see how this works.
Just for the same of argument, lets say we were trying to write a simple audio player on GNU/Linux. Now, how do you make it play sounds? At a very basic level you might write directly to /dev/dsp. So now your app plays sounds. It might lock the /dev/dsp device but hey, this is just a simple example.
Let's up the stakes a bit and try and port the app to, say, Windows. What happened to /dev/dsp? It doesn't exist. How about MacOS X? Nope, not likely to work here either.
How does this relate to abstraction? Well, if our audio app uses pulseaudio to plays its sound it will now work on any platform that pulseaudio is supported on. For something like KDE that is aiming to be a cross platform environment this makes coding your apps an awful lot easier.
In other words the GNU/Linux audio foundation isn't broken, it just doesn't exist on Windows.
Why bin? Because that's where your 'binaries' are, right? oh, except there are programs now that are text files run through an interpreter, so that doesn't really apply. A user's files aren't under /usr, my webserver by default isn't under /svr, it's under /var/www. /etc? Yeah, something about etcetera really says 'config files'. Seriously, who thought /etc was a good name?
This is the biggie. To answer this, it is necessary to look at and understand where Unix came from.
First, another quick experiment. Try and find a Unix reference manual from any time in the last twenty years or so. The command references are still likely to work. Any shell scripts (providing you are using the modern version of the same interpreter) are also likely to work without any changes.
In the earliest days of Unix space was at a premium. Shorter command names meant shorter scripts (and less space in the file allocation tables). This is why the "base" commands are only two characters long, for example, "ls", "cd", "rm", "du" and so forth. Although we don't have the same physical limits these days there are a lot of scripts out there that rely on the short versions of the file names. Keeping them the same means that people don't have to re-learn all their skills with each new release of the OS (something that Microsoft could learn from).
This also follows through to the file system layout (again, I'm going to simplify this a bit, but hopefully you'll get the idea).
At the root of our Unix system we find these main folders:
These are the most basic parts of your Unix system. These are the base commands and libraries that are required to give you a bootable system with access to a network.
Moving down the tree, we come to /usr.
This is the next level up. /usr is NOT where user files are stored, or for user generated versions of applications. In this case "usr" stands for Unix System Resources (although originally this was the location of users home directories). This is where the vendor provided files live (the stuff that isn't part of the standard base files). For those who argue about everything being shoved into /usr by Ubuntu, RedHat or whoever, this is actually where they SHOULD go. Anything in here should have been provided by the distro maintainers. Between / and /USR that should contain everything that your operating system needs. All applications, all configuration files, everything.
So what about /usr/local?
The /usr/local section of the file system is where any binaries that YOU create are stored, along with their configuration files. If you wanted to create a custom version of any application it should appear in here. This keeps your stuff separate from what the vendor provides, and in theory prevents you from permanently damaging the operating system. If you do manage to balls things up totally then deleting /usr/local should be enough to fix it again (as all the vendor provided files should still be intact and untouched).
Another benefit of this approach is that once your root system is installed, the actual location of /usr becomes irelevent. It could just as easily be on a shared network drive as it could be on your local disk. If disk space is at a premium this can be a very effective way of working. It also means that every users has the same base system, because they are running the same apps from the same place.
OK, so thats not as useful for a single user system, but it is still functionality that is used in some places. Just because YOU don't use it, doesn't mean it isn't useful.
Before anyone pipes up yes, I am fully aware of /opt, /var, /tmp, /dev and so forth. All of these have their uses, but are not relevent for the purposes of this discussion.
That's a big giant gaping hole in Linux, not in Thom's proposed filesystem layout. There's no such distrinction in a Linux distro, as there's no such thing as "the OS" vs "the user apps". Once someone gets the balls to stand up and say "this is the OS" and package it separately from "the user apps", the FHS will never change.
Actually GNU/Linux and Unix already does separate the OS from the User Apps. Remember our three levels? The bottom level is the OS - the bit you need to get a working system (ie. /bin /sbin /lib and so on). Anything in /usr or above is a user app. Yes, you may see XFree86 as essential, but GNU/Linux can run without it. Same for Mozilla, and FireFox and anything else in /usr or /usr/local.
* * *
The biggest problem there is with operating systems in general (not just GNU/Linux) is that for some reason people assume that it should all be easy. The desktop is easy to use therefore the underlying system should also be easy to use.
This is a very strange form of logic. Simplifying where necessary is a good thing, providing it doesn't impact on functionality or reliability. To go back to our car analogy there would be an argument for simplifying the innards of the car to make it much easier to understand and maintain for the common user. As a thought experiment, let's try it.
Let's start with the gearbox. Much too complicated and a potential point of failure, choosing a good default gear should do away with the need for that. How about a petrol engine? All that internal combustion malarkey sounds a bit dangerous to me. Running a vehicle based on small controlled explosions? Stuff that for a game of soldiers! Let's replace that with an electric one. But wait, maybe some people don't understand how an electric motor works either. So on second thoughts, let's replace it with a pedal driven one.
Hmm, it's a bit heavy to pedal, so lets remove most of the metal bodywork, a canvass roof should suffice (plus it's easy to repair or replace).
Anti-lock brakes? They'd have to go as well. Disc brakes are much simpler. Power streering? Not really needed now, drop that too. We can also leave out the airbags as we won't be going that fast now anyway.
So what are we left with? Basically a four-wheeled bicycle. Handy in some circumstances, easy to maintain but not necessarily as useful as what we started with.
Yes, this is taking it to the extremes, but that is the equivalent of what people are suggesting is done to the Unix file system. Let's remove everything that we don't understand the reasons for and just use what is left. Sadly what is left may be easy to understand, but its functionality would likely be crippled.
* * *
Does any of this mean that people (like GoBoLinux for example) shouldn't experiment and try different things? Of course not. Finding new (and potentially better) ways of doing things is something that can end up as a benefit to everyone. But making changes for the sake of being different is not so good.
Looking closer at GoBoLinux it is adding one hell of a lot of complexity to the system in order to just keep things working (have a check of http://www.gobolinux.org/index.php?page=at_a_glance and ask yourself about all the symlinks), whilst loosing some of the benefits of the traditional Unix system.
Reading http://www.gobolinux.org/index.php?page=doc/articles/clueless gives plenty of information on why GoBoLinux have chosen their approach. It also re-inforces some of the points made above, especially with regard to the three-tier approach of traditional Unix.
* * *
In the end, used properly the current Unix File System Layout actually works rather well, changing to something else isn't going to solve the problems of people ignoring a standard. All it will achieve is change for the sake of it, and chances are some benefits will be lost in the process.
The recent post on OSNews by Thom Holwerda (and especially many of the comments) provide some good examples of the perceived problems and the oft touted solutions.
There is a counter argument though, which goes something like this: "the Unix File System has been evolving for well over 30 years, isn't it strange that no-one noticed just how broken it is?"
Let's look at some of the arguments for and against the current system.
To make this easier, I'll pick up on some of the comments and see if they can be answered.
One quick point. In most cases I'm going to refer to Unix where this covers all Unix based operating systems. If I say something specific to GNU/Linux or another operating system then I'll name it.
I'm just trying to explain that many people are put off diving further into the intricacies of the computer simply because of how daunting everything is. By making a system easy to use and understand not only at the very highest level (the UI) but also all the levels below that, we might enable more people to actually *understand* their computers better, which would be beneficial to *all* of us.
I am of the strong belief that there is no sane reason WHATSOEVER why we couldn't make computers easier to use and understand on ALL levels, and not just at the top - other than geek job security.
This is a good place to start. The layout is there to simplify maintenance of the system, not to complicate it. This is nothing to do with "Job Security" - more to do with making a usable, maintainable system. Having people dipping into the OS structure (whether it be Windows, Unix or MacOS) would create MORE work for the support geek, not less.
I'll give you a real life example. Around ten years ago I installed Linux for a friend. This was back in the days that installing it was still a bit of an art. At the time getting XWindows up and running was cause for celebration, and as for working sound, IN YOUR DREAMS BUDDY!
After an hour or so of fiddling around with the config files, xf86config (remember that?), making sure that the correct packages were installed I gave him a quick run-though of how the system worked. As he had come from a DOS/Windows background I'd configured everything to look pretty similar, and showed how the basic commands worked (use "ls" instead of "dir", "cd" works about the same, "rm" instead of "del" and so forth) and gave a quick guided tour of XWindows, X11Amp and the other installed goodies.
He collared me the next day: "I thought you said this Linux stuff was stable. I restarted it and now I can't get back in! It's shit!"
On further investigation what he had done became apparent. He'd had a wander through the file system, picked some files that "didn't look important" (including /etc/passwd in this case) and deleted them to free up a bit of space.
This doesn't just happen with Linux. A year or so later the Telecoms manager at my company phoned me because his PC wouldn't boot any more. He'd been trying to upgrade Internet Explorer to the latest version and had run out of space on his C:\ drive. He'd managed to find a folder that didn't look that important but "had a lot of stuff in" it that he "didn't need" and deleted it. His PC had crashed part-way through and now it wouldn't start any more. Sadly the junk folder he'd chosen was called C:\WINDOWS.
OK, so these are vaguely amusing war stories but what is my point? Well, my point is this: Users don't understand operating systems. I'd go as far as to say that they shouldn't actually have to. In the majority of cases the best thing that a user can do is to not mess with the underlying OS at all. Hiding as much of it as possible from them is A Very Good Thing Indeed.
As is traditional at this point, lets turn to our old friend the analogy. Many people drive cars. You sit down, turn the ignition, grab the steering wheel, press down the accellerator and off you go (yes, I know that there is a little more to it than that, but you get the general idea). Now, how many drivers could strip an engine? How about the gears, know how they work? Could you strip the gearbox down if you needed to and reassemble it in a working condition afterwards?
The fact is that you don't need to know the mechanics of a car in order to drive one. Although anyone could pop open the bonnet and have a root around inside most people don't. If there is a problem, they take it to a garage.
Of course, some people DO tinker with their cars. They take a great deal of pride in being able to maintain and even customise their car. Is what they do easy? Of course not. Can anyone do it? No. Only an idiot would imagine that everyone can do everything, some degree of knowledge or learning may be required. This isn't meant to be an insult, but it is a fact.
To come back to the point of the analogy, is the Car any less useful because people don't understand how it works? Of course not.
This follows through to computers. Most people can use their computer quite happily with no idea of the underlying mechanisms. If they have problems then they can get in touch with their friendly neighbourhood technician. There is nothing stopping them learning about it if they want, just don't expect it to be easy. Just like a car, an operating system (and its component parts) is made to fulfil a function, not to be played around with.
pulseaudio is yet another layer on top of a broken audio foundation. Adding layers does not make things better, it just hides it a little longer.
Another good example of mistaken thinking. Abstraction can be a very good thing, and pulseaudio is an excellent example of this. Let's see how this works.
Just for the same of argument, lets say we were trying to write a simple audio player on GNU/Linux. Now, how do you make it play sounds? At a very basic level you might write directly to /dev/dsp. So now your app plays sounds. It might lock the /dev/dsp device but hey, this is just a simple example.
Let's up the stakes a bit and try and port the app to, say, Windows. What happened to /dev/dsp? It doesn't exist. How about MacOS X? Nope, not likely to work here either.
How does this relate to abstraction? Well, if our audio app uses pulseaudio to plays its sound it will now work on any platform that pulseaudio is supported on. For something like KDE that is aiming to be a cross platform environment this makes coding your apps an awful lot easier.
In other words the GNU/Linux audio foundation isn't broken, it just doesn't exist on Windows.
Why bin? Because that's where your 'binaries' are, right? oh, except there are programs now that are text files run through an interpreter, so that doesn't really apply. A user's files aren't under /usr, my webserver by default isn't under /svr, it's under /var/www. /etc? Yeah, something about etcetera really says 'config files'. Seriously, who thought /etc was a good name?
This is the biggie. To answer this, it is necessary to look at and understand where Unix came from.
First, another quick experiment. Try and find a Unix reference manual from any time in the last twenty years or so. The command references are still likely to work. Any shell scripts (providing you are using the modern version of the same interpreter) are also likely to work without any changes.
In the earliest days of Unix space was at a premium. Shorter command names meant shorter scripts (and less space in the file allocation tables). This is why the "base" commands are only two characters long, for example, "ls", "cd", "rm", "du" and so forth. Although we don't have the same physical limits these days there are a lot of scripts out there that rely on the short versions of the file names. Keeping them the same means that people don't have to re-learn all their skills with each new release of the OS (something that Microsoft could learn from).
This also follows through to the file system layout (again, I'm going to simplify this a bit, but hopefully you'll get the idea).
At the root of our Unix system we find these main folders:
/ -- root
/bin -- binaries
/sbin -- system tools (ie. fdisk, hdparm, fsck)
/lib -- libraries
/etc -- configuration files / scripts / anything that doesn't fit
in the other directories
These are the most basic parts of your Unix system. These are the base commands and libraries that are required to give you a bootable system with access to a network.
Moving down the tree, we come to /usr.
/usr -- root
/usr/bin -- binaries
/usr/sbin -- system tools
/usr/lib -- libraries
/usr/etc -- configuration files / scripts / anything that doesn't fit
in the other directories
This is the next level up. /usr is NOT where user files are stored, or for user generated versions of applications. In this case "usr" stands for Unix System Resources (although originally this was the location of users home directories). This is where the vendor provided files live (the stuff that isn't part of the standard base files). For those who argue about everything being shoved into /usr by Ubuntu, RedHat or whoever, this is actually where they SHOULD go. Anything in here should have been provided by the distro maintainers. Between / and /USR that should contain everything that your operating system needs. All applications, all configuration files, everything.
So what about /usr/local?
/usr/local -- root
/usr/local/bin -- binaries
/usr/local/sbin -- system tools
/usr/local/lib -- libraries
/usr/local/etc -- configuration files / scripts / anything that doesn't fit
in the other directories
The /usr/local section of the file system is where any binaries that YOU create are stored, along with their configuration files. If you wanted to create a custom version of any application it should appear in here. This keeps your stuff separate from what the vendor provides, and in theory prevents you from permanently damaging the operating system. If you do manage to balls things up totally then deleting /usr/local should be enough to fix it again (as all the vendor provided files should still be intact and untouched).
Another benefit of this approach is that once your root system is installed, the actual location of /usr becomes irelevent. It could just as easily be on a shared network drive as it could be on your local disk. If disk space is at a premium this can be a very effective way of working. It also means that every users has the same base system, because they are running the same apps from the same place.
OK, so thats not as useful for a single user system, but it is still functionality that is used in some places. Just because YOU don't use it, doesn't mean it isn't useful.
Before anyone pipes up yes, I am fully aware of /opt, /var, /tmp, /dev and so forth. All of these have their uses, but are not relevent for the purposes of this discussion.
For a start, it has a gaping hole: he doesn't explain how you separate "System" from "Programs".
That's a big giant gaping hole in Linux, not in Thom's proposed filesystem layout. There's no such distrinction in a Linux distro, as there's no such thing as "the OS" vs "the user apps". Once someone gets the balls to stand up and say "this is the OS" and package it separately from "the user apps", the FHS will never change.
Actually GNU/Linux and Unix already does separate the OS from the User Apps. Remember our three levels? The bottom level is the OS - the bit you need to get a working system (ie. /bin /sbin /lib and so on). Anything in /usr or above is a user app. Yes, you may see XFree86 as essential, but GNU/Linux can run without it. Same for Mozilla, and FireFox and anything else in /usr or /usr/local.
* * *
The biggest problem there is with operating systems in general (not just GNU/Linux) is that for some reason people assume that it should all be easy. The desktop is easy to use therefore the underlying system should also be easy to use.
This is a very strange form of logic. Simplifying where necessary is a good thing, providing it doesn't impact on functionality or reliability. To go back to our car analogy there would be an argument for simplifying the innards of the car to make it much easier to understand and maintain for the common user. As a thought experiment, let's try it.
Let's start with the gearbox. Much too complicated and a potential point of failure, choosing a good default gear should do away with the need for that. How about a petrol engine? All that internal combustion malarkey sounds a bit dangerous to me. Running a vehicle based on small controlled explosions? Stuff that for a game of soldiers! Let's replace that with an electric one. But wait, maybe some people don't understand how an electric motor works either. So on second thoughts, let's replace it with a pedal driven one.
Hmm, it's a bit heavy to pedal, so lets remove most of the metal bodywork, a canvass roof should suffice (plus it's easy to repair or replace).
Anti-lock brakes? They'd have to go as well. Disc brakes are much simpler. Power streering? Not really needed now, drop that too. We can also leave out the airbags as we won't be going that fast now anyway.
So what are we left with? Basically a four-wheeled bicycle. Handy in some circumstances, easy to maintain but not necessarily as useful as what we started with.
Yes, this is taking it to the extremes, but that is the equivalent of what people are suggesting is done to the Unix file system. Let's remove everything that we don't understand the reasons for and just use what is left. Sadly what is left may be easy to understand, but its functionality would likely be crippled.
* * *
Does any of this mean that people (like GoBoLinux for example) shouldn't experiment and try different things? Of course not. Finding new (and potentially better) ways of doing things is something that can end up as a benefit to everyone. But making changes for the sake of being different is not so good.
Looking closer at GoBoLinux it is adding one hell of a lot of complexity to the system in order to just keep things working (have a check of http://www.gobolinux.org/index.php?page=at_a_glance and ask yourself about all the symlinks), whilst loosing some of the benefits of the traditional Unix system.
Reading http://www.gobolinux.org/index.php?page=doc/articles/clueless gives plenty of information on why GoBoLinux have chosen their approach. It also re-inforces some of the points made above, especially with regard to the three-tier approach of traditional Unix.
* * *
In the end, used properly the current Unix File System Layout actually works rather well, changing to something else isn't going to solve the problems of people ignoring a standard. All it will achieve is change for the sake of it, and chances are some benefits will be lost in the process.
Tuesday, 26 May 2009
Puncture-resistant Bike Tires
In the year(ish) that I've been a commuting cyclist I've been lucky enough to have avoided getting any punctures. My daughter has been less lucky. A couple of weeks ago she managed to get a staple in her back tire which caused multiple small punctures.
Trying to repair a puncture on the back tire is about a big a pain in the arse as you can get. You have the choice between trying to find the puncture without removing the wheel (tricky, time consuming and runs the risk of tearing the tube), or having to remove the rear brake, chain, gears and the wheel to get the inner-tube out, and that's before you even start trying to find and repair the puncture.
I'd reached the point where I was ready to call it quits, buy an inner-tube from Halfords and pay them the extra to fit it ('cos I'm a lazy git when it boils down to it).
Although I've not had any punctures I have managed to shatter the right pedal on my bike. I'm not sure how I managed it but rest asured it was totally wrecked, so today I spent my lunchbreak looking for a pair of standard pedals (in other words cheap, 'cos not only am I lazy, but I'm also a tight-wad).
Our local hardware store was selling pedals at £2.99 a pair, which isn't too bad really. They also had tubes of this strange-looking orangey-pink stuff called "Doctor Sludge."
According to the label it repairs punctures and makes the inner-tube puncture-proof for the lifetime of the tube. Did I hear a "yeah right?" I thought so. As it was going for just over four quid I decided to give it a shot.
What does this involve? Well, first you unscrew and remove the valve from the inner-tube (you get a small tool for this with the sludge), next attach the bottle of sludge using the extendable tube and pour about half the 250ml bottle into the tire. After that you replace the valve, pump up the tire and that's it, job done.
It works by the air pressure in the tire forcing the sludge out through any holes, at which point the sludge sets solid. Any (small) punctures after the tire has been treated should heal straight away.
Well, I've just tried this with my daughters bike. Bear in mind that I've had four attempts at repairing the tire the old-fashioned way. I've probably wasted a couple of hours and had a pretty frustrating time into the bargain messing with the bowl of water, rubber glue, repair patches and so forth. To make it worse, after all that effort it still wasn't fixed (it would deflate after about half-an-hour).
The Doctor Sludge method took around ten minutes, and so far (twelve hours later) the tire has stayed fully inflated. Not only that, but I've got enough left to sort out her front tire as well.
Before anyone asks, no, I'm not associated with the Doctor Sludge people. I think I'll be buying some more of this for my own bike (unless anyone from Doctor Sludge is reading this and feels like sending me a couple of free bottles. . .).
Trying to repair a puncture on the back tire is about a big a pain in the arse as you can get. You have the choice between trying to find the puncture without removing the wheel (tricky, time consuming and runs the risk of tearing the tube), or having to remove the rear brake, chain, gears and the wheel to get the inner-tube out, and that's before you even start trying to find and repair the puncture.
I'd reached the point where I was ready to call it quits, buy an inner-tube from Halfords and pay them the extra to fit it ('cos I'm a lazy git when it boils down to it).
Although I've not had any punctures I have managed to shatter the right pedal on my bike. I'm not sure how I managed it but rest asured it was totally wrecked, so today I spent my lunchbreak looking for a pair of standard pedals (in other words cheap, 'cos not only am I lazy, but I'm also a tight-wad).
Our local hardware store was selling pedals at £2.99 a pair, which isn't too bad really. They also had tubes of this strange-looking orangey-pink stuff called "Doctor Sludge."
According to the label it repairs punctures and makes the inner-tube puncture-proof for the lifetime of the tube. Did I hear a "yeah right?" I thought so. As it was going for just over four quid I decided to give it a shot.
What does this involve? Well, first you unscrew and remove the valve from the inner-tube (you get a small tool for this with the sludge), next attach the bottle of sludge using the extendable tube and pour about half the 250ml bottle into the tire. After that you replace the valve, pump up the tire and that's it, job done.
It works by the air pressure in the tire forcing the sludge out through any holes, at which point the sludge sets solid. Any (small) punctures after the tire has been treated should heal straight away.
Well, I've just tried this with my daughters bike. Bear in mind that I've had four attempts at repairing the tire the old-fashioned way. I've probably wasted a couple of hours and had a pretty frustrating time into the bargain messing with the bowl of water, rubber glue, repair patches and so forth. To make it worse, after all that effort it still wasn't fixed (it would deflate after about half-an-hour).
The Doctor Sludge method took around ten minutes, and so far (twelve hours later) the tire has stayed fully inflated. Not only that, but I've got enough left to sort out her front tire as well.
Before anyone asks, no, I'm not associated with the Doctor Sludge people. I think I'll be buying some more of this for my own bike (unless anyone from Doctor Sludge is reading this and feels like sending me a couple of free bottles. . .).
Saturday, 9 May 2009
Dell GX270
I've normally got mixed feelings about Dells. On the up side they tend to be fairly reliable (apart from some well publicised problems with POTs bursting on some motherboards). The downside is that they tend to be fairly hard to upgrade.
So why change my computer for an old GX270? Well, the fact is that it is significantly faster than the venerable old Athlon XP 2200 which has served me well for the past doo-de-dah years (where doo-de-dah is a number between one and too-many).
One thing that is taking some getting used to is the noise, or lack of it. My original PC sounded not unlike a Harrier jump jet taking off when it was started, and made a constant noise whilst in use. Yes, you get used to it but My God was it loud!
To give you an idea of how quiet the GX270 is, my LCD monitor makes more noise. Seriously, this thing is whisper quiet. I'd go as far as to say it is one of the quietest PCs that I've ever used (and that is including some of those with specialised cooling equipment).
Really, the only problem with this model of Dell is reliability. Hopefully this will be one of the PCs that doesn't suffer with swollen capacitors, think of it as the XBox 360 of the PC world.
I don't like playing Russian Roulette with my equipment, but I'm going to take a chance and hope for the best (I'm just going to have to put my original PC "on ice" as a backup in case of emergencies).
So why change my computer for an old GX270? Well, the fact is that it is significantly faster than the venerable old Athlon XP 2200 which has served me well for the past doo-de-dah years (where doo-de-dah is a number between one and too-many).
One thing that is taking some getting used to is the noise, or lack of it. My original PC sounded not unlike a Harrier jump jet taking off when it was started, and made a constant noise whilst in use. Yes, you get used to it but My God was it loud!
To give you an idea of how quiet the GX270 is, my LCD monitor makes more noise. Seriously, this thing is whisper quiet. I'd go as far as to say it is one of the quietest PCs that I've ever used (and that is including some of those with specialised cooling equipment).
Really, the only problem with this model of Dell is reliability. Hopefully this will be one of the PCs that doesn't suffer with swollen capacitors, think of it as the XBox 360 of the PC world.
I don't like playing Russian Roulette with my equipment, but I'm going to take a chance and hope for the best (I'm just going to have to put my original PC "on ice" as a backup in case of emergencies).
Friday, 8 May 2009
Back Again. . .
I've been kind of busy of late - hence the lack of blogging.
In fact I've written a couple of pieces (that I'm going to have to finish and post) but, well, sometimes life just gets in the way, and recently life has been getting in the way in quite a large way.
So, two funerals later (seriously) and I'm back.
To get the ball rolling again, here are some of the things that I would have been blogging about under normal circumstances.
Hackintosh Havoc
I've had a play with a home-made hackintosh. What do I mean by that? Well, basically it is MacOS X running on a standard Intel PC. Was it worth the effort? Probably not. To cut a long blog short you would be better buying a second hand Mac than the amount of effort you will need to go to in order to get it working properly (and in case you are wondering - it never really worked properly, although it was damn close).
In case any Apple lawyers are reading, the hard disk used was humanely destroyed after the experiment. No copies of OSX Tiger were harmed in attemping this.
Ubuntu Blues
I've recently aquired a Dell OptiPlex 270 (Pentium 4, 2.8ghz folks!) which I'm going to be using as a replacement for my venerable 1.8Gghz Athlon XP 2200. The strange thing about this PC is that although it supports Hyper Threading (sort of a cheap alternative to Dual Core) this isn't enabled by default. Strange but true. Once it has been enabled the PC performs rather well with Windows XP.
Of course, I also installed Ubuntu alongside it. Unfortunately the "newest" version of Ubuntu I had to hand was an 8.04 install. Not to be deterred by this I installed it (reducing the XP partition down to 20 gig) then upgraded it to 8.10 and then again to 9.04.
One problem with the OptiPlex 270 is that it needs a low profile AGP graphics card - and the only one I was able to rustle up at short notice was an ancient 16 meg ATI Rage Pro 128. Not the best card by a long straw - but better than the onboard 8 meg(!) Intel one.
Luckily I was able to borrow a 128 meg Geforce FX 5200 PCI card - which worked well in Windows (after a little bit of fiddling to disable the onboard card). It also worked well in Ubuntu - up to the point where I rebooted and checkdisk started - but claimed that it couldn't repair the file system. After a couple of hours of running FSCK on Ubuntu's root partition (and watching hundreds of errors appear on screen) I gave up, downloaded the Ubuntu 9.04 install CD and reinstalled from scratch (this time as EXT4).
As the PCI graphics card was still too slow I bought a cheap-and-cheerful low profile AGP card (another Geforce 5200) which now runs like a charm. Ubuntu accepted the new card without problems (booted up and hey! It works!) - Windows however took about an hour to get everything running correctly (which included uninstalling and re-installing the drivers, swearing and playing around with different configuration options to get the card recognised correctly, and then to get the resolution so that it would change from 640x480 up to 1280x1024).
Ubuntu 9.04 boots extremely quickly (just like Windows XP), and is ready to work as soon as the desktop is displayed (unlike XP which is unusuable for the first minute or two).
SCO is Gonna Go
It has been recommended by the U.S. Trustee that SCO is moved out of Chapter 11 Bancruptcy into full Chapter 7. This basically means that it has been agreed that there is no future for SCO as a company, and so its assets are to be sold and the proceeds given to the creditors.
Could this be the end of the extremely long running SCO vs The World saga?
Seeing as SCO, as usual, are planning to oppose this decision (gosh, really?).
So what did Darl McBride have to say? “We are reviewing the motion that was filed in Delaware today with counsel and will have a detailed response for the court in due course. We plan to oppose the motion and present our own suggested course of action to the court."
Time will tell if this lawsuit still has legs.
In fact I've written a couple of pieces (that I'm going to have to finish and post) but, well, sometimes life just gets in the way, and recently life has been getting in the way in quite a large way.
So, two funerals later (seriously) and I'm back.
To get the ball rolling again, here are some of the things that I would have been blogging about under normal circumstances.
Hackintosh Havoc
I've had a play with a home-made hackintosh. What do I mean by that? Well, basically it is MacOS X running on a standard Intel PC. Was it worth the effort? Probably not. To cut a long blog short you would be better buying a second hand Mac than the amount of effort you will need to go to in order to get it working properly (and in case you are wondering - it never really worked properly, although it was damn close).
In case any Apple lawyers are reading, the hard disk used was humanely destroyed after the experiment. No copies of OSX Tiger were harmed in attemping this.
Ubuntu Blues
I've recently aquired a Dell OptiPlex 270 (Pentium 4, 2.8ghz folks!) which I'm going to be using as a replacement for my venerable 1.8Gghz Athlon XP 2200. The strange thing about this PC is that although it supports Hyper Threading (sort of a cheap alternative to Dual Core) this isn't enabled by default. Strange but true. Once it has been enabled the PC performs rather well with Windows XP.
Of course, I also installed Ubuntu alongside it. Unfortunately the "newest" version of Ubuntu I had to hand was an 8.04 install. Not to be deterred by this I installed it (reducing the XP partition down to 20 gig) then upgraded it to 8.10 and then again to 9.04.
One problem with the OptiPlex 270 is that it needs a low profile AGP graphics card - and the only one I was able to rustle up at short notice was an ancient 16 meg ATI Rage Pro 128. Not the best card by a long straw - but better than the onboard 8 meg(!) Intel one.
Luckily I was able to borrow a 128 meg Geforce FX 5200 PCI card - which worked well in Windows (after a little bit of fiddling to disable the onboard card). It also worked well in Ubuntu - up to the point where I rebooted and checkdisk started - but claimed that it couldn't repair the file system. After a couple of hours of running FSCK on Ubuntu's root partition (and watching hundreds of errors appear on screen) I gave up, downloaded the Ubuntu 9.04 install CD and reinstalled from scratch (this time as EXT4).
As the PCI graphics card was still too slow I bought a cheap-and-cheerful low profile AGP card (another Geforce 5200) which now runs like a charm. Ubuntu accepted the new card without problems (booted up and hey! It works!) - Windows however took about an hour to get everything running correctly (which included uninstalling and re-installing the drivers, swearing and playing around with different configuration options to get the card recognised correctly, and then to get the resolution so that it would change from 640x480 up to 1280x1024).
Ubuntu 9.04 boots extremely quickly (just like Windows XP), and is ready to work as soon as the desktop is displayed (unlike XP which is unusuable for the first minute or two).
SCO is Gonna Go
It has been recommended by the U.S. Trustee that SCO is moved out of Chapter 11 Bancruptcy into full Chapter 7. This basically means that it has been agreed that there is no future for SCO as a company, and so its assets are to be sold and the proceeds given to the creditors.
Could this be the end of the extremely long running SCO vs The World saga?
Seeing as SCO, as usual, are planning to oppose this decision (gosh, really?).
So what did Darl McBride have to say? “We are reviewing the motion that was filed in Delaware today with counsel and will have a detailed response for the court in due course. We plan to oppose the motion and present our own suggested course of action to the court."
Time will tell if this lawsuit still has legs.
Subscribe to:
Posts (Atom)
