[opensuse-project] opensuse upgrade: newer, faster, worse
Hello, The reason for this mail is quite simple -- I've been using open/suse for a long time and I am afraid to see how opensuse is getting better, yet on the other hand is getting worse. Better -- because for example computer boots faster, worse -- because to do the same thing as before, user has to download extra packages, download "outdated" packages or learn again how to make things work with new tools. For me meaning of upgrade is simply -- user should upgrade system and everything should work as before, minimum. The only changes could be: everything is faster, more secure, reliable, etc. Examples: opensuse dropped smbfs package some time ago, and this done silently, when you try to use smbfs... nothing, no information why, what should user do. losetup worked perfectly well in 10.2, after upgrade user is supposed to set from scratch her/his configuration to make things work. I don't want only to complain, because it is wasting time. My propositions: a) let's say user works with OS X.Y with package P installed older than the basic package from this OS version (example opensuse 10.2 and cups 1.1) -- do not touch such packages! it is clear that user intentionally downgraded this package to work with it, it was her/his will so do not force upgrade of such packages b) dropping software (like smbfs (*)) -- provide fake packages (I already reported this idea), so when user tries to use it explain what she/he should do with it b.1) however this example (*) shows a bad judgement -- I think it is better to provide unmaintained code to help users, than to remove such software and make things worse for users (cifs does not work so well) c) if one tool is replaced with another (losetup example) provide converter, so user could call losetup-backward-compability script and all arguments would be translated to the new tool used in opensuse d) if it is only possible (technically) maintain backward compatibility, ignoring current userbase in such manner reminds me of one big firm and its attitude -- it is bad example to follow In general: it is better to make things work in one place (opensuse distribution) so every user could benefit from it, than ignoring users workplace and making them fix system after upgrade to the state before upgrade. This just a wasting time. Backward compatibility really matters -- it is no use I get new, great cups if it does not work for me at all. The same goes for every other package. Currently this issue is being treated too lightly (in my opinion). Thank you for your time, have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Freitag 12 Oktober 2007 schrieb Maciej Pilichowski:
Backward compatibility really matters -- it is no use I get new, great cups if it does not work for me at all. The same goes for every other package. Currently this issue is being treated too lightly (in my opinion). Hi Maciej,
And you want to help? Because making things only develop in one direction without any regression is _work_ - a lot of work. And unless you want to pay 100€ for every openSUSE release, you better supply patches on a regular base to help. And I'm afraid I don't see them. Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
And you want to help? Because making things only develop in one direction without any regression is _work_ - a lot of work. And unless you want to pay 100€ for every openSUSE release, you better supply patches on a regular base to help. And I'm afraid I don't see them.
My post was technical (I gave some ideas how to solve problems), not a personal attack. Since I would like to keep it this way, just a short personal answer: a) pay or don't say anything -- it is just a excuse, so the user would think that for 100E she/he is not buying quality system but rather right to speak about it b) help b.1) * when user just uses linux it is bad, because she/he should send bug/wish/crash reports * when user already does that it is also bad, because she/he should send patches * and so on Sorry, I won't regret that I am not dying from overwork b.2) I already try to help seeking bugs or new ideas, I have only 24h per day so I am unable simply to type faster, sleep less, and simply not live my life (unfortunately I do the last part for a long time) b.3) last but not least, suggesting that I don't help (or my help does not count) is just rude (not to me, but to any person, it is not about computers Stephan) Back to technical issues -- I would be glad to hear if solving problems with backward compatibility has rather green light in opensuse or it is just a matter of "some users" (in other words: buy a new computer). I would be glad to discuss how to solve it, so new users would get the best system while users who just upgrade do this without struggling. have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Maciej Pilichowski escribió:
a) pay or don't say anything -- it is just a excuse
no, it is just a basic thing on software economics and if in case you had a tiny idea about the amount of work needed to do what you suggest you would agree. it is very simple, the effort must be worth, because such thing will require thousands and thousands of man-hours be done and hence increase the cost of the product, not to mention that with all posible combinations of software packages is almost **impossible** to ensure that it will work!!
I would be glad to hear if solving problems with backward compatibility has rather green light in opensuse
Sure, some problems can be solved in case by case basis. -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Maciej Pilichowski escribió:
Hello,
For me meaning of upgrade is simply --
yeah, it is very easy in words...
user should upgrade system and everything should work as before,
The holy grail eh ? that 's **a hell lot** of work.
Examples: opensuse dropped smbfs package some time ago, and this done silently, when you try to use smbfs...
because it was not needed anymore.. or do you expect we carry obsolete stuff forever ?
a) let's say user works with OS X.Y with package P installed older than the basic package from this OS version (example opensuse 10.2 and cups 1.1) -- do not touch such packages!
and you expect us to support that ? o_O how you ensure that will work at all?? got an idea ?
I think it is better to provide unmaintained code to help users, than to remove such software and make things worse for users (cifs does not work so well)
Providing unmantained code to users is a very risky, irresponsible thing and should be avoided by all means.
Backward compatibility really matters --
It matters as much as any other area, but frecuently conflicts with things as like ease of manteniance, security,correctness..etc.. -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
For me meaning of upgrade is simply -- yeah, it is very easy in words...
True :-).
user should upgrade system and everything should work as before, The holy grail eh ? that 's **a hell lot** of work.
Cristian, I am aware of this. I am just pointing out the aim. It is the aim, right?
Examples: opensuse dropped smbfs package some time ago, and this done silently, when you try to use smbfs... because it was not needed anymore..
What do you mean by "not needed"? There is no other way I can connect to samba servers. Luckily other people have exactly the same problem so after some googling I found out how to put smbfs back to my system. So there is need to connect to samba servers and smbfs is the key (I tried cifs).
or do you expect we carry obsolete stuff forever ?
This example is not about obsolete software per se, there is no other (newer) software I can use.
a) let's say user works with OS X.Y with package P installed older than the basic package from this OS version (example opensuse 10.2 and cups 1.1) -- do not touch such packages! and you expect us to support that ? o_O how you ensure that will work at all?? got an idea ?
Support -- of course not. I am asking for providing such feature as sensitive upgrade (i.e. do not upgrade downgraded packages). Ensure -- user risk. Note. User intentionally _downgraded_ package P before (several times). It is easy to detect such case and leave such packages intact. Of course some kind of dialog could be provided: " Installer found out that you downgraded packages. Do you want them to upgrade now? [ ] P1 [ ] P2 [ ] P3 ... " Once again -- if user uses OS 10.2 and at the same time package P is installed from OS 10.1 it had to be a good reason for it, and probably in such case user knows better (than current installer).
Providing unmantained code to users is a very risky, irresponsible thing and should be avoided by all means.
Different goals obviously. I see no purpose in having maintained, nice, etc. software which make make hardware stop working. I rather see providing unmaintained software as risky, but if it is necessary, valid mean to make hardware work.
Backward compatibility really matters -- It matters as much as any other area, but frecuently conflicts with things as like ease of manteniance, security,correctness..etc..
You are right. So maybe let's focus on one piece -- what do you think about this "smart upgrade" idea (not upgrading downgraded packages)? have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Maciej Pilichowski escribió:
Support -- of course not. I am asking for providing such feature as sensitive upgrade (i.e. do not upgrade downgraded packages). Ensure -- user risk.
THink on the following : a) will this feature be widely used so it is a nice thing for most users ? b) downgraded package depends on X , Y , Z library so those depend on A,B,C...Z so we have to keep them installed as well.. what about if the ABI of certain Key component changes ? how you ensure that will ever work ? what happends if f.e B comes from some third party repository or if C is no longer available and the functionality is now provided by "F" ? just use your imagination and create more combinations ok ? ;-) It is a no-win situation, it will break and leave a non working package in one way or another. -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, Cristian, thank you for your comments.
a) pay or don't say anything -- it is just a excuse no, it is just a basic thing on software economics
No, in this context it is an excuse. I already have installed OS 10.3 so if I buy it it will not differ -- for good or bad. To buy a software I have to be sure: a) company is entirely responsible for what it sells b) I can trust the development in longer perspective c) it is not some kind of "scheme"
and if in case you had a tiny idea about the amount of work needed to do what you suggest you would agree.
Is there a reason that you insult me? From opensuse perspective I am a just a random user, but you don't know me -- so why do you say things like that? I work as a developer, for several years in financial IT sector and one thing is solid there -- no matter how fancy new version is it is useless if it does not work with current infrastructure (software/hardware/system). Opensuse is not Suse enterprise, ok, but why not make it more reliable?
it is very simple, the effort must be worth, because such thing will require thousands and thousands of man-hours be done and hence increase the cost of the product, not to mention that with all posible combinations of software packages is almost **impossible** to ensure that it will work!!
Cristian, I agree with you. However there is a difference: a) idea is bad, because it requires a lot of effort b) idea is good, but it requires a lot of effort ad.a) end of discussion ad.b) then we can think how to make things simpler
Support -- of course not. I am asking for providing such feature as sensitive upgrade (i.e. do not upgrade downgraded packages). Ensure -- user risk.
THink on the following :
a) will this feature be widely used so it is a nice thing for most users ?
It depends how good OS next version will be. If it works there is no need to looking back. But if not... As an example -- Opensuse 10.3, let's say I downloaded it, installed (just from the disc) and: 1) I cannot connect to samba servers 2) I cannot print anything 3) I assume I cannot work since sax crashes while detecting my video card 4) I cannot access my encrypted data (1), (2), and (4) is strictly related to backward compatibility. And I think that every user would like to: a) connect to servers just like she/he used to b) print just like she/he used to c) access her/his data like she/he used to It is not "could the titlebar be more orange, I like this color", but rather more basic thing -- using your own computer. I can work because I downgraded packages all related to those issues.
b) downgraded package depends on X , Y , Z library so those depend on A,B,C...Z so we have to keep them installed as well.. what about if the ABI of certain Key component changes ? how you ensure that will ever work ? what happends if f.e B comes from some third party repository or if C is no longer available and the functionality is now provided by "F" ? just use your imagination and create more combinations ok ? ;-) It is a no-win situation, it will break and leave a non working package in one way or another.
There is a winning strategy here, just take a look. Opensuse 10.2 -- I cannot print (because of cups). So I downgraded it manually, breaking all dependencies. Result -- yast does not work with downgraded cups but I can print. Now, opensuse 10.3 upgrade -- what situation is here? There is a package which is known to be downgraded, dependencies are broken. a) should new version be installed b) should current version be kept ? ad.a) what for, really? this is done right now. Result, all dependencies are ok, but I cannot print ad.b) dependencies are broken exactly like they were broken before (so no extra harm is done). Result -- I still can print I am not saying the algorithm for improving upgrade is trivial, but is doable and user would benefit from it. And speaking of manhours, which you mentioned before -- you (suse) get massive amount of work for free -- from developers, artists, testers, etc. volunteers in short, so instead of summing up the costs on your side, it is better to look how people can contribute again (*). But first of all -- there must be a will to do the change. Thanks for your time, have a nice day bye (*) no, patches are not everything :-)) -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
There is a winning strategy here, just take a look. Opensuse 10.2 -- I cannot print (because of cups). So I downgraded it manually, breaking all dependencies. Result -- yast does not work with downgraded cups but I can print.
Now, opensuse 10.3 upgrade -- what situation is here? There is a package which is known to be downgraded, dependencies are broken. a) should new version be installed b) should current version be kept
?
ad.a) what for, really? this is done right now. Result, all dependencies are ok, but I cannot print ad.b) dependencies are broken exactly like they were broken before (so no extra harm is done). Result -- I still can print
I am not saying the algorithm for improving upgrade is trivial, but is doable and user would benefit from it.
New version should be installed because, when you saw the problem in 10.2, you reported the bug and the new package from 10.3 works again. Now suppose the old package has two different problems, A and B, that in 10.2 were "fixed" downgrading the package. Bug A was really fixed for 10.3 but bug B wasn't. When updating to 10.3 should the new package be installed? How do you know if the user downgraded the package because bug A or B? If it would be doable I would be with you, but I really think it isn't, it's too complex But even if with a LOT of work it would be doable, you can obtain the same result with a fixed package for 10.3. If we have two equivalent solutions we should select the easier one... and fix the package is by far the easier one. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
New version should be installed because, when you saw the problem in 10.2, you reported the bug and the new package from 10.3 works again.
Yes, I reported a bug. It won't be fixed. Period. It is not just single report that is closed as wontfix/worksforme for a reason of not enough hardware for developers. So in theory, you are right, everything reported is fixed, but in practice it is not like that.
Now suppose the old package has two different problems, A and B, that in 10.2 were "fixed" downgrading the package. Bug A was really fixed for 10.3 but bug B wasn't. When updating to 10.3 should the new package be installed? How do you know if the user downgraded the package because bug A or B?
Because user selected (or not) this downgraded package to upgrade. And it does have anything to do with fixed bugs in those packages. Installer could list found packages that were downgraded, to ensure user is willing to upgrade.
If it would be doable I would be with you, but I really think it isn't, it's too complex
It is quite simply (procedure), really. List of packages (when the version is released) is well known, the current (installed) version is also know. Since yast can compare versions... this is it. The only difference would be to include full set of such lists for already released versions of open/suse. Now, it is a bit of work, I admit, but after that it is one more version per release. have a nice day bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Maciej Pilichowski escribió:
Is there a reason that you insult me? From opensuse perspective I am a just a random user
Im not insulting you!! but it is very clear that you dont really know about what are you proposing, believe me , it is **way very hard**!!
Cristian, I agree with you. However there is a difference: a) idea is bad, because it requires a lot of effort b) idea is good, but it requires a lot of effort
ad.a) end of discussion ad.b) then we can think how to make things simpler
add c) the idea is good, but explained in a too simplistic way and it is too costly to implement in the short and long term, and does not seem to be worth to do.
It depends how good OS next version will be. If it works there is no need to looking back. But if not...
It is for niche use.
As an example -- Opensuse 10.3, let's say I downloaded it, installed (just from the disc) and: 1) I cannot connect to samba servers
Open a bug report
2) I cannot print anything
Open a bug report
3) I assume I cannot work since sax crashes while detecting my video card
open a bug report
4) I cannot access my encrypted data
same,
There is a winning strategy here,
I really doubt it. just take a look. Opensuse 10.2 -- I
cannot print (because of cups). So I downgraded it manually, breaking all dependencies. Result -- yast does not work with downgraded cups but I can print.
then you have proven my point, you end with a broken system in one way or another !! :-)
so instead of summing up the costs on your side, it is better to look how people can contribute again (*).
People can use their time in more important things, there are plenty,zillions of stuff to fix. Sorry, but I still dont see how you propose to fix the problem in a realisitic way, the variables are too much, the final result will be probably and non working system that costed a hell lot of work. -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
As an example -- Opensuse 10.3, let's say I downloaded it, installed (just from the disc) and: 1) I cannot connect to samba servers
Open a bug report
Done, waiting for response. But note that OS 10.2 and OS 10.3 were released with such set of software that user had to search for solutions for his/her own and download software that was removed on purpose from OS just to make things work.
2) I cannot print anything Open a bug report
Done, bug won't be fixed.
3) I assume I cannot work since sax crashes while detecting my video card open a bug report
Done (novell bugzilla), bug won't be fixed.
4) I cannot access my encrypted data same,
Done, the problem (because it is not bug per se) won't be fixed. I hope similar issues in future would be solved properly.
cannot print (because of cups). So I downgraded it manually, breaking all dependencies. Result -- yast does not work with downgraded cups but I can print.
then you have proven my point, you end with a broken system in one way or another !! :-)
What do you mean by "broken system"? Everything works here because I _manually_ 1) installed alternate packages with unmaintained smbfs 2) downgraded cups 3) copied old xorg.conf 4) downgraded util-linux I can hardly call working system a broken one. How do you call non-working, "non-broken" system then? Another-kind-of-working? :-) Ok, I see here this solution has no chance :-) How about another thing -- providing wrappers for programs that were replaced (*) by other programs. (*) so program A is removed and program B is put instead, of some small version of A is only preserved and B is put additionally Here example is losetup. In OS 10.2 it was included, full version, in 10.3 there is only some kind of partial losetup included. Wrapper would be handy to easily migrate to newer tool. have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
As an example -- Opensuse 10.3, let's say I downloaded it, installed (just from the disc) and: 1) I cannot connect to samba servers
Open a bug report
Done, waiting for response. But note that OS 10.2 and OS 10.3 were released with such set of software that user had to search for solutions for his/her own and download software that was removed on purpose from OS just to make things work.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=332693 ? That's no a report about cifs. And was reported after 10.3 release.
2) I cannot print anything Open a bug report
Done, bug won't be fixed.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=231119 ? You never provided the requested log files...
4) I cannot access my encrypted data same,
Done, the problem (because it is not bug per se) won't be fixed. I hope similar issues in future would be solved properly.
3) copied old xorg.conf The installer made a backup? So I think the behaviour is correct. Well, not creating an unusable xorg.conf would be better, but bugs exists... If more than a single user was affected by the same bug I suppose Novell would have purchased a Dell Latitude D610 or something to be able to reproduce it, but since just you complained... The solution "you have a backup in case something fails" looks like
"not bug per se"? It looks like a serious bug (to people that encrypts his data). If there is a real bug "won't be fixed" doesn't looks like a good solution. the correct one to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
1) I cannot connect to samba servers
Open a bug report
Done, waiting for response. But note that OS 10.2 and OS 10.3 were released with such set of software that user had to search for solutions for his/her own and download software that was removed on purpose from OS just to make things work.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=332693 ?
No, it is just a suggestion how make life easier for people who used smbfs. This one: https://bugzilla.samba.org/show_bug.cgi?id=5019
2) I cannot print anything
Open a bug report
Done, bug won't be fixed.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=231119 ? You never provided the requested log files...
1) oh boy, read carefully -- I provided logs but not to pollute novell bugzilla I just put a link to the other report with the logs 2) no, of course this not that report, because it is only about minor defect in yast, forgetting settings, this one: https://bugzilla.novell.com/show_bug.cgi?id=217215 which ended up at the cups bugzilla: http://www.cups.org/str.php?L2185
4) I cannot access my encrypted data same, Done, the problem (because it is not bug per se) won't be fixed. I hope similar issues in future would be solved properly. "not bug per se"? It looks like a serious bug (to people that encrypts his data). If there is a real bug "won't be fixed" doesn't looks like a good solution.
In OS 10.3 there is no full losetup, only limited edition, the reason is (not verbatim quote) I should use dm-crypt instead. I am not sure that it is 100% equivalent (see smbfs vs. cifs history) so for me it is safer to use losetup from 10.2 which works with all features I need (for example gpg support). Losetup from 10.3 cannot do this. So, if dm-crypt is able to mimic losetup, it is not a bug, just a not 100% good decision. If it is not -- it is a bug, but I cannot check this.
If more than a single user was affected by the same bug I suppose Novell would have purchased a Dell Latitude D610 or something to be able to reproduce it, but since just you complained...
I didn't complain. I just said that. Crashing sax is a fact, not personal opinion. have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
1) I cannot connect to samba servers
Open a bug report
Done, waiting for response. But note that OS 10.2 and OS 10.3 were released with such set of software that user had to search for solutions for his/her own and download software that was removed on purpose from OS just to make things work.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=332693 ?
No, it is just a suggestion how make life easier for people who used smbfs.
Well, Novell doesn't have to know about this one since isn't in his bugzilla. But looks like there are really a lot of complains about cifs. If the "is unsupported" problem is really such a big problem I think the smbfs KMP package from https://bugzilla.novell.com/show_bug.cgi?id=224790#c4 could be added to OBS... to "drivers:/filesystems/"? Would be easily available but not supported. Still I don't think "is unsupported" should be such a big problem when keeping a module while the new one matures, at least no in a case like this one where so much people complains. If no inside the kernel package, yes like a KMP in the OSS repository... perhaps making clear someway it is unsupported.
2) I cannot print anything
Open a bug report
Done, bug won't be fixed.
This one -> https://bugzilla.novell.com/show_bug.cgi?id=231119 ? You never provided the requested log files...
1) oh boy, read carefully -- I provided logs but not to pollute novell bugzilla I just put a link to the other report with the logs
2) no, of course this not that report, because it is only about minor defect in yast, forgetting settings, this one: https://bugzilla.novell.com/show_bug.cgi?id=217215 which ended up at the cups bugzilla: http://www.cups.org/str.php?L2185
Ok, this is a real problem, but it's a very particular case. I don't think there are so much (if any) problems like this one. That's a bug that should be fixed by USRobotics, but... I would understand if you didn't tried to ask them. Novell hasn't any procedure for cases like this one? If Novell asks USRobotics would help, or I'm expecting too much from USR? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello,
Well, Novell doesn't have to know about this one since isn't in his bugzilla.
Yes, and it is quite new :-) I posted it in samba bugzilla, since everytime where I am not sure where to post a report I am told to post it at original bug tracking system.
But looks like there are really a lot of complains about cifs.
You can tell by looking at google. Also there is a lengthy report at novell bugzilla about dropping smbfs (and comparing it to other distributions).
Still I don't think "is unsupported" should be such a big problem when keeping a module while the new one matures, at least no in a case like this one where so much people complains. If no inside the kernel package, yes like a KMP in the OSS repository... perhaps making clear someway it is unsupported.
Yes, that would be great.
Ok, this is a real problem, but it's a very particular case.
Of course I have only one router/printserver but I guess it is related to whole family of those models.
I don't think there are so much (if any) problems like this one. That's a bug that should be fixed by USRobotics,
Yes.
but... I would understand if you didn't tried to ask them.
The other reporter tried -- "we don't support linux". Companies really awkwardly react when I am asking for linux support (when I was about to buy Plustek scanner I got the answer, but when I asked about linux... silence :-)).
Novell hasn't any procedure for cases like this one? If Novell asks USRobotics would help, or I'm expecting too much from USR?
Probably you are :-) but it would be really nice to do so. Users who bought routers from USR would surely benefit from that. have a nice day bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sunday 14 October 2007 07:05:57 am Maciej Pilichowski wrote:
The other reporter tried -- "we don't support linux". Companies really awkwardly react when I am asking for linux support (when I was about to buy Plustek scanner I got the answer, but when I asked about linux... silence :-)).
It is not always up to the company support policy, but it is up to the support personnel skills. One reads template answer, that is basic troubleshooting I already did, the other is asking questions, listen for comments, and both are the same company. First puts in 8 hours and go home, second really wants to take care of your problem. It depends how company pay, how evaluate personnel efficiency and skills. They can do mistakes here that lead to poor support, making skilled people to leave, and customers have to live with template readers :-( -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Maciej Pilichowski escribió:
What do you mean by "broken system"?
if you change component X and then component Y gets broken, that is what call a broken system..
1) installed alternate packages with unmaintained smbfs
That is an unsupported operation.
2) downgraded cups
same.
4) downgraded util-linux
same, you cannot expect to get support for a system that uses random/untested software combinations.. -- "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury Cristian Rodríguez R, Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I'm not a Novell employee, but I have some technical background, so: On Fri, 2007-10-12 at 16:46 +0200, Maciej Pilichowski wrote:
Hello,
The reason for this mail is quite simple -- I've been using open/suse for a long time and I am afraid to see how opensuse is getting better, yet on the other hand is getting worse. Better -- because for example computer boots faster, worse -- because to do the same thing as before, user has to download extra packages, download "outdated" packages or learn again how to make things work with new tools.
For me meaning of upgrade is simply -- user should upgrade system and everything should work as before, minimum. The only changes could be: everything is faster, more secure, reliable, etc.
Good goal to have.
Examples: opensuse dropped smbfs package some time ago, and this done silently, when you try to use smbfs... nothing, no information why, what should user do. losetup worked perfectly well in 10.2, after upgrade user is supposed to set from scratch her/his configuration to make things work.
Why doesn't cifs work? Is there a bugzilla.novell.com bug about this? The openSUSE community (Novell, SUSE, and third party contributors who want to see openSUSE succeed) can't fix what we don't know about. Basically.. a buggy program isn't an excuse to keep an older unmaintained software around. The goal should be to make its replacement work. If there is a case it doesn't work, file a bug about it and someone will fix it.
I don't want only to complain, because it is wasting time. My propositions:
a) let's say user works with OS X.Y with package P installed older than the basic package from this OS version (example opensuse 10.2 and cups 1.1) -- do not touch such packages! it is clear that user intentionally downgraded this package to work with it, it was her/his will so do not force upgrade of such packages
openSUSE would have to ship a database of every openSUSE version / package version combination in order for this to work. Even then, not very safe for security reasons, et. al.
b) dropping software (like smbfs (*)) -- provide fake packages (I already reported this idea), so when user tries to use it explain what she/he should do with it b.1) however this example (*) shows a bad judgement -- I think it is better to provide unmaintained code to help users, than to remove such software and make things worse for users (cifs does not work so well)
And who do you blame when the unmaintained package has a security bug that allows someone to rootkit you, and it happens? Do you expect Novell to fix a security problem in an unmaintained piece of software that isn't even shipped in the supported versions?
c) if one tool is replaced with another (losetup example) provide converter, so user could call losetup-backward-compability script and all arguments would be translated to the new tool used in opensuse
This is a good idea potentially.
d) if it is only possible (technically) maintain backward compatibility, ignoring current userbase in such manner reminds me of one big firm and its attitude -- it is bad example to follow
Upgrading works for the most part. I have a server at work that has been upgraded from SL 10.1 to OS 10.2 and now to OS 10.3.. not a clean install, but being upgraded. Everything seamlessly worked. In your case, it didn't. But a bug report needs to be submitted so that someone can look at it and figure out why it doesn't work.
In general: it is better to make things work in one place (opensuse distribution) so every user could benefit from it, than ignoring users workplace and making them fix system after upgrade to the state before upgrade. This just a wasting time.
Upgrading should just work. If there is a case it doesn't, its a bug that needs to be fixed.
Backward compatibility really matters -- it is no use I get new, great cups if it does not work for me at all. The same goes for every other package. Currently this issue is being treated too lightly (in my opinion).
It matters to us all. But backwards compatibility for the sake of backwards compatibility is a bad thing. Look at Microsoft Windows and their bloat for example. openSUSE already ship some "compatibility packages" for older versions of select libraries that newer programs depend on.
Thank you for your time, have a nice day, bye
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hello, Justin, thanks for your reply.
Examples: opensuse dropped smbfs package some time ago, and this done silently, when you try to use smbfs... nothing, no information why, what should user do. losetup worked perfectly well in 10.2, after upgrade user is supposed to set from scratch her/his configuration to make things work. Why doesn't cifs work?
I have no clue, because whatever I do, it always shows the same error. Quite a lot people have the same problem.
Is there a bugzilla.novell.com bug about this?
Cifs or smbfs? Former -- I would rather look at cifs reporting system, the latter one, yes.
Basically.. a buggy program isn't an excuse to keep an older unmaintained software around. The goal should be to make its replacement work.
Of course -- but what to do between, here (*)? [ time ] old package removed --> system not working (*) --> newer version works
If there is a case it doesn't work, file a bug about it and someone will fix it.
I do this.
a) let's say user works with OS X.Y with package P installed older than the basic package from this OS version (example opensuse 10.2 and cups 1.1) -- do not touch such packages! it is clear that user intentionally downgraded this package to work with it, it was her/his will so do not force upgrade of such packages openSUSE would have to ship a database of every openSUSE version / package version combination in order for this to work.
No, no :-) Note, that the older package is already installed in the system (with broken dependencies already). Take a look at the cups example -- I have it installed already, I don't need it on the disc, I want the installer won't remove it.
Even then, not very safe for security reasons, et. al.
If it is installed, it is unsecure already.
b) dropping software (like smbfs (*)) -- provide fake packages (I already reported this idea), so when user tries to use it explain what she/he should do with it b.1) however this example (*) shows a bad judgement -- I think it is better to provide unmaintained code to help users, than to remove such software and make things worse for users (cifs does not work so well) And who do you blame when the unmaintained package has a security bug that allows someone to rootkit you, and it happens?
Me. I saw a warning "unmaintained software", right? I had a choice.
Do you expect Novell to fix a security problem in an unmaintained piece of software that isn't even shipped in the supported versions?
Not at all. Unmaintained software is unmaintained software, I understand it. But at least I can install it and do my work.
But a bug report needs to be submitted so that someone can look at it and figure out why it doesn't work.
Yes, I post bug/wish reports :-) But when the hardware matters usually it is a dead end (because developers do not have what I have, so reports are closed as worksforme or similar).
It matters to us all. But backwards compatibility for the sake of backwards compatibility is a bad thing.
Hmm, I don't agree with that (entirely). There should be continuous link between previous version and newer version. Nothing like "your system does not work, use google". I mentioned possible solutions, they are not perfect, but I think it is the place to discuss how to best solve the problem. Thank you for reading :-), have a nice day, bye -- Maciej Pilichowski --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (6)
-
Christian Morales Vega -
Cristian Rodriguez -
Justin Haygood -
Maciej Pilichowski -
Rajko M. -
Stephan Kulow