Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
cyphax
wrote on the 12 Jan 09 at 10:26
|
|
|
"To those smug people just dying to type 'you should have checked yourself before upgrading' really don't bother - my idea is to AUTOMATE SOMETHING THE COMPUTER CAN AND SHOULD DO FOR ME, not become a full time OS geek."
You're right, something similar happened to me before when my videocard was suddenly no longer supported by the new version of the Nvidia driver (the proprietary one). The result was that X simply would not start anymore.
There should be a fallback or so.
|
|
ampers
wrote on the 12 Jan 09 at 12:53
|
|
|
I am amazed there are no comments from geeks saying exactly that! (You should check) Why should we not automate such things.
Ampers
"Beware Geeks bearing gifs".
|
|
Whise_PT
wrote on the 12 Jan 09 at 17:50
|
|
|
|
im voting bad because the blacklist isnt allways reliable .. my video card was blacklisted on compiz because it works but its not 100% , after i removed it from the blacklist i never had any problems ,so that list kinda sucks
|
|
sandrex
wrote on the 13 Jan 09 at 03:53
|
|
|
I gave my +1 in this way.
"The point of a an upgrade advisor isn't to tell you exactly what wont work.. Its just to give you an idea of problems you may have.
Who cares if its not 100%, but its better that at least people have an idea they might have problems (and what those probs may be)".
|
|
vs8
wrote on the 13 Jan 09 at 04:46
|
|
|
|
Excellent Idea. +1
|
|
|
+1
I've been bitten by this before as well.
I'm not sure how to better handle the interaction between blacklists and applications or activities that should be able to check if something is blacklisted, but it is an area that could use some thought.
|
ziroday
(Brainstorm moderator)
wrote on the 14 Jan 09 at 11:48
|
|
|
|
There are release notes filed for every release that you should really be reading before hand to find out if any regressions will occur.
|
|
cyphax
wrote on the 14 Jan 09 at 11:59
|
|
|
"There are release notes filed for every release that you should really be reading before hand to find out if any regressions will occur."
Oh, okay, I'll tell my mother that. :P
Seriously, that is absolutely not a solution. Half the normal population can't read those notes because of the techno babble in them. Not only that, half the people that aren't geeks will have no clue _whatsoever_ exactly what hardware they have.
|
|
asdir
wrote on the 15 Jan 09 at 12:26
|
|
|
|
If idea #3 is implemented, it should state though, that there might be changes in the future. Otherwise first-time-installers might not come back to Ubuntu even after the problem is fixed.
|
|
arckeda
wrote on the 17 Jan 09 at 20:07
|
|
|
|
Solution 3, Canonical should be pushing for hardware / computer companies to do this.
|
|
ziroday
(Brainstorm moderator)
wrote on the 19 Jan 09 at 08:23
|
|
|
|
The release notes do exist for the this reason. They are fairly easy to comprehend as long as the user knows what hardware they have (and I am all for promoting hardinfo be installed by default). Having a piece of software that contains _every_ single hardware device in it and there possible incompatibilities is hard to implement and hard to maintain. If the user is not sure about anything there are multiple support resources for them to use including the formus, IRC etc.
|
|
r0g
wrote on the 19 Jan 09 at 23:43
|
|
|
@ziroday
This is exactly what I'm talking about - "those smug people" saying RTFM to everything...
"Having a piece of software that contains _every_ single hardware device in it and there possible incompatibilities is hard to implement and hard to maintain"
Well there's the can-do spirit that managed to create an OS kernel, filesytem, networking stack and windowing system all from scratch eh! It's hard to do so let's not do it.
1) Linux itself maintains this list and the matching drivers so even if it were 'hard to implement and hard to maintain' such a list is still clearly quite plausible.
2) I'm not suggesting we maintain a list of all the hardware in the world anyway, just that we look at common apps hardware blacklists and compare them to users hardware before starting the upgrade process.
3) It _may_ be in the release notes but why the fuck do I even have a computer for if it can't spare me hassle of searching through text files! We're not talking about implementing fourier transforms here, I'd be surprised if such a check couldn't be implemented with a perl one liner _if_ canonical took the trouble to collate and publish the list in question.
4) Yes there are forums, I spent several hours of my life in them in order to figure out why I couldn't get compiz to work when this happened, not to mention the half a day it took me to backup, wipe and re-install 8.04 when it turned out there's no solution other than becoming a driver developer and fixing the buggy drivers myself.
5) At the end of the day if you can publish this info in a 'release notes' file you can stick it in a simple text file and grep it against the output of lspci. People have computers to eliminate tedious repetitive work, why are you saying something that is fairly trivially automated should not be? Are you a quaker or something?
Gah!
|
|
cyphax
wrote on the 20 Jan 09 at 14:52
|
|
|
"The release notes do exist for the this reason. They are fairly easy to comprehend as long as the user knows what hardware they have (and I am all for promoting hardinfo be installed by default)."
Still, release notes are not a useful tool to help out people who know nothing about computers but send e-mails, chat on MSN and browse the web. There are far too many software updates to even expect anyone to read everything. Heck, I don't even read all the release notes myself. Why would this responsibility be with the user when they're advised by their operating to update their software?
|
|
yookoala
wrote on the 21 Jan 09 at 05:05
|
|
|
|
I want to know if my video card (intel) hangs compiz and the whole os BEFORE it happen.
|
|
dalhamir
(Idea reviewer)
wrote on the 25 Jan 09 at 09:31
|
|
|
|
I think solution #4 is basically just a better fleshed out version of #3. #3 warns you that something won't work. #4 tells you exactly what won't work and why. Neither are bad ideas, but #4 is better.
|
|
gmatht
wrote on the 27 Jan 09 at 03:17
|
|
|
|
Btrfs copy-on-write may help with #5.
|
|
|
I believe the undo function is so stupidly simple, it's brilliant.
|
|
|
|
There should be an undo function, because an upgrade advisor can't catch everything. However, not installing the update in the first place makes a lot more sense than undoing an update.
|
|
doctormo
wrote on the 10 Feb 09 at 00:08
|
|
|
You won't be able to fix this problem until hardware identification moves beyond driver classification and into user information. DeviceKit/HAL needs to be augmented with a full set of user displayable hardware information fields.
Smolt, no filtering, no analytics, it won't work until you have a solid hardware model that does more than sysfs and separates out the computer, the hardware components and the devices.
|
|
MKdx
wrote on the 19 Mar 09 at 15:13
|
|
|
I don't think that the "Upgrade advisor" should contain every single hardware. It could contain those *known* to be incompatible or problematic (green/yellow/red).
The needed info would be posted in release notes. However, it would be helpful to have small tool with the same info to aid the less tech-savvy or the less english capable population.
|
|
|
For me, the main advantage of #3 over #4 is the automatic aspect.
I really think that the check has to be done automatically. The only fact to click on "upgrade" or "install" has to launch the process.
In the case where no incompatibilities are found, the user has not even to know that the check was performed.
Now, if a potential problem is discovered, one can launch an Upgrade Advisor to help the user to choose if he wants or not to install.
My point of view is that the issue given here has to never more occurs :
https://bugs.launchpad.net/bugs/359392
500+ comments, among of them *a lot* of criticism against Ubuntu's policy to release a "stable" version with a _known_ *critical* bug that impacts a widespread graphic chipset.
My opinion is that Ubuntu did well to release Jaunty, but people with the Intel card GM965/GL960 had to be warned to not install (or upgrade to) Jaunty.
|
Post your comment
|
