aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: I am really tired to read the whole thread...  (Read 5170 times)

User294

  • Newbie
  • *
  • Karma: 1
  • Offline Offline
  • Posts: 41
I am really tired to read the whole thread...
« on: May 30, 2009, 03:54:32 AM »

Because devs will infailingly answer "please try a current wxWidgets version" if anybody reports a crash with wx 2.8.7.  :P
Uhm, how about old admin's principle: "do not fix what is not broken" ?If there is known problems, fine, let's update it. Otherwise ... er ... running for cutting edge without reasons is, uhm, strange  ;D

Quote
Personally, I'd link the whole thing static. No dependencies, no hassle. Just one executable, and good.
Please, NEVER do this, at least for *nix/Linux - see below why. Package managers were invented for GOOD reasons!

1) Code sharing. I'm really prefer to have ONE, SYSTEM-WIDE WxWidgets. Rather than to have 20 programs using 20 private copies of WxWidgets. Shared libraries ARE ABOUT SHARING CODE AND RAM, after all  >:(. In Windows, let's say 20 apps using zlib. Then, each app have to keep it's own zlib.dll or link it statically (there is no good method to request it from system so apps have to redistribute it on their own). It is obvious that 20 dll files occupy 20 times more space than one. Same goes for RAM as well when programs are running. One shared lib shares code in RAM. But 20 different DLLs  are not doing so. Wasting 20 times more RAM and disk space for ... nothing actually sucks. Especially for heavy libs like WxWidgets.

2) Easy updates (easy for users, not maintainers or devs). Imagine same 20 apps, same zlib. Now there is security flaw found! As it was some time ago. In Windows it is up to you, user to re-download all 20 apps and hope their dev's updated zlib in these apps (and there is no guarantees they did it).  That's why you still can sometimes hack Windows users with ancient zlib exploit (outdated apps with old zlib are here and with static linking user lacks any chances to update flawed lib at all if devs failed to do so!). Updating 20 apps in Windows is a real PITA. In contrast, in Linux (or similar system with packages managers), maintainers have to build zlib once and put it to repositories with higher version number than older one. Then, package managers on user's side will figure out there is new zlib available and offer to update it. Once user confirms this, ONE SMALL PACKAGE WITH ZLIB have to be downloaded. Then, ALL APPS using zlib are automatically FIXED (since they're using this system-wide zlib) and no longer suffer from security issue (except these VERY BAD apps linked statically). So, for user this is as simple as few mouse clicks or couple commands. Compare to redownloading and reinstalling 20 apps manually and you will have some idea what is actually better... (actually MS created MSI but it's very sucking implementation of package manager, Linux and other have much better packages management systems which are years  ahead of MSI's design and features).

Some drawback is here - maintainers have to build all stuff so they have some work to do and they sometimes could be a bit slow or not willing to rebuild libs without good reasons (just to be on bleeding edge is usually not counted as good reason, especially by conservative Debian guys, etc).

I hope you got idea about packages management systems. Package managers are really doing great job, keeping stuff up to date and offloading users and admins from manual "3rd party" software updates. It is an order of magnitude harder to keep both Windows AND all installed apps and their libs up do date than same thing in Linux (and *BSD as well).

Packages managers are very good invention - they solve much more problems than creating. For example, it is much harder to hit people with exploits if they update ALL apps and libs, not just like in Windows where system cares only about its updates but ton of apps with flawed zlib, libpng, ... could still float around, being a good target for hackers.
« Last Edit: May 30, 2009, 04:04:49 AM by User294 »
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3830
  • Engines screaming
I am really tired to read the whole thread...
« Reply #1 on: May 30, 2009, 11:33:42 AM »

Uhm, how about old admin's principle: "do not fix what is not broken" ?
That's one of the most silly principles I've ever heard. It just means "sit on your ass and don't do anything, so you won't be blamed when the shit hits the fan". Following it we could just as well stop all development activities right now. 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?

If you look at the SVN changelog of wx there are hundreds of fixes from 2.8.7 to 2.8.10 . Who can say how many might be critical, and simply ignoring these means ignoring all the work the wx team put into their project.

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.

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.

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). One lazy "don't fix it if it ain't broken" packager can easily cut off half a community from important updates. 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 ? On Windows the version check works flawlessly, people update the app and are up to date again right away. Fully, including all libs used. Any app can easily provide such a mechanism now that we have the Internet, and any good app should do that.

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 "automatic system-wide security update" cuts both ways you see. Not only can all apps be provide with a new lib (with which they have never been tested, so nobody can say if they still work by the way...), but just as well can all apps be stuck with an old lib, or even a broken lib. Does "OpenSSH" ring a bell for you? Or the permanent "try building CryptoPP for yourself" issued on the crash boards?  Hard disc usage is no argument nowadays, even memory usage is not that important. You never run 20 wx apps at the same time.

That's why I'm opting for static builds. 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.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

User294

  • Newbie
  • *
  • Karma: 1
  • Offline Offline
  • Posts: 41
I am really tired to read the whole thread...
« Reply #2 on: May 31, 2009, 12:47:44 AM »

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.

Quote
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 though.

Quote
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  ;D

Quote
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  :o

Quote
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.

Quote
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.

 Good example:
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 :D. 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.

Quote
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.  

Quote
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?


Quote
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.

