Have you actually been able to save and locate receipts and warranty papers for some random device you bought 2 years ago? I can't find a receipt after 2 months. After 1 year the thermal receipts really begin to deteriorate
Simple solution: buy a cheap home file and use it, and photocopy or scan thermal receipts whilst they're still readable.
Same here, but my 69 year old dad and CentOS. Firefox, Thunderbird, OpenOffice.org, gramps, get_iplayer, gcdmaster, k3b, pidgin and he's happy. As other posters have mentioned, I get a little flurry of problems and queries when I'm forced to upgrade him to the latest version of the distro, but after a month or so, I go months without hearing of any difficulties.
As for hardware support, he knows to ask me for recommendations before he buys anything, so I can check it's compatible.
If there's a task he wants to do, he just describes it, I research it and give him a recipe for using it.
For support, I keep sshd listening so I can fix stuff remotely most of the time. This really impresses him, and he likes not having to bother with patches and anti-virus updates.
Admittedly, I've never tried it with Xming. But it's fine with a Linux/Xorg/openssh X server on a LAN. It's slow across ADSL/WAN, though.
I got sick of MythTV locking up, crashing, and the constant non-stop twiddling with my configuration because I could never get things quite right.
That doesn't chime with my experience of MythTV at all. It took about a day of solid fiddling to get core functionality working, and about a month of on-off work to get most of the other stuff working. It takes maybe half a day when I do a combined hard disc/distro/MythTV upgrade. The rest of the time, it JFWs. I run it on very modest hardware; a P4 2.53GHz (used to be a Celeron 1.7GHz), 768MB RAM and an nVidia 440MX video card. I use 3 physical DVB-T tuners which I multiplex to give 6 virtual tuners.
The only reliability issues I can report are a)
It may not have intelligent filtering, but MythTV's ability to easily schedule recordings using an EPG makes it trivial to speculatively record things that if one had to use discrete appliances one might not bother setting to record.
It's true that I'm watching more TV since I've had my MythTV box, but I'm pretty sure the quality of the TV I'm watching has improved. For a start, I've virtually eliminated my old habit of channel-surfing through hours and hours of the reality TV pap that's shown in peak hours and replaced it with watching movies, documentaries and quality comedy instead.
Um, what's wrong with:
desktop$ ssh -Y mythtv
mythtv$ mythtv-setup
Sure, you need the X libraries on the MythTV backend, but there's no need to run X on it!
I picked up WoG for US$2. I'd never played it before and had never been bothered enough to even download the demo. Effectively, I was happy to pay US$2 to take a chance on something which I might not like or play at all, or I might love and play relentlessly. I wouldn't have regretted that US$2 if I played it once and never bothered again.
I should add that I'm not a big gamer; I get all my games used for £1-4 for PSX, original XBox and PC and generally stick to recognised AAA titles. I pay similar prices for movie DVDs. Only CDs and DVD box sets get better prices out of me; anywhere from £8 to £16 usually.
Wouldn't be the first time Israel decided to go level somebody else's reactor
Or even the second.
Beyond these problems of attitude, there is also the very real and politically neutral problem of a MAD scenario involving Iran and Israel. Mutually Assured Destruction (barely) worked during the Cold War because both the US and the USSR were supremely stable and supremely powerful in their respective spheres of influence.
Also, with a few exceptions (Cuba/Turkey/Italy being the obvious examples), the large geographical distances involved meant that there was time for both sides to double-check and confer before launching a retaliatory strike in the event of a suspected launch by the other. In these regional scenarios (Israel v. most of its neighbours, India v. Pakistan, North Korea v. Japan/South Korea/China/whoever) there's very little time to cool things down; if one party detects a launch their choices are limited to a) do nothing and b) strike back (probably with everything they have) immediately.
Whilst MAD may have kept the West and the Eastern Bloc from fighting a nuclear war, I fear it definitely won't work the same way in these regional conflicts.
You can witness this in terms of people who continually cry about wanting more "quality" electronics, yest consistently purchasing the cheapest crap they can get their hands on. When you talk to them, they claim that quality and reliability are things they value highly. However their consumption habits show that isn't the case, what they value is low cost an features.
I think part of the problem is that 'low cost and features' are easy to verify; you go into the store, or look at some photos, or read some reviews, or at worst, RTFM, and you know what you're getting and for how much.
On the other hand, build quality, stability, reliability etc. can only be evaluated after purchase (at least these days, now that the formerly-reputable brands have debased themselves by badge engineering generic crap to hit a given price point, rather than confidently and assertively saying "we can't build a quality X for £Y, and we don't think anyone else can either"). And if you're not happy, good like finding a vendor who'll give you your money back.
So, given the hit-or-miss nature of assessing build quality, it's not surprising consumers select based on the attributes they can easily evaluate.
However, you are right in that the response is usually worthless.
I concur; no official posthumous pardon, or in the absence of that, funding to maintain the Bletchley Park museum.
USN-819-1 references CVE-2009-2692 not CVE-2008-4609 (i.e. the issue we're talking about here). The details don't match CVE-2008-4609 either. Searching Debian's security announcement list for CVE-2008-4609 finds nothing.
Debian (and by extension, Ubuntu) do a fine job of producing distributions and keeping them pretty secure. But you've not substantiated your claim that they've implemented their own kernel fix for CVE-2008-4609.
Where is it documented that Debian's kernels are fixed? Have you got a link?
Are you quite sure Debian supplied a kernel fix? Only searching debian.org for CVE-2008-4609 doesn't find anything relevant.
With your bare hands?!?
