Re: [Hampshire] [OT] MTBF
2009/7/19 James Courtier-Dutton : > 2009/7/19 Philip Stubbs : >> 2009/7/19 James Courtier-Dutton : >> >>> To get a MTBF figure: >>> Approx MTBF = ( Number of Devices tested * Test time ) / Number of failures. >> >> As ever, that is not always the case. I used to work for an aerospace >> company, and they would quote MTBF before one sample had even been >> built, let alone tested to failure. In that case, the MTBF was >> calculated based on some rules. I don't know the details but I do >> remember that number of components were a key variable. Therefore the >> pumps they made were designed to have a few parts as possible. The >> MTBF number was therefore a result of some clever work by >> statisticians. I would not be surprised if that is the case here. No > > It is my understanding that once one has the MTBF of each single component. > Once one knows how they are fitted together, one can calculate > availability figures for the sum of the parts. > So, if one has a network with redundant devices, one can take the MTBF > together with the mean time to restore (MTTR) of each device on the > network and come up with a total availability for the entire network. > The knowledge area is called RAMS analysis. (Reliability, > Availability, Maintainability and Safety). > The case is similar for components on a circuit board. One can have > the MTBF of each resistor, etc. on the circuit board and calculate > the the MTBF for the entire circuit board. > As a general rule, more devices in series makes the result worse, more > devices in parallel make the results better. This is why more > components in the pump made it worse because I expect few of them were > redundant components. Sounds like you know more about this than me. (not hard) :-) Having a figure for MTBF is a good thing. Being able to calculate a MTBF at the design stage is also a good thing. What irritates me is when a marketing department picks up on a measure, such as MTBF or Watts or Hz or whatever, decide this is a good indicator for ho well a product performs, and then starts pressuring the engineering side to do whatever is required to increase the number. It then becomes distorted. An example. Vacuum cleaners used to be rated only in watts. If you wanted a vacuum cleaner with lots of suck, you bought one that consumed the most watts. However, the way the watts are calculated were standardized. Run the vacuum in free air for one minute. Run the vacuum with its inlet blocked for one minute. Average watts consumed is then the rating. Marketing then say to the engineers, we need more watts. Well the vacuum consumes less power when the inlet is blocked, so the engineers introduce leaks into the design, so that when the inlet is blocked, the pump is still shifting air and doing work, keeping the power consumption up. Never mind that the vacuum performance is compromised. The end result is I no longer have much faith in the numbers on the box. The more colours, pictures and words on the box means more input from marketing, and the greater the pinch of salt needed. :-) My apologies to anybody here in marketing. :-) -- Philip Stubbs -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] [OT] MTBF
2009/7/19 James Courtier-Dutton : > 2009/7/19 Philip Stubbs : >> 2009/7/19 James Courtier-Dutton : >> >>> To get a MTBF figure: >>> Approx MTBF = ( Number of Devices tested * Test time ) / Number of failures. >> >> As ever, that is not always the case. I used to work for an aerospace >> company, and they would quote MTBF before one sample had even been P.S. I currently work in the Space sector, amongst other things. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] [OT] MTBF
2009/7/19 Philip Stubbs : > 2009/7/19 James Courtier-Dutton : > >> To get a MTBF figure: >> Approx MTBF = ( Number of Devices tested * Test time ) / Number of failures. > > As ever, that is not always the case. I used to work for an aerospace > company, and they would quote MTBF before one sample had even been > built, let alone tested to failure. In that case, the MTBF was > calculated based on some rules. I don't know the details but I do > remember that number of components were a key variable. Therefore the > pumps they made were designed to have a few parts as possible. The > MTBF number was therefore a result of some clever work by > statisticians. I would not be surprised if that is the case here. No It is my understanding that once one has the MTBF of each single component. Once one knows how they are fitted together, one can calculate availability figures for the sum of the parts. So, if one has a network with redundant devices, one can take the MTBF together with the mean time to restore (MTTR) of each device on the network and come up with a total availability for the entire network. The knowledge area is called RAMS analysis. (Reliability, Availability, Maintainability and Safety). The case is similar for components on a circuit board. One can have the MTBF of each resistor, etc. on the circuit board and calculate the the MTBF for the entire circuit board. As a general rule, more devices in series makes the result worse, more devices in parallel make the results better. This is why more components in the pump made it worse because I expect few of them were redundant components. James -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] [OT] MTBF
2009/7/19 James Courtier-Dutton : > To get a MTBF figure: > Approx MTBF = ( Number of Devices tested * Test time ) / Number of failures. As ever, that is not always the case. I used to work for an aerospace company, and they would quote MTBF before one sample had even been built, let alone tested to failure. In that case, the MTBF was calculated based on some rules. I don't know the details but I do remember that number of components were a key variable. Therefore the pumps they made were designed to have a few parts as possible. The MTBF number was therefore a result of some clever work by statisticians. I would not be surprised if that is the case here. No doubt a marketing guy has seen a nice big number written and decided to use that in marketing the product. In reality, it probably means very little, just at the watts quoted on stereo's and vacuum cleaners bares little to the actual real world performance. -- Philip Stubbs -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] disabling flash adverts
Isaac Close wrote: > Within 1 minute of reading your answer I have installed Flashblock, it was > very simple to do. Has it proved reliable for people so far, I wonder ? > Works fine for me, though I had forgotten I had installed it at first, so wonderd why youtube and iplayer didn't show videos straightaway! Right-click and allow was an intuitive interface to allow some sites always to be allowed to show flash immediately. Simon -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] What do you think?
Stephen Davies wrote: > > Conclusions. > > While the ambitions of those who want to relegate the command line to > history are very laudable, there are many cases where it is the only > place to get the job done and done with certainty. > In addition to that, until Linux does not use any shell scripts on > startup/shutdown the command line will be an essential for developers, > sysadmins and even users (at times). I don’t think that reliance upon > scripts will be removed anytime soon after all, we don’t want the mess > that is the Windows Registry re-invented do we? > > > I can't see my day to day job of sysadmin will move to a GUI only option. The reason why M$ have been forced to produce a "power shell" is because sysadmins insisted they need it to maintain both windows and Linux. The power of the command line is it can be scripted easily, quickly and very effectively. GUIs do not have the flexibility to cover all the different needs. Therefore the command line tools like ifconfig, ping, grep, vim, awk, perl, python, sed and others will be with us for a long time! Non sys admins might be able to just use GUIs for normal use, but I doubt they will be able to fault find without the command line in both windows and Linux. John. -- -- Discover Linux - Open Source Solutions to Business and Schools http://discoverlinux.co.uk -- -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] Interesting Hardware Reference Poster
2009/7/19 Sean Gibbins : > Subject says it all really: > > http://tinyurl.com/lf3dqb > > I thought it might come in handy for other folks like me who sometimes > find themselves playing with older kit. Heee-wack! That is pretty funky! I feel tempted to print it out just for the geek appeal. I I expanded the image and was thinking "where's the RAM?"... then found that my window was only showing two thirds of the width. Nice one... even though I very rarely take machines to bits and have never e.g. de/populated a motherboard it's a great resource to know about. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] What do you think?
Hi Stephen, On Sun, Jul 19, 2009 at 02:06:13PM +0100, Stephen Davies wrote: > As everything in Linux/Unix is a file and the majority of these files > are plain text there is a great temptation to edit them manually > especially if you are remotely logged into the system over a slow > connection and using the GUI is not practicable. If use of the GUI is not practical then I don't see the point of configuring it remotely, use a different tool altogether. I also don't agree that configuring a GUI application must be done with text files. If the application is a GUI then I think it should be configured with a GUI, preferably part of the same application itself. It might be fine to read a config file to change some of the more esoteric options, but I don't see why the majority of configuration can't be done in the GUI. It seems to work for Firefox, which is the largest GUI application I run. By the way, I tend to prefer non-GUI applications for most things. > Once you have done that there is a danger that the changes you make will > not be picked up by the GUI application. This particularly applies to > comments. Nice and helpful as they are, how many GUI’s distributed in a > standard Linux Distro today can handle comments. I don't know but it seems a trivial problem for the author of the GUI software to overcome. > It is good practice to comment any changes so that the next person who > comes along to fix the problem you edit has just caused can know who did > what, when & why to the file. Yep, the version history strikes back. How > many GUI’s give you the opportunity to add a new bit oh version history > to the file? Not many I’d be willing to guess. The configuration of client software is typically not versioned. Do you need it to be? It's a good question about how to maintain central configuration control for GUI desktop software. > Then comes CVS (or something similar). We all know that it is good > practice to use CVS/SVN/git or some commercial package to store those > ultra critical files in so that when your system goes down in a heap of > flames (it does happen) you can pull everything out of your Source > Control System and deploy it on the new system knowing that it is the > latest version. > Some of these systems add comments into the file showing the checkin > date/time & user. This is great for auditing purposes but we are back to > the problem, how does the GUI handle comments. Again, the answer is not > very well. I'm not aware of any SCCS which adds stuff into the files under control, unless you tell it to. And if your file format supports comments then this again seems trivial. > > Command line option applicability > > With some applications that have a plethora of command line options the > is often some which will not work together or worse still, are ignored > completely if they are placed after another option of the command line. > > How is the GUI Developer going to easily, reliably code up the rules for > the GUI so that the application has a better then 50/50 chance of doing > what the user wants when if gets kicked off? Config files are typically used when command-line configuration becomes too complex. > Estimating the number of test cases to ensure that the test coverage > could be a daunting operation and without a decent tool to actually do > the manual application of GUI operation it could be almost impossible. Testing definitely seems the hardest thing to me. As always. > One company I work with has done this for one of their applications > already so it is not just some crystal ball gazing. The costs of > maintaining the GUP have since dropped by more than 50% and from that > experience, they are considering doing it for more applications. Note, > this is not anything you will find buried in dome Debian repository > somewhere and will cost you more money than most LUG users will earn in > a year. Nice implicit suggestion that expensive closed source software is inherently better than FLOSS! Solaris used to cost a lot of money and Windows still does, but I think Linux is better than both of them. There countless examples of FLOSS that is the best in its class. I don't see the point of your "you won't find this in Debian" comment. > Clearly this is not ideal practice and it is going to take a sea change > in attitude by developers to achieve this even on a small percentage of > key application in Linux but if the goal of doing away with the command > line is to be achieved then I think that this change is essential and > long overdue. I don't really see that the standards of configurability for popular Linux GUI apps is any better or worse than those for Windows. I think this could be improved, but "doing away with the command-line" is not a goal I support and I think is orthogonal to making better GUI apps. GUI apps could be better. On Linux and Windows. > The ideal state would be that the GUI did the followin
[Hampshire] What do you think?
Fellow Lug members, I would welcome comments on the following. The Linux Application Developers Quandary or is it really a Nightmare Linux distributions such as Ubuntu are making great strides in removing the need to do even quite advanced configuration operations via the command line and utilities like ‘vi’ (and even ‘emacs’ for those so inclined). Some would like to banish the bash command terminal to the same prominence the DOS Command window has on Windows Systems. i.e. buried away in All Programs-Accessories along with Windows Explorer, Notepad and Calculator to name but a few. That is all fine and dandy for the majority of key/core applications that are already included in a distributions repository. In the case of someone starting out to develop a new application that needs both a daemon that uses one or more configuration files and an application controller(to edit the configuration files) do they:- 1) Develop a command line only controller for V1.00 2) Develop a GUI only controller for V1.00 3) Both of the above 4) Non of the above and rely on users being able to use vi/emacs etc With application complexity increasing and the number of configurable parameters or even command line switches and options the task facing anyone who wants to develop a viable front-end for the application is considerable and forever increasing. Consider the following two cases. Properties files, manual edits and CVS Properties files (or as the used to be called ‘ini files’) are in my opinion are real PITA. That said, they are a million times better than the Windows Registry. As everything in Linux/Unix is a file and the majority of these files are plain text there is a great temptation to edit them manually especially if you are remotely logged into the system over a slow connection and using the GUI is not practicable. Once you have done that there is a danger that the changes you make will not be picked up by the GUI application. This particularly applies to comments. Nice and helpful as they are, how many GUI’s distributed in a standard Linux Distro today can handle comments. It is good practice to comment any changes so that the next person who comes along to fix the problem you edit has just caused can know who did what, when & why to the file. Yep, the version history strikes back. How many GUI’s give you the opportunity to add a new bit oh version history to the file? Not many I’d be willing to guess. Then comes CVS (or something similar). We all know that it is good practice to use CVS/SVN/git or some commercial package to store those ultra critical files in so that when your system goes down in a heap of flames (it does happen) you can pull everything out of your Source Control System and deploy it on the new system knowing that it is the latest version. Some of these systems add comments into the file showing the checkin date/time & user. This is great for auditing purposes but we are back to the problem, how does the GUI handle comments. Again, the answer is not very well. Command line option applicability With some applications that have a plethora of command line options the is often some which will not work together or worse still, are ignored completely if they are placed after another option of the command line. How is the GUI Developer going to easily, reliably code up the rules for the GUI so that the application has a better then 50/50 chance of doing what the user wants when if gets kicked off? Estimating the number of test cases to ensure that the test coverage could be a daunting operation and without a decent tool to actually do the manual application of GUI operation it could be almost impossible. Note, I have not even considered the coding of the GUI at this stage. Just writing down the rules will probably show up actual inconsistencies in the documentation (assuming there is something more than a ‘man’ page) and how the application actually works. Adding an AI rules engine may be the only way to go for some complex applications. One company I work with has done this for one of their applications already so it is not just some crystal ball gazing. The costs of maintaining the GUP have since dropped by more than 50% and from that experience, they are considering doing it for more applications. Note, this is not anything you will find buried in dome Debian repository somewhere and will cost you more money than most LUG users will earn in a year. If we take the two cases outlined above it is not hard to see that many projects have made the decision (either consciously or not) to take the easy way out and not handle comments etc or dynamically edit the options presented on the GUI if they would make the execution of the command fail. Clearly this is not ideal practice and it is going to take a sea change in attitude by developers to achieve this even on a small percentage of key application in Linux but if the goal of doing away wi
Re: [Hampshire] disabling flash adverts
--- On Sun, 19/7/09, Alan Pope wrote: > 2009/7/19 Isaac Close : > > Quick question that I hope won't start a flame war as > one can never be too careful on this list. > > > > What is perhaps the quickest and simplest way to > stop/block flash adverts without disabling flash all > together ? > > > > Flashblock firefox extension. It will cause all flash items > to appear > as a box with a 'f' Flash logo in it. If you want the flash > to > load/play you click it, or right click and always allow for > that site. > Within 1 minute of reading your answer I have installed Flashblock, it was very simple to do. Has it proved reliable for people so far, I wonder ? many thanks, Isaac. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] [OT] MTBF
2009/7/18 Andy Smith : > Hi James, > > On Sat, Jul 18, 2009 at 10:44:49PM +0100, James Courtier-Dutton wrote: >> Take an example of a SSD >> Manufacturer quotes: >> OCZ-120GB-Solid-State-Drive: MTBF 1.5 million hours. >> To me that means and MTBF of 171 years abouts. >> So, why do OCZ only guarantee it for 2 years? > > MTBF figures for hard drives (and possibly other things) are quoted > in terms of analysis of large numbers of that model. The item is > rated for 2 years of use. > > What they are saying is that if you got many of these items and ran > them simultaneously for 2 years then you should get 171 years > aggregate service out of them before any of them developed a fault. > > Or if you ran one item for 2 years then replaced it and kept going, > it should be 171 years before you had a failure inside the 2 years > of any individual item. > > Cheers, > Andy > To get a MTBF figure: Approx MTBF = ( Number of Devices tested * Test time ) / Number of failures. So, you are right, there is no indication as to what might happen after 2 years. The model for failures is a U curve anyway. In that some failures happen early on due to burn in etc., then it is fairly quite for a bit, and then the failures start happening again at an exponential rate. This link helped me http://www.vicr.com/documents/quality/Rel_MTBF.pdf -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
[Hampshire] Linux and hotmail deltasync
Hi, Is there any way to access hotmail using the MS deltasync protocol in Linux? Kind Regards James -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] disabling flash adverts
On Sun, Jul 19, 2009 at 09:59:58AM +, Isaac Close wrote: > What is perhaps the quickest and simplest way to stop/block flash > adverts without disabling flash all together ? AdBlock can be used to block individual adverts and ad sources. There are various Flash blockers available, too -- most of those will block all Flash content but allow you to click on the blocked box and see the Flash if you want to. The latter is probably quicker and simpler to implement and use. Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Prof Brain had been in search of The Truth for 25 years, with --- the intention of putting it under house arrest. signature.asc Description: Digital signature -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
Re: [Hampshire] disabling flash adverts
2009/7/19 Isaac Close : > Quick question that I hope won't start a flame war as one can never be too > careful on this list. > > What is perhaps the quickest and simplest way to stop/block flash adverts > without disabling flash all together ? > Flashblock firefox extension. It will cause all flash items to appear as a box with a 'f' Flash logo in it. If you want the flash to load/play you click it, or right click and always allow for that site. Cheers, Al. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
[Hampshire] disabling flash adverts
hi there, Quick question that I hope won't start a flame war as one can never be too careful on this list. What is perhaps the quickest and simplest way to stop/block flash adverts without disabling flash all together ? The question is asked with firefox in mind, largely on a windows platform. tia Isaac. -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
[Hampshire] Interesting Hardware Reference Poster
Subject says it all really: http://tinyurl.com/lf3dqb I thought it might come in handy for other folks like me who sometimes find themselves playing with older kit. * *Sean* * -- www.funkygibbins.me.uk -- Please post to: Hampshire@mailman.lug.org.uk Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire LUG URL: http://www.hantslug.org.uk --
