That's one of the most silly principles I've ever heard.
No, it has appeared because overzealous attempts to fix each and every thing may actually cause things to get worse.
It just means "sit on your ass and don't do anything, so you won't be blamed when the shit hits the fan".
Not exactly, but sometimes it is really better to know where to stop or things will getting worse than before. Only sometimes
Following it we could just as well stop all development activities right now.
Nope, you have things which are, uhm, broken and should be fixed (at least it looks for me in this way). Sorry for telling some truth
Why don't you turn off your update manager you have not only on Windows, but also on Linux? Is your Linux broken? Can you decide what is broken and what isn't?
Uhm, you're being overzealous even here. It's really awful
If you look at the SVN changelog of wx there are hundreds of fixes from 2.8.7 to 2.8.10
Yes, I know this. And that's actually why I can't sometimes understand Debian people. Debian maintainers are rather willing to fix ancient stuff (in terms of security holes) rather than simple provide new version if it does not causes problems. That's sometimes weird (and that's why I prefer Ubuntu which is guaranteed to uplift versions at least each 6 months). But you can see developer's side. But ignoring administrator's and user's sides. They HATE to install and update software - it just should work. So in reality there should be some kind of balance. In Linux everyone is free to choose distro which fits his feeling of this balance. Someone uses Fedora and turns into a kind of beta-tester with all libs and apps of latest possible versions (these ARE often plagued with bugs). Some other people prefer old stuff which worked for them for years. As for me, it looks like with WxWidgets major problem is their overall low quality, not the fact that someone is slow to update them. If they fixed hundreds of bugs, they released it before with all these bugs. And why there is expectations that in new version they will not introduce yet another hundreds of new bugs while fixing old ones and adding features, etc? Usually there is new bugs introduced while old bugs fixed and as I can understand, maintainers who trying to represent something complete and working are trying to save users asses from chances that someone will release new version which is even worse than old one (and it happens on regular basis, btw). At least I can understand this up to some degree. Unless it getting overzealous a way too much.
Who can say how many might be critical, and simply ignoring these means ignoring all the work the wx team put into their project.
No, actually this is just about managing software quality. Developers are always trying to do the best. However, not each and every newer version is exactly best from user's\admin's standpoint.
Once, "legendary" RedHat guy Ulrich Drepper has introduced a patch to gnu c library which changed names resolution stuff in library. He probably had some good intentions (though he refused to comment his actions and rather sticked to stupid "all phuck-0ff" position) but patch looked questionable when compared to RFCs and what worse, this has been released as new library version by RedHat. This caused damage to a number of (previously-working) real world LDAP servers installations (and LDAP could be business-critical stuff, you know, AD is basically LDAP, he-he). So, lots of users were unhappy and there was an impressive battle in their bug tracker
. Maintainers can act as safeguards in such scenario who will defer problematic version and prevent such unexpected kind of damages to running systems. It could be a good tactics if performed properly. However overzealous people can cause troubles here as well
. Debian is a good example of such overzealous guys who dislike to update SW versions at all.
And with a P2P app like aMule you can't even say "as long as everything appears to be working, fine". Your outdated app might still be screwing up the network for others or have security holes opening the global Kad network you're participating in for attacks that hit others too.
I'm really want to put your words into ears of some overzealous maintainers.
Anyway, if someone files a bug report asking people for help who he hasn't paid and who do this in their free time, the very least that can be expected is that he tries first if the problem still occurs with the latest version. That's the latest version of everything - not only the app, but also the libraries the app is using.
This could be technically challenging to users. Building your own private copy of lib is annoying and I'm personally will never use private copy of lib in real world scenario except for short-time testing (I'm really believe shared libs are about SHARING code, so it have to be SYSTEM-WIDE library, and update manager have to care about updating it). I will also avoid statically linked stuff since I do not want to get hacked even if I will forget about this app and it will turn out year later than one of statically-linked libs was flawed so I was hit by exploit. Let's Windows people to "enjoy" by trojans, viruses and other malware. I'm really do not want to have same fate.
Hint: even if something works with library version Y but user uses system which by default supplied with version X, result of effort building with custom version Y of library will be pretty useless to user and it will be quite problematic to distribute such version to others in a proper manner so you do not have to expect *nix users to be very cooperative here. This causes lots of extra actions without any proper reward (you can't even give results to other users in a proper manner!) so user's motivation goes to hell here. Even if things working fine with library ver. Y, other users of my distro will not benefit from this. So why I have to spend my time on pretty useless actions?
Which leads us back to the packaging problem. I've seen packagers screwing up really bad (try to install aMule in Ubuntu Jaunty's app manager to see what I mean).
Yes, even best technologies can cause some new, strange or weird problems. Once there is new technologies, there is new troubles associated with it. Let's say, 1000 years ago there was no chances of train crash or air-plane crash. Should we call air-planes and trains bad invention and stop using it in favour of "safer" horses? Same for packages managing. It solves some issues but creates some new problems as well.
One lazy "don't fix it if it ain't broken" packager can easily cut off half a community from important updates.
No, then community will annoy him a way too much and if update is a really important (read "security update"), maintainers who refusing to fix security holes quickly are about to gain bad reputation and lose userbase (btw, even Ubuntu people usually quickly reacts to security stuff, as well as maintainers of other systems as well). In some cases there could be need to "ping" maintainer manually though, etc
. And some maintainers (most notably, Debian) are overzealous in terms of time they're willing to "test" lib before giving it to wide public.
What use is it that we provide a version check signaling the user if his app is outdated when it takes six months to get the package updated in the distribution ?
It's not your fault. If there is security issues, you can expect somehow quick reaction(at least to fix issue). Otherwise .. users and admins are not too happy about frequent updates(they're about using stuff, not about running for bleeding edge!). I'm still encounter eMule 0.47c sometimes and updating say, 80% users to current eMule takes some MONTHS sometimes. Now I can see only 45% of eMule users updated to 0.49c. So users are pretty same everywhere - they're about USING stuff and not about constant updates
Packaging system btw helps here by setting up lower watermark. It is quite tricky to use too ancient software when package manager handles software packages and going to update it, at least sometimes. In Windows if user is careless about updates (and most users are), they will use very old stuff (like eMule 0.47c, etc) for ages. Ignoring security issues at all. Then they getting a number of viruses and backdoors and are spamming the world, DDoSing, etc. Packaging management at least attempts to keep both system AND software anyhow patched against threats. And it is much better than nothing (as it happens with Windows).
On Windows the version check works flawlessly,
Huh? I can see eMule 0.49c only gained 45% "market share" according to my "hot" statistics from ~1000 peers. This is less than half eMule peers! And eMule 0.49c was released in February
. Flawless? Nice joke...
. Surely you have no troubles to update 1 or 2 mules. But when it comes to millions, this is a real challenge. In overall score packaging systems usually perform better. Because most users are going to update system. If this will also update software, fine. In Windows users are often do not bother themselves with updating 3rd party software. So you can still find Windows people with ancient and unsupported WinAmp 2.95 (which haves known exploitable flaws), with old apps using flawed zlib and libpng, etc and pwn them with exploits easily. That's why there is so many spam in the world... And software managed by package managers most of time is anyhow non-exploitable and careless user is no longer represents a real problem.
NB: there was not enough windows aMules to collect reasonable statistics on how they're updated, I'm sorry.
people update the app and are up to date again right away.
The only problem is that they're NOT. Right now I can see only 45% of eMule users bothered to update to 0.49c since February. And there is still 17% users using eMule 0.48a which is TWO YEARS OLD. Some retarded users are even still using few 0.45b mules. Yikes!
(I'm do not have enough aMule on Windows in queue to collect same statistic for aMule, sorry).
Package managers will at least prevent use of flawed exploitable versions in most cases. Probably one of reasons why malware not widespread on *nix/Linux systems - at least package managers are trying to keep system AND apps AND all libs up to date or at least, without major known security holes.
Fully, including all libs used.
But the problem is that users are pretty ignorant - see above! Tell me, which libs uses eMule 0.48b? Or, better, 0.45b? And they have both app and all libs which are many years old. So they're probably quite easy targets for hackers... In system with packages managers user usally haves apps and libs if not with latest versions then at least patched against exploitable holes most of time. In Windows even this not achieved. There is still 17% users using 2-year-old libs. And some retards still using 0.45b which is nearly 4.5 years old. JFYI, this version still contains zlib security flaw I used as example in previous message... while virtually all *nix/Linux distros updated their zlib quickly enough.
So, don't be surprised if some of these retards still being exploited by bad guys to send spam, perform DDoS attacks, etc.
Any app can easily provide such a mechanism now that we have the Internet, and any good app should do that.
But it an order of magnitude easier to deal with ONE, centralized updater which updates everything. It is easy to configure and use ONE updater. It is a real PITA to use 20 different updaters and remember about them all. And in recent Windows, executable overwrite policies were tightened up, breaking most of these self-made updaters (so Vista with UAC enabled causes a decent amount of headache and compatibility problems).And not all app devs care about libs-related security enough. Many app creators are pretty ignorant about lib versions and do not care about security. Maintainers usually doing this job much better. In terms of preventing security issues in software.
If you sift through the crash report boards you find that for some guys aMule simply doesn't work. While true crash bugs in the app result in lots of reports as soon as they are introduced (and are pretty rare) there is always this background noise of unexplainable faults where I suspect weird combinations of the underlying libs as the reason.
You're probably right here and each benefit comes with associated drawbacks. Planes could crash. Package managers can add some headache. But in overall score, I used Windows for years. Than I also tried Ubuntu and Debian. I'm personally will NEVER resort to Windows way of "managing" software again. Ever! Just as I will never return to riding horse instead of using air plane.
Does "OpenSSH" ring a bell for you?
Hmm, can you be more specific about OpenSSH? What's the problem with it? And well, I can remember OpenSSL was updated once to fix security flaws. And I can remember I found few Windows apps with non-fixed DLL versions. I had to resort to manual replacing of DLLs since apps authors did not bothered themselves at all. Fortunately they were not statically linked at least so I can replace libs. But usual John the User will be vulnerable in such scenario.
Or the permanent "try building CryptoPP for yourself" issued on the crash boards?
Yes, I can understand some frustration. That's life. Planes could crash. And planes need expensive fuel instead of grass. And there is so many staff involved on airports, on plane itself and so on. It could be annoying to wait in airport and they even can sometimes lose your baggage. But riding a horse still not an answer.
Hard disc usage is no argument nowadays, even memory usage is not that important.
Then let's each app to supply it's own Windows copy. So ALL needed libraries are really PRIVATE
.And are you really ready to maintain own windows update servers?
.And I can still have moderately-sized system partition or even SSD (which are expensive btw so they're usually quite small to reduce price).
You never run 20 wx apps at the same time.
But at least I can run few of them and it even can be netbook or something like this. With cat-ass sized SSD and limited RAM. Furthermore, I may want to run such things like aMule, say, on my small router to avoid huge power-hungry and noisy PC running 24/7. Which is both RAM and "disc" constrained device. So as for me, bloat is bad idea, regardless of what you say. I'm really hate bloat. I can run torrent client on router and it can perform well enough. But I still can't achieve this with aMule...
That's why I'm opting for static builds.
Now imagine user will forget about your app. User may have hundreds or thousands apps installed, your app is one of many so user generally can't keep proper tracking of it's fate anyhow and can even ignore built-in updater. Then, time passes, guy who built static build abandons this (quite common if guy does not holds maintainer role officially). Years later user will remember about app and launch this app and .. what? Ancient linked-in libs will be used instead of updated system libs. User will be still vulnerable if any flaws were found during this time in statically linked libs. Quite common for Windows users. Quite uncommon for *nix\Linux ones.
Btw, I seen one funny bug report to MS. They confirmed bug. But they refused to fix it. Why? Because there was no way to give updated component to users anyway. So bug still here. That's price of living without a decent packages manager.
At least the users with the unexplainable crashes should try a fully static build with all the libs included for a change to see if that's where the problem is coming from.
Advanced users who are aware of caveats of static linking and can manage software on their own maybe should really try this. Though from my standpoint this looks as hard and non-rewarding task with pretty useless output (i.e. I can't really redistribute such aMule "Frankenstein edition" to other users) so I will try to avoid this as much as possible, sorry
As for me, instead of sticking to a non-constructive "we're supporting only latest version of libs, go to hell everyone else!" position (which will never work anyway
) there could be some really working compromise between users and devs.
It can look like this: declare "versions of X and up of libfoo and Y and up of libbar are supported, everyone else is out of luck, go bother maintainers to update them!". By selecting "X" and "Y" you can balance between ancient and defective libs but everyone supported and happy and current "we're supporting only latest version" state of things which will never really work for *nix\Linux anyway.
Maintainers probably will never distribute statically linked blobs or allow them in main system repos for mentioned (security!) reasons and I will basically thank them for doing so so they can take control on updating all libs used by each and every app. And you have to live with fact that not everyone in real world is going to use aMule with absolutely latest lib versions. If you care someone to actually use aMule. Making aMule running perfectly under Windows makes little sense - there is eMule already (with it's own advantages and disadvantages). And if aMule does not works properly under most of current Linux (*nix, BSD, ...) real-world distros with their not-so-perfect libs - what is the real use of aMule, then? I hope you're really will reconsider your position a bit. It will not work in way you want for *nix/Linux/*BSD anyway.
P.S. now I'm really should take a rest. And sorry everyone for long (and boring?) post explaining things which can be already evident for someone.