| |||||||||||||
Red Hat: no desktop products comingRed Hat: no desktop products comingPosted Apr 20, 2008 20:55 UTC (Sun) by danhah (guest, #51567)In reply to: Red Hat: no desktop products coming by mmarq Parent article: Red Hat: no desktop products coming
No offense but we are in 2008 not 3008. It is difficult enough to track bugs at the moment (hence the fact that I have one in amorok well actually not amorok, one of the libs) but can you imagine if every person on the planet was to compile there own software. How many different optimisations would there be. Where would the bug be. It could be in any of a hundred different optimised setting. And I could then imagine sun redhat etc only supporting the software if you bought there hardware because they could only test it on that. And even then the potential to fall over an optimisation bug. That could mean finding a missing ( in about 3 million lines of code. That os would cost quite a lot of money. Lets keep it simple. Try and reduce the number of bugs not increase them.
(Log in to post comments)
Red Hat: no desktop products coming Posted Apr 20, 2008 21:01 UTC (Sun) by nix (subscriber, #2304) [Link] We'd be running Gentoo or one of the BSDs. :) `Build from source' is not implausible. mmarq's IR-distribution thingy (I can't entirely work out what he's driving at but that's what it seems like to me) is.
Red Hat: no desktop products coming Posted Apr 20, 2008 21:22 UTC (Sun) by danhah (guest, #51567) [Link] Hey I dont mind build from source as long as everybody contributes to the same source and we try to simplify things. But 10 people could have the exact hardware and just one of them could have a bug how long do you think it take to track that down. Forever I would think. I tell you what he wants a super optimized system. The extra 1% gain just isnt worth the extra hassle. Speed is never a problem for (on my PIII 700) its just the bugs that are killing me.
Red Hat: no desktop products coming Posted Apr 21, 2008 0:42 UTC (Mon) by mmarq (guest, #2332) [Link] Have you read other of my postings ? hey!... but was you yourself that complained vigorously in this thread "" Can somebody explain to me why redhat, ubuntu, any commercial organisation can get enthusiasts to help them find bugs and stabilise a product, only for them, once stable, to sell it as a stable enterprise os."" Do you think that is what is really happening ?... without "life long optimization", that is, without a permanent tunning and seeing, what conflicts with what really, how can you tell that the apps and libs that you "guess" are conflicting, are not running great as ever in RH "commercial" or other offerings, and no need to issue patches and or warnings ? "" The solution was to upgrade, upgrade the app but when I tried, that the old problem of dependency hell ( now I know that has changed with yum . Ok mandrake had a slightly newer version so I installed that. Great that worked - oh no some other app now has a different bug so that means upgrade or down grade. dependency hell again."" Isn't that because all possible combinations are impossible to track ? But if a really optimization effort was made to be possible, because a revenue stream is been generated, and the projects specially in desktop, and many more projects developers could be supported and funded,... wouldn't this dependency hell me much more attenuated ? I was in your side, because you and thousand more are in cold right now... i was in the cold many times, and could be tomorrow again... but your arguments only give reasons for RH not get involved in the mainstream desktop. Your objections to my posts seem to be that; - what would be made "commercial" and installed from those repositorys from online, would be much different from the *free*, and there would be a permanent winter!? How much worst could it be from what is now ?... wouldn't a real catch the bug and dependency, generating much more involvement from the original projects, so that apps can be changed and evolve to be vectorized and parallelized... help a lot ? Source Code: awareness track marketing mobility, specially for that source code if 'exposed' in a practical way... profits can generate a lot of improvements, dead RH, or Ubuntu or Novell... no!... and how much different would it be from "box checking" a package manager that install a binary, from the same thing that downloads the pre-formated source code or IL representation, compiles it and installs it ????........... The changed/optimized source code must be available anyway... its in the license. But yes, the generated "profile file" and then aplayed compiler settings could not... But do not *fear*, because there would be plenty of FAQs, wikis and howtos availables... profile generators too, and that LLVM infrastructure *DOES LIFE LONG CHECK AND OPTIMIZATION*, you would never be *LEFT BEHIND*, if savvy and willing to waste several days doing everything possible to get the most optimization out of it... chances are that your installation could even be better than the "commercial" installation !!!....... The idea of *TAKING FROM THE HANDS* of final users, *INITIAL* debugging and dependency hell, by installing from online, is only a *VERY GOOD SERVICE DESERVING A HONEST PROFIT*, because there are plenty out there that have a *gross mania* that they know a lot about computers, but the only thing they do is f..k up real good!!.. Otherwise why would a company waste resources, good engineers and high qualified technicians time, to support a zoo ( i wont pay royalties) of the utmost imbecility and 'ubber' idiocy, that is not only scary but is an horror movie that defies believe... getting itself under because of it ? ...i know!... i once get a really angry boss, and not of a corner shop, complaining furiously against my little company because why was that Windows(R) installs completely in the C: partition !!??... we was right the technician "supposedly" could have installed it in D:, the only think that was not accounted for is that that boss 'thing', with admin rights, would render MSFT the service of changing what was inside of the windows folder from place, because he felt that then would make much more sense and be much more aesthetic appealing!!!.... its only an example!... Why do you think that MSFT never got directly involved in this kind of direct support of desktop end users ???.... it gots plenty of patsys!... So what could be more simple, on the exploding need for bug squashing and dependency hell, than to fund the original projects and projects developers for the task ?... yes... can only be done if there is profit to justify it. What is the difficulty of making *part* of that "optimization" using virtual machines that mimic very closely the intended targets ? Why would it be that pernicious of having several *different optimizations* if there gonna be several different machine configurations, with different possible ISAs to support, and not only in the CPU ? 3008 ?... stream computing is already possible now and not only for HPC jobs, Fusion chips will be out in 2009, and the same for Intel Larabee, and Nvidia similar approaches... watch the news...
Red Hat: no desktop products coming Posted Apr 21, 2008 10:45 UTC (Mon) by danhah (guest, #51567) [Link] I am sure we have similar goals. All I am saying is lets try to simplify things to where it just works. Be it source or binary packages. Once that happens then lets look at optimisation. All that you are saying is a great idea and obviously something to aim for but I think we need to walk a little faster before flat out sprinting. Dependency hell will always be possible because if libc changes compatibility then things break. It is about acknowledging that and fitting that into a stable system.
Red Hat: no desktop products coming Posted Apr 21, 2008 19:11 UTC (Mon) by nix (subscriber, #2304) [Link] libc isn't going to break, full stop. However, what *is* a concern is a more general case of something which we did see in the last major upgrade. Remember the wtmp format change? Remember the GCC exception-handler errors, back when libgcc was always statically linked? This is a special case of a more general problem, which is that if some library code manages some shared resource, and more than one variety of it gets to run in the same address space (as happens with static linking, and with differing-soname shared linking), and those varieties have different expectations of some shared resource, things will break. Unix doesn't really have a good answer to this other than `soname breaks that affect shared libraries that are linked both into libraries and into the users of those libraries should force relinking of all those libraries at once, or changes of the intermediate libraries' sonames', both of which avoid having multiple copies of different versions of the same shared libraries in the same address space at once. Neither of these situations are exactly ideal, but as far as I know nobody's thought of a better way. (Has anyone?)
Red Hat: no desktop products coming Posted Apr 21, 2008 19:46 UTC (Mon) by danhah (guest, #51567) [Link] Wasn't there a problem with native threads? and libc. I remember a whole back some of the audio guys complaining about a problem with debian but a workaround was to use -ntpl or something like that. Interesting thread though, pity there is only 3 people reading it. :)
|
|||||||||||||