Quote
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  ;D. And some maintainers (most notably, Debian) are overzealous in terms of time they're willing to "test" lib before giving it to wide public.

Quote
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).

Quote
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...  ;D. 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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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  ;D.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).

Quote
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...  >:(

Quote
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.

Quote
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 ;D.

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  :P)  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.
« Last Edit: May 31, 2009, 12:59:08 AM by User294 »
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3830
  • Engines screaming
I am really tired to read the whole thread...
« Reply #3 on: May 31, 2009, 02:10:19 PM »

You really are a Man on a Mission it appears. I have read your whole post of course, but I won't reply to each statement for the whole bulk of it.

Quote
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.
The thing with free software is, you can pull quite something off with the limited resources available, but you can't do a full quality assurance spanning all the different platforms and usecases. That's what we need our users for. All the "cutting-edge-junkies" who always run the latest SVN snapshots and report problems they find with them. Guys, without your work we could never get the app stable.
Of course everybody is free to use only the stable versions. He just has to be aware that he doesn't contribute as much that way. And it is annoying if you release an app and then someone complains about a bug he could have detected earlier using a beta.

Quote
it looks like with WxWidgets major problem is their overall low quality
They are just a few guys who do a tremendous job with their all-in-one multi-platform toolbox. And without our help they are lost. That's why I'm currently working on getting aMule to run with wx 2.9 (or the other way round). It doesn't do to wait until everything is finished and then start bitching about bugs.

Quote
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...
People have a right to be idiots, and many use that right. (It's called "The Dilbert Principle" btw.) They get the info (unless they are dumb and turn the signaling off) and they can easily upgrade their app, without waiting for somebody third-party to wake up and update his package. That's good enough for me.
And I won't ever take "my distro hasn't this version yet" as an excuse, just as I won't take "I was too lazy to install the new version". If I can be bothered to look at a backtrace and search for a bug in the code, the user can be bothered to try a current version first.

Quote
It is a real PITA to use 20 different updaters and remember about them all.
Take TortoiseSVN. It opens a popup every now and then messaging that a new version is available. Then it takes a few clicks, and it's updated. Where's the PITA, and what should I have to remember?

Quote
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.
My bad, OpenSSL. You have a nice way to put the biggest fuck-up in Internet security. It was not caused by Microsoft, and it can't be fixed by updating a few packages. The broken certificates are out there and security for all platforms will be tainted for years. Just because some packager thought he was more clever than the devs of the software and he could safely hack away some ominous lines of code he didn't understand.

Quote
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.
Well, I won't post "That's life. Planes could crash." to somebody asking for help on the crash board. You are no dev, it's easy for you to say that and move on.

Quote
I can run torrent client on router and it can perform well enough. But I still can't achieve this with aMule...  Angry
Freddy77 got it running on his router with his memory mapping code actually. But that code is in no distro yet.  :P

Quote
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.
Yeah, sure. As if a current lib will still work with a years-old app. Not if the interface is more complex than two bricks of Lego you stick together. I can tell you that aMule 2.2 won't run with wx 2.9 by simply replacing the lib.

Quote
And you have to live with fact that not everyone in real world is going to use aMule with absolutely latest lib versions.
The problem is not exactly that it's not the latest versions, it's that something is wrong with them. And if you try to search for a bug you have to start with ruling out possibilities. You can't do that if you get crashes in some libraries you don't know what may have been hacked around in them to remove some Purify warnings.

Quote
Making aMule running perfectly under Windows makes little sense - there is eMule already
So what? Does making aMule running perfectly under Linux make sense with xMule available? (Yeah, I'm aware that comparing eMule with xMule is stupid.) There is no turf in open source. Anybody can make anything, no matter if there's anything else that may be better. If I can run it that's enough reason for me to do it. It's my time I'm spending after all.

Wow, never intended to be that verbose. Festor, if we are annoying you just move the whole thing to Off-Topic.  :)
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5898
Re: I am really tired to read the whole thread...
« Reply #4 on: June 01, 2009, 12:00:07 AM »

I'm in line with an iced coffee to watch a movie and it's my wife's birthday and the iPhone's keyboard is too slow and I'm too lazy and the movie will start really soon anyway but man am I gonna flame the shit out of everyone here when I have some time.
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 163
  • Offline Offline
  • Posts: 2688
Re: I am really tired to read the whole thread...
« Reply #5 on: June 01, 2009, 11:47:08 AM »

You won't. (have some time)
Logged
concordia cum veritate

Vollstrecker

  • Global Moderator
  • Hero Member
  • *****
  • Karma: 65
  • Offline Offline
  • Posts: 1466
  • Unofficial Debian Packager
    • http://vollstreckernet.de
Re: I am really tired to read the whole thread...
« Reply #6 on: June 02, 2009, 01:45:09 AM »

As I get the feeling, I started with a question this big thread, some words. I think this started in Festors Ubuntu thread, and the question was just because: I know the packages that wx-devs release. This is Debian or Ubuntu. Distros that should work, and man when a new wx-version reaches one of those that is from 2.8 branch, you'll get a hell of problems with deps, because the pkg's don't fit into the app. There's no problem in using newer versions, but they shouldn't break the system. You'll need to stay on these packages.
Such thing is no problem for gentoo. Gentoo is like an Harley Davidson, the people like to repair it, not to drive it. Debian/Ubuntu is for driving.
Logged
Homefucking is killing prostitution