To use your own IRC client, join channel #boycottnovell in FreeNode.
| DavidGerard | wow, there's a nasty bug in kubuntu 9.04 re: openoffice 3.0 | Apr 27 00:01 |
|---|---|---|
| DavidGerard | ooo3 tries to talk kde ... 3. | Apr 27 00:01 |
| DavidGerard | you hit 'open' and it takes a minute for the file selector to pop up, several error dialogues along the way | Apr 27 00:02 |
| DavidGerard | presumably we're all supposed to use koffice | Apr 27 00:02 |
| jose_X | that would be a horrible bug indeed.. wonder what triggers it | Apr 27 00:02 |
| DavidGerard | um, me hitting control-O! | Apr 27 00:03 |
| DavidGerard | it's looking for a DCOP server that isn't quite what it expects any more | Apr 27 00:03 |
| *DavidGerard doesn't know enough of the internals of kde to understand it more | Apr 27 00:03 | |
| DavidGerard | that's what the error seems to be saying | Apr 27 00:03 |
| DavidGerard | i would say "i can't believe no-one tested this and marked it blocker" | Apr 27 00:04 |
| DavidGerard | but i can believe this | Apr 27 00:04 |
| DavidGerard | otoh it took until now for me to notice it | Apr 27 00:04 |
| DavidGerard | but then my .doc editing is actually mostly in google docs | Apr 27 00:04 |
| DavidGerard | there's me, living in the cloud. tasteful text ads woven into my line of vision. | Apr 27 00:04 |
| jose_X | DavidGerard, what I meant was that it seems that would be an obvious bug so maybe it has something to do with your hw setup or something else (maybe a combination of something else) | Apr 27 00:05 |
| _Hicham_ | DavidGerard : OOo is better supported by Gnome | Apr 27 00:06 |
| *_Hicham_1 (n=hicham@wana-92-245-12-196.wanamaroc.com) has joined #boycottnovell | Apr 27 00:14 | |
| jose_X | perhaps the bug shows with certain types of .doc formatted material.. or maybe some feature that is not fully implemented at this time. hopefully this wouldn't be something common | Apr 27 00:15 |
| Balrog | http://arstechnica.com/open-source/ne... | Apr 27 00:18 |
| *DavidGerard has quit (Read error: 110 (Connection timed out)) | Apr 27 00:24 | |
| *mib_ksosr5 has quit ("http://www.mibbit.com ajax IRC Client") | Apr 27 00:24 | |
| *_Hicham_ has quit (Read error: 110 (Connection timed out)) | Apr 27 00:39 | |
| *_Hicham_1 (n=hicham@wana-92-245-12-196.wanamaroc.com) has left #boycottnovell | Apr 27 00:46 | |
| jose_X | maybe DavidGerard will file a bug report. the .doc he used might be important | Apr 27 00:46 |
| *_Hicham_1 (n=hicham@wana-92-245-12-196.wanamaroc.com) has joined #boycottnovell | Apr 27 00:46 | |
| *_Hicham_1 is now known as _Hicham_ | Apr 27 00:46 | |
| jose_X | there are too many things that could create the prob. | Apr 27 00:46 |
| schestowitz | the bug can be reported to KDE/Ooe and fixed quickly | Apr 27 00:47 |
| schestowitz | If it's serious and applies to all, it'll be fixed | Apr 27 00:47 |
| schestowitz | Also, for KDE, Ubuntu does not seem like the right route. KDE is secondary in Canonical | Apr 27 00:47 |
| schestowitz | Mandriva is a good route | Apr 27 00:47 |
| jose_X | GreyGeek from LinuxToday (and BN) was very positive on Kubuntu904 | Apr 27 00:48 |
| jose_X | hw support and because he likes kde422 | Apr 27 00:48 |
| _Hicham_ | schestowitz : Yes, but better file the bug to OOo | Apr 27 00:48 |
| schestowitz | Mandriva 2009.1 is out soon | Apr 27 00:48 |
| schestowitz | Good KDE experience there. | Apr 27 00:49 |
| schestowitz | Not all KDE4s are created equal | Apr 27 00:49 |
| *oiaohm (n=oiaohm@unaffiliated/oiaohm) has joined #boycottnovell | Apr 27 00:49 | |
| _Hicham_ | but better install the upstream version first | Apr 27 00:49 |
| jose_X | bugs can arise from perfectly good sofware when used in bad configurations | Apr 27 00:49 |
| jose_X | maybe the dependencies weren't met | Apr 27 00:49 |
| oiaohm | Ok jose_X define bug. | Apr 27 00:49 |
| schestowitz | I've always assumed Ubuntu just takes the core system, tosses kde-desktop on it, then adds package manager and som e stuff | Apr 27 00:49 |
| schestowitz | Kubuntu is not the focus on Canonical | Apr 27 00:49 |
| _Hicham_ | Upstream projects binaries are better for filing bugs | Apr 27 00:50 |
| jose_X | "bug" | Apr 27 00:50 |
| schestowitz | They don't ship it as a product | Apr 27 00:50 |
| schestowitz | Unlike Mandriva... | Apr 27 00:50 |
| jose_X | point is we don't know what had the problem | Apr 27 00:50 |
| jose_X | so an "ooo bug" might not be an ooo bug at all.. that was the point i guess | Apr 27 00:50 |
| oiaohm | Some bugs where applications can be put into bad configure are lack of good configuration tools. | Apr 27 00:50 |
| oiaohm | To warn users of stupidity. | Apr 27 00:50 |
| jose_X | or bad docs | Apr 27 00:50 |
| oiaohm | Like samba | Apr 27 00:51 |
| _Hicham_ | he might install the debug package if he want to spot the problem | Apr 27 00:51 |
| jose_X | if people want stable, they should not be running the latest and greatest | Apr 27 00:51 |
| oiaohm | Really sold program but configuration is a nightmare. | Apr 27 00:51 |
| _Hicham_ | jose_X : not always good | Apr 27 00:51 |
| oiaohm | jose_X: latest and greatest is another problem. | Apr 27 00:51 |
| _Hicham_ | jose_X : do u agree on running OOo 2.4? | Apr 27 00:51 |
| _Hicham_ | it is more stable | Apr 27 00:52 |
| oiaohm | Why are distrobutions designed to only have 1 version of the runtime. | Apr 27 00:52 |
| jose_X | i don't use ooo or word processing for much | Apr 27 00:52 |
| jose_X | did my resume years ago in html and used html to pdf conversion | Apr 27 00:52 |
| _Hicham_ | oiaohm : to reuse the libraries | Apr 27 00:52 |
| oiaohm | There are a lot of cases where having many has stablity advantages. | Apr 27 00:52 |
| oiaohm | Ie applications only used with versions they are known stable with. | Apr 27 00:53 |
| oiaohm | Problem for distributions they try to force all applications to use 1 version. | Apr 27 00:53 |
| _Hicham_ | oiaohm : but that breaks one of a Linux Distro principles | Apr 27 00:53 |
| jose_X | my taxes are the html output from some javascript processing and that gets converted to pdf as well | Apr 27 00:53 |
| _Hicham_ | one library version for all programs | Apr 27 00:53 |
| oiaohm | Its a flawed idea. | Apr 27 00:54 |
| oiaohm | goal should be to get to 1. | Apr 27 00:54 |
| oiaohm | But not at the cost of users. | Apr 27 00:54 |
| oiaohm | Currently the idea of 1 is put before the cost to users. | Apr 27 00:54 |
| jose_X | oiaohm, completely agree about the version thing.. not saying no distro does that but most seem not to | Apr 27 00:54 |
| oiaohm | So users cannot run latest and greatest programs because old programs don't work with the new version. | Apr 27 00:55 |
| oiaohm | Really with multi version support there is not reason to split development and mainline as split installs. | Apr 27 00:55 |
| _Hicham_ | oiaohm : in that case the program uses its local library | Apr 27 00:55 |
| _Hicham_ | not the system's one | Apr 27 00:55 |
| jose_X | some apps come with the libraries they like.. so users do have that option if someone puts the package together that way | Apr 27 00:55 |
| jose_X | but distros are failing not to support many versions | Apr 27 00:56 |
| jose_X | there are a lot of things I want improved in distros | Apr 27 00:56 |
| jose_X | that doesn't mean things are bad now, but they can be better | Apr 27 00:56 |
| _Hicham_ | jose_X : like? | Apr 27 00:56 |
| schestowitz | links posted, gn | Apr 27 00:56 |
| oiaohm | Take debian sid testing and stable | Apr 27 00:56 |
| jose_X | _Hicham_, do you mean what I would change? | Apr 27 00:57 |
| oiaohm | If there was proper multi version support in there you could have a single tree. | Apr 27 00:57 |
| _Hicham_ | jose_X : yes | Apr 27 00:57 |
| oiaohm | With all the parts in sid testing and stable. | Apr 27 00:57 |
| oiaohm | With users able to install any combination of it without any issues. | Apr 27 00:57 |
| oiaohm | Its supprisingly not that hard to do. | Apr 27 00:57 |
| _Hicham_ | oiaohm : I don't think it is a good idea | Apr 27 00:57 |
| oiaohm | The dynamic loader in Linux is a userspace program. | Apr 27 00:58 |
| jose_X | well, i want applications to build dependencies that are accurate and extensive | Apr 27 00:58 |
| jose_X | anyone can take the lead here.. we need not wait for projects.. you can patch them | Apr 27 00:58 |
| _Hicham_ | and u know that one of the main reasons to use up-to-date libraries is security concerns | Apr 27 00:58 |
| jose_X | the result would allow easier building of distros.. of custom distros | Apr 27 00:58 |
| _Hicham_ | that is why programs should be relinked against new versions | Apr 27 00:59 |
| oiaohm | So debian back ports patches to old appliccations and that does not cause secuirty problems _Hicham_ | Apr 27 00:59 |
| jose_X | you can manage the security issue to a degree with chroot and other tools | Apr 27 00:59 |
| oiaohm | 1 version stops defective programs from just being deleted out of existance. | Apr 27 00:59 |
| _Hicham_ | oiaohm : backports are not always a good idea | Apr 27 00:59 |
| oiaohm | Instead of just upgrading them. | Apr 27 01:00 |
| oiaohm | There are lots of cost to that 1 version idea. | Apr 27 01:00 |
| oiaohm | forced to do backports is one of them. | Apr 27 01:00 |
| _Hicham_ | oiaohm : Debian model is unique | Apr 27 01:00 |
| oiaohm | Redhat does it too. | Apr 27 01:00 |
| oiaohm | Its not unique | Apr 27 01:00 |
| jose_X | consider forking | Apr 27 01:01 |
| oiaohm | You end up wall pinned. | Apr 27 01:01 |
| jose_X | that should be supported and encouraged | Apr 27 01:01 |
| oiaohm | If I update this .so file I will break like 20 applications. | Apr 27 01:01 |
| oiaohm | But one applications has a secuirty flaw and it needs a never version of it. | Apr 27 01:01 |
| _Hicham_ | oiaohm : u can always link it against a local library | Apr 27 01:01 |
| oiaohm | So backporting gets forced. | Apr 27 01:01 |
| oiaohm | Linking to a local library break the 1 lib for all rule too _Hicham_ | Apr 27 01:02 |
| oiaohm | You have to break the rule. | Apr 27 01:02 |
| oiaohm | Or have messes. | Apr 27 01:02 |
| jose_X | _Hicham_ what you just said would be support for multiple versions. that should be faciliated not just possible | Apr 27 01:02 |
| jose_X | unix supports multiple versions.. i'm not arguing things are hell.. i'm just saying that i would like more support in that area | Apr 27 01:03 |
| oiaohm | Mutli version also allows segment by segment upgrade. | Apr 27 01:03 |
| oiaohm | Also segment by segment roll back. | Apr 27 01:03 |
| oiaohm | So you upgrade and a key program you need does not work. | Apr 27 01:04 |
| jose_X | it would put more control in the end user instead of the concept of a package provider | Apr 27 01:04 |
| _Hicham_ | oiaohm : if the library is vulnerable, all programs that depend on it must be retested after upgrade | Apr 27 01:04 |
| oiaohm | Makes problems more correctable by end user. | Apr 27 01:04 |
| oiaohm | Mutli lib is about applications not libs _Hicham_ | Apr 27 01:04 |
| oiaohm | Yes a secuirty flawed lib could still force back porting. | Apr 27 01:05 |
| oiaohm | But we really don't need back porting on everything. | Apr 27 01:05 |
| _Hicham_ | it can be patched | Apr 27 01:05 |
| _Hicham_ | as Debian do | Apr 27 01:05 |
| oiaohm | Backporting. | Apr 27 01:06 |
| _Hicham_ | without upgrading the whole system | Apr 27 01:06 |
| oiaohm | Debian takes fix from newer version and coverts to older. | Apr 27 01:06 |
| oiaohm | Ie backporting. | Apr 27 01:06 |
| _Hicham_ | yes | Apr 27 01:06 |
| _Hicham_ | to ensure system stability | Apr 27 01:06 |
| oiaohm | Problem with backporting it causes unstablity as well. | Apr 27 01:06 |
| _Hicham_ | how? | Apr 27 01:07 |
| oiaohm | If patch does not fit in right big problems happen. | Apr 27 01:07 |
| oiaohm | backports are not as well tested. | Apr 27 01:07 |
| _Hicham_ | if there is not enough testing | Apr 27 01:07 |
| _Hicham_ | not security patches | Apr 27 01:07 |
| _Hicham_ | security patches get well tested in Debian | Apr 27 01:07 |
| oiaohm | A main open source project the code is built and tested by many distributions. | Apr 27 01:07 |
| oiaohm | Even debain secuirty patches are on advrage more flawed than just updating the lib. | Apr 27 01:08 |
| oiaohm | Backporting need to be a last resort option. | Apr 27 01:08 |
| _Hicham_ | backporting is not advised in Debian | Apr 27 01:09 |
| oiaohm | Libs with backport need to be least used. So reducing risk. | Apr 27 01:09 |
| oiaohm | Debian has backports even on libc | Apr 27 01:09 |
| oiaohm | Even that for over 90 percent of the applications could be just using the newer version. | Apr 27 01:09 |
| _Hicham_ | backports for libc? | Apr 27 01:10 |
| oiaohm | So avoiding risks. | Apr 27 01:10 |
| oiaohm | Debian is not a good example of how to do it. | Apr 27 01:10 |
| _Hicham_ | seems illogical | Apr 27 01:10 |
| oiaohm | Once debain goes stable. | Apr 27 01:10 |
| oiaohm | The versions of libs basically locks. | Apr 27 01:10 |
| _Hicham_ | why backport libc? | Apr 27 01:10 |
| _Hicham_ | better upgrade the whole system | Apr 27 01:11 |
| oiaohm | then have stacks of applications that don't work. | Apr 27 01:11 |
| oiaohm | You need half way point. | Apr 27 01:11 |
| jose_X | _Hicham_, Linux is overdue for a file format (eg, xml) to describe in as homogenous a fashion as possible as much metadata about each project | Apr 27 01:11 |
| oiaohm | Halfway between full upgrade and the old flawed system. | Apr 27 01:12 |
| jose_X | this is a necessary step to giving the end user maximum control | Apr 27 01:12 |
| oiaohm | Basically the 1 lib idea does not work. | Apr 27 01:12 |
| jose_X | it could be used for things like to properly account for license/authors as well as (importantly) for dependencies and build hints or instructions | Apr 27 01:12 |
| oiaohm | What is need is a rolling system. | Apr 27 01:12 |
| _Hicham_ | oiaohm : so there should be many libc versions? | Apr 27 01:13 |
| oiaohm | So upgrading happens in a invisable way. | Apr 27 01:13 |
| oiaohm | _Hicham_: most likely 2 versions. | Apr 27 01:13 |
| oiaohm | One for older applications that will not work with more modern libc | Apr 27 01:14 |
| oiaohm | Of course the older 1 has the back ported patches in it. | Apr 27 01:14 |
| oiaohm | And is planed for removal as soon as no more applications depend on it. | Apr 27 01:14 |
| oiaohm | Basically a deprecation system. | Apr 27 01:15 |
| _Hicham_ | oiaohm : it is an upgrading process | Apr 27 01:15 |
| oiaohm | Yes. | Apr 27 01:15 |
| oiaohm | Just not a big change at once as the current system demards. | Apr 27 01:16 |
| _Hicham_ | that brings us to the fast release cycle vs long term cycle | Apr 27 01:16 |
| oiaohm | It also provides the option of going backwards temp until issues with newer parts are vised. | Apr 27 01:16 |
| oiaohm | This is called no cycle. | Apr 27 01:16 |
| oiaohm | All updates happen when they are ready. | Apr 27 01:17 |
| _Hicham_ | Debian vs Ubuntu, RHEL vs Fedora | Apr 27 01:17 |
| oiaohm | none of them run on a no cycle. | Apr 27 01:17 |
| oiaohm | cycle sets a fixed time between updates. | Apr 27 01:18 |
| _Hicham_ | oiaohm : no cycle is not good | Apr 27 01:18 |
| _Hicham_ | especially for commercial ends | Apr 27 01:18 |
| oiaohm | How its it not good. | Apr 27 01:18 |
| oiaohm | No cycle allows older programs to work. | Apr 27 01:19 |
| _Hicham_ | older programs should be upgraded | Apr 27 01:19 |
| oiaohm | For longer than cycle do. | Apr 27 01:19 |
| _Hicham_ | or ported to new libs | Apr 27 01:19 |
| oiaohm | older programs in business should only be upgraded if the upgrade works. | Apr 27 01:19 |
| oiaohm | Its about the users. | Apr 27 01:20 |
| oiaohm | Current hack around cycle is chroot the old defective distribution. | Apr 27 01:20 |
| oiaohm | What means more applications with defective parts _Hicham_ | Apr 27 01:21 |
| oiaohm | no cycle allows updates at any time. Either for features or secuirty. | Apr 27 01:21 |
| oiaohm | Allows defective parts to be depreaced out faster than fixed cycle. | Apr 27 01:22 |
| _Hicham_ | oiaohm : i don't think that this is applicable | Apr 27 01:22 |
| oiaohm | cycle effects business usage _Hicham_ | Apr 27 01:22 |
| oiaohm | MS is having the trouble with Vista due to upgrade cost due to numbers of applications that will fail. | Apr 27 01:23 |
| oiaohm | Businesses are staying put. | Apr 27 01:23 |
| _Hicham_ | but at least, people will know when to upgrade their systems | Apr 27 01:23 |
| oiaohm | MS in windows 7 is now forced to virtualise XP . | Apr 27 01:23 |
| oiaohm | So all the viruses of XP will remain around. | Apr 27 01:23 |
| oiaohm | For a lot longer. | Apr 27 01:24 |
| oiaohm | Basically failure. | Apr 27 01:24 |
| oiaohm | That is the path cycle sooner or latter causes. | Apr 27 01:24 |
| _Hicham_ | Microsoft has no release cycle | Apr 27 01:24 |
| oiaohm | LOL | Apr 27 01:24 |
| oiaohm | They do. | Apr 27 01:24 |
| oiaohm | Last 2 have been late. | Apr 27 01:25 |
| oiaohm | Just like debain is late on it release cycles. | Apr 27 01:25 |
| _Hicham_ | they failed to release Vista on time ( old Longhorn ) | Apr 27 01:25 |
| _Hicham_ | Debian has no release cycles too | Apr 27 01:25 |
| oiaohm | Debian is ment to get a release out every 12 months. | Apr 27 01:25 |
| oiaohm | So far never happened. | Apr 27 01:25 |
| oiaohm | Ok once | Apr 27 01:26 |
| oiaohm | Secound version. | Apr 27 01:26 |
| _Hicham_ | meant and do are different things | Apr 27 01:26 |
| oiaohm | They still have a time tabled release cycle. | Apr 27 01:26 |
| oiaohm | Just fail to stick to it. | Apr 27 01:26 |
| _Hicham_ | because it is a volunteer projects | Apr 27 01:27 |
| oiaohm | Ubuntu has failed to stick to theres from time to time too. | Apr 27 01:27 |
| oiaohm | All items with a release cycle will miss it from time to time. | Apr 27 01:27 |
| oiaohm | Some groups are better at keeping it than others. | Apr 27 01:27 |
| oiaohm | Wine has a development version release cycle of 2 weeks. | Apr 27 01:27 |
| oiaohm | 90 percent of the time they hit it. | Apr 27 01:27 |
| _Hicham_ | Fedora's approach is great | Apr 27 01:27 |
| oiaohm | Sometimes it expands to 3 to 4 weeks. | Apr 27 01:27 |
| _Hicham_ | they always have a contingency plan | Apr 27 01:28 |
| _Hicham_ | if we fail to do that, here is plan B | Apr 27 01:28 |
| oiaohm | That is better release cycle management. | Apr 27 01:28 |
| oiaohm | But its still a cycle. | Apr 27 01:28 |
| oiaohm | In a no cycle you can still have offical releases. | Apr 27 01:29 |
| oiaohm | The difference in a no cycle your end users are automatically updated. | Apr 27 01:29 |
| _Hicham_ | oiaohm : a cycle ensure syncing with upstream projects | Apr 27 01:30 |
| oiaohm | All upstream projects have different cycles. | Apr 27 01:30 |
| oiaohm | Like you are not going to try to keep a full distribution normally up a wine cycle of 2 weeks. | Apr 27 01:30 |
| oiaohm | No cycle in the distribution allows each bit to run at the cycle of the upstream project. | Apr 27 01:31 |
| oiaohm | Linux kernel cycles every 3 months. KDE and Gnome releses are never in line with each other. | Apr 27 01:33 |
| _Hicham_ | oiaohm : u are then promoting Windows philosophy | Apr 27 01:33 |
| oiaohm | Basically setting a cycle at distribution level brings you into conflit with all the cycles you have to stay synced. | Apr 27 01:33 |
| *Omar87 has quit ("Leaving.") | Apr 27 01:34 | |
| oiaohm | Not a windows one. | Apr 27 01:34 |
| oiaohm | There is still a place for quality control. | Apr 27 01:34 |
| _Hicham_ | how ? | Apr 27 01:34 |
| oiaohm | Fixed cycles force items to be rushed. | Apr 27 01:34 |
| _Hicham_ | which is great | Apr 27 01:35 |
| _Hicham_ | rushing is always good | Apr 27 01:35 |
| oiaohm | Depends. | Apr 27 01:35 |
| oiaohm | If you are the poor user who lossed document because of it. | Apr 27 01:35 |
| _Hicham_ | I appreciate rushing | Apr 27 01:35 |
| *the_mad_hatter (n=chatzill@H166.C206.cci.switchworks.net) has joined #boycottnovell | Apr 27 01:35 | |
| _Hicham_ | it is the user's fault then | Apr 27 01:35 |
| oiaohm | Would it not be better to run all the QA tests | Apr 27 01:35 |
| the_mad_hatter | Always user fault <G> | Apr 27 01:36 |
| oiaohm | Before droping it on the user. | Apr 27 01:36 |
| _Hicham_ | oiaohm : nothing is perfect | Apr 27 01:36 |
| the_mad_hatter | Have you heard about XPM? | Apr 27 01:36 |
| _Hicham_ | everything needs extensive testing | Apr 27 01:36 |
| oiaohm | no cycle allows focus to stick on having it done right. | Apr 27 01:36 |
| _Hicham_ | that is why we have development versions of distros | Apr 27 01:36 |
| oiaohm | Ok this bit not ready. Plan b it use older verison for now. | Apr 27 01:36 |
| _Hicham_ | everything goes tested in there | Apr 27 01:37 |
| the_mad_hatter | New option in some versions of Windows 7 - XP Compatibility Mode | Apr 27 01:37 |
| the_mad_hatter | http://community.winsupersite.com/b... | Apr 27 01:37 |
| oiaohm | Stuff stays in development versions longer than it should. | Apr 27 01:37 |
| oiaohm | Stuff stays in stable longer than it should too. | Apr 27 01:37 |
| oiaohm | Basically fixed cycle ends up with crud. | Apr 27 01:37 |
| oiaohm | Poor user ends up paying for it. | Apr 27 01:38 |
| _Hicham_ | oiaohm : how to do QA then? | Apr 27 01:38 |
| _Hicham_ | how to fix the time of testing? | Apr 27 01:38 |
| oiaohm | You know that like 6 months before debian release 95 percent of the applications are fully tested. | Apr 27 01:39 |
| _Hicham_ | yes | Apr 27 01:39 |
| oiaohm | Its the 5 percent that cause the delay form users getting access to those features. | Apr 27 01:39 |
| oiaohm | So users are stuck with worse programs due to 5 percent problem. | Apr 27 01:39 |
| _Hicham_ | but Debian have a longer testing time because of the different archs it supports | Apr 27 01:40 |
| oiaohm | QA method does not really need to change. | Apr 27 01:40 |
| _Hicham_ | Fedora have a different approach | Apr 27 01:40 |
| oiaohm | Delievery need to. | Apr 27 01:40 |
| _Hicham_ | how ? | Apr 27 01:40 |
| oiaohm | When its passed it goes to user. | Apr 27 01:40 |
| oiaohm | To do that you need multi lib support. | Apr 27 01:40 |
| oiaohm | Only the not passed stuff remains in the development versions. | Apr 27 01:41 |
| oiaohm | This also makes it simple for people to focus what needs work. | Apr 27 01:41 |
| oiaohm | The advantage of no cycle. Cleaner to see where work has to be done. | Apr 27 01:42 |
| _Hicham_ | multilib support is present in Debian | Apr 27 01:42 |
| _Hicham_ | there is for example libstdc++5 and 6 | Apr 27 01:42 |
| _Hicham_ | upstream Thunderbird is linked against libstdc++5 | Apr 27 01:43 |
| oiaohm | Only to a small ammount. | Apr 27 01:43 |
| oiaohm | Simply they were forced. | Apr 27 01:44 |
| _Hicham_ | there is gtk+-2.0 and gtk+-1.2 | Apr 27 01:45 |
| oiaohm | But you would not see subversions in there when they are needed. | Apr 27 01:45 |
| oiaohm | Basically the idea of 1 lib already does not exist. | Apr 27 01:45 |
| _Hicham_ | that is what I want to say | Apr 27 01:46 |
| oiaohm | Accept it move forward and do what is best for the end users. | Apr 27 01:46 |
| oiaohm | Best for the end users is getting the newest stable applications to them as soon as you can. | Apr 27 01:46 |
| _Hicham_ | the model ur proposing is problematic, and brings more overhead | Apr 27 01:46 |
| oiaohm | Really not. | Apr 27 01:46 |
| oiaohm | Brings more disk space usage. | Apr 27 01:47 |
| _Hicham_ | for sure | Apr 27 01:47 |
| oiaohm | Work wise no more than maintaining the 3 branches. | Apr 27 01:47 |
| _Hicham_ | u will end up with a really huge /usr/lib and /lib directories | Apr 27 01:47 |
| oiaohm | To a point. | Apr 27 01:47 |
| _Hicham_ | it is disk space and memory usage too | Apr 27 01:48 |
| oiaohm | Applications shipping with there own libs also will cost that. | Apr 27 01:48 |
| _Hicham_ | firefox and thunderbird do not share the same libraries | Apr 27 01:49 |
| oiaohm | Users isntalling a chroot to use older applciations will cost more. | Apr 27 01:49 |
| _Hicham_ | older applications are problematic too | Apr 27 01:49 |
| _Hicham_ | simply they need to be ported to new libraries | Apr 27 01:49 |
| oiaohm | I want to be rid of them. | Apr 27 01:49 |
| oiaohm | But they don't disappear over night. | Apr 27 01:50 |
| _Hicham_ | or provide a compatibilty bridge library | Apr 27 01:50 |
| oiaohm | Problem with chroot is it gets out side the normal update cycle. | Apr 27 01:50 |
| _Hicham_ | like redhat do | Apr 27 01:50 |
| Balrog_ | multilibs ... Apple does it in an interesting way | Apr 27 01:50 |
| _Hicham_ | why not bridge libs? | Apr 27 01:51 |
| oiaohm | redhat compatibilty bridges allow cycle crossing. | Apr 27 01:51 |
| oiaohm | bridge libs could be used as the final depreaction move of a lib _Hicham_ in a no cycle. | Apr 27 01:51 |
| Balrog_ | they use a 'framework' directory that's structured like this: Root --> Headers, <Binary>, Resources [all symlinks]; Versions --> [version number] --> Headers, <Binary>, Resources | Apr 27 01:52 |
| oiaohm | Users don't want to be using really old programs either. | Apr 27 01:52 |
| *seller_liar has quit ("http://www.mibbit.com ajax IRC Client") | Apr 27 01:52 | |
| Balrog_ | then you can have multiple versions within the same package | Apr 27 01:52 |
| Balrog_ | the symlinks link to the current version | Apr 27 01:52 |
| Balrog_ | of course, this isn't used for different architectures as there are fat binaries for that. | Apr 27 01:52 |
| jose_X | _Hicham_ the disk space usage is not a prob. however clutter is a different matter. the two are independent of each other though not in practice today | Apr 27 01:53 |
| _Hicham_ | oiaohm : providing a bridge library is easier than porting a whole lot of stuff | Apr 27 01:53 |
| oiaohm | bridge library is still a multi lib solution. | Apr 27 01:53 |
| _Hicham_ | oiaohm : but it is less problematic | Apr 27 01:54 |
| oiaohm | Just reduces diskspace for the means to do it. | Apr 27 01:54 |
| jose_X | oiaohm, we can have auto chroot support created so that it is not a big deal but happens transparently | Apr 27 01:54 |
| oiaohm | The problem with the chroot is the version of Linux in there jose_X | Apr 27 01:54 |
| oiaohm | Lot of places forget what they have in there. | Apr 27 01:54 |
| oiaohm | So it becomes completely not supported. | Apr 27 01:55 |
| oiaohm | Yet still in use. | Apr 27 01:55 |
| oiaohm | _Hicham_ its time to make bridge libs they don't come out of thin are. | Apr 27 01:55 |
| oiaohm | Its all comprimses. | Apr 27 01:56 |
| oiaohm | Allowing multi libs side by side allows stuff to work. | Apr 27 01:56 |
| oiaohm | At the cost of more disk and memory. | Apr 27 01:56 |
| jose_X | oiaohm, i haven't played with chroot much but i don't see the prob you are implying exists. could you be more specific | Apr 27 01:56 |
| oiaohm | Lets say you put like a LTS version of ubuntu in that chroot. | Apr 27 01:57 |
| oiaohm | You are using 1 or 2 applications from it. | Apr 27 01:57 |
| oiaohm | Could you not forget about it completely when it goes end of life. | Apr 27 01:57 |
| oiaohm | That is what happens. | Apr 27 01:57 |
| oiaohm | The cycle split causes these problems. Users cannot run old and new under the single management system to draw there attention to stuff that should be removed. | Apr 27 01:58 |
| jose_X | oiaohm, i think you are saying that chroot is not designed into the distro and supported | Apr 27 01:59 |
| oiaohm | There is not need for chroot if applications work with each other either jose_X | Apr 27 01:59 |
| jose_X | you are talking about an end user hack that might be done today, right? i would like distros to support, among other things, a framework that i think chroot could help implement | Apr 27 01:59 |
| oiaohm | I am talking about what is done today. | Apr 27 02:00 |
| jose_X | is chroot not useful for security? | Apr 27 02:00 |
| _Hicham_ | oiaohm : bridge libs is better at that | Apr 27 02:00 |
| jose_X | to isolate instances of runnings | Apr 27 02:00 |
| jose_X | in particular, make it easy to go from one chroot to another ... | Apr 27 02:00 |
| _Hicham_ | we can keep upgrading programs until the bridge libs get orphaned | Apr 27 02:00 |
| jose_X | and ... | Apr 27 02:00 |
| oiaohm | chroot alone is not useful. You need to wrap it up in containers. | Apr 27 02:00 |
| jose_X | reuse.. | Apr 27 02:01 |
| jose_X | i think the future is source distros | Apr 27 02:01 |
| oiaohm | Basically _Hicham_ bridge beats back portings. | Apr 27 02:01 |
| jose_X | but not like gentoo where one group sets up all the limits | Apr 27 02:01 |
| jose_X | rather like Linux from scratch.. | Apr 27 02:01 |
| jose_X | but with a lot more organization and standardization of semantic descriptions of the project appications taht exist or are created | Apr 27 02:02 |
| oiaohm | Multi version allows when bridge don't work so applications still to _Hicham_ | Apr 27 02:02 |
| oiaohm | Correct answer as with all these things is use many different items to get close to ideal as able. | Apr 27 02:02 |
| oiaohm | Idea for users is latest and greatest applications with perfect stablity. | Apr 27 02:03 |
| oiaohm | Idea/Ideal | Apr 27 02:03 |
| _Hicham_ | Unreachable Ideal | Apr 27 02:03 |
| oiaohm | I know. | Apr 27 02:03 |
| oiaohm | But what is the closest we can get to it. | Apr 27 02:03 |
| jose_X | oiaohm, what you are describing is some oil to help smooth through cases some users run into today. what I am saying is simply to take that sort of support for multiversion to a new level to allow much more flexible computing in the future | Apr 27 02:03 |
| jose_X | you might thing we would make a mess of things.. but not if we tag all important issues carefully.. | Apr 27 02:04 |
| oiaohm | Without Users distributions die. | Apr 27 02:04 |
| oiaohm | Its really simple to forgot what the users needs and goals are. | Apr 27 02:05 |
| oiaohm | MS vista was a great example of that. | Apr 27 02:05 |
| _Hicham_ | oiaohm : if all libraries providers were to provide bridges, we wouldn't run into that | Apr 27 02:05 |
| jose_X | comparisons to windows don't work because you don't get access to source there | Apr 27 02:05 |
| oiaohm | Not really _Hicham_ | Apr 27 02:06 |
| jose_X | linux is different. users really can be in control | Apr 27 02:06 |
| _Hicham_ | basically, there should be a smooth transition plan | Apr 27 02:06 |
| oiaohm | dynamic loader of Linux finds the first .so not the best .so for the applciation. | Apr 27 02:06 |
| oiaohm | multi lib support means correcting the loader. | Apr 27 02:06 |
| jose_X | now imagine the loader.. | Apr 27 02:06 |
| oiaohm | Or correcting the executable. | Apr 27 02:07 |
| jose_X | simply being part of a larger creation framework where it could be customized on a per app basis | Apr 27 02:07 |
| jose_X | the complexity can be managed because most uses cases are few in number and have a well defined set of constraints | Apr 27 02:07 |
| oiaohm | Basically they don't build bridges in large numbers because no management framework is there _Hicham_ | Apr 27 02:07 |
| *Balrog_ has quit ("bye") | Apr 27 02:08 | |
| jose_X | imagine debian, and every other distro maintainer standardizing their recipes | Apr 27 02:08 |
| oiaohm | libs also support versioning. But that is more of a night mare than a help. | Apr 27 02:08 |
| oiaohm | Applciation is taged to only talk to X version. | Apr 27 02:08 |
| jose_X | there would be large overlaps (we would search and design it to be so).. | Apr 27 02:08 |
| oiaohm | You have updated by 1 darm without version. | Apr 27 02:09 |
| jose_X | distros would be created by end users and projects would export semantic tags to facilitate this | Apr 27 02:09 |
| oiaohm | Not going to happen any time soon jose_X | Apr 27 02:09 |
| jose_X | sure oiaohm that's what they said about .... | Apr 27 02:10 |
| oiaohm | LSB project | Apr 27 02:10 |
| oiaohm | work with them | Apr 27 02:10 |
| jose_X | a demo to show the proof of concept could get a lot of people on board | Apr 27 02:10 |
| _Hicham_ | jose_X : "distros would be created by end users"? | Apr 27 02:10 |
| oiaohm | Know first hand how hard distributions hold on to there own packaging format. | Apr 27 02:10 |
| jose_X | you are familiar with linux from scratch right | Apr 27 02:10 |
| _Hicham_ | LSB is great | Apr 27 02:10 |
| oiaohm | Biggest cat fight in LSB history was over packaging. | Apr 27 02:11 |
| oiaohm | jose_X lot of project have produced demos of it. | Apr 27 02:12 |
| oiaohm | And they have all died a slow death. | Apr 27 02:12 |
| _Hicham_ | oiaohm : third parties rarely use specific package management | Apr 27 02:12 |
| jose_X | we are talking about different things | Apr 27 02:12 |
| jose_X | oiaohm | Apr 27 02:12 |
| _Hicham_ | they provide their installer/unistaller à la Windows | Apr 27 02:12 |
| oiaohm | Mostly because of the incompadible. | Apr 27 02:13 |
| jose_X | well closed source apps are a different beast. | Apr 27 02:13 |
| oiaohm | Lot of those ISV's come to LSB and want a common packaging format. | Apr 27 02:13 |
| oiaohm | When they cannot have it they go back to the windows way. | Apr 27 02:13 |
| _Hicham_ | thanks to god we have checkinstall | Apr 27 02:14 |
| _Hicham_ | u can have a package for ur distros our of the binary installer | Apr 27 02:14 |
| oiaohm | LSB is trying to get packagekit up. | Apr 27 02:14 |
| jose_X | when you want to update a package, you say something like Package-app refresh and install X | Apr 27 02:14 |
| jose_X | The user has control but it is at a very high level | Apr 27 02:15 |
| *the_mad_hatter has quit (Read error: 110 (Connection timed out)) | Apr 27 02:15 | |
| oiaohm | So those binary installers will register what they install _Hicham_ | Apr 27 02:15 |
| jose_X | what they install as been preplaned to a large degree and you can't deviate from that plan | Apr 27 02:15 |
| oiaohm | jose_X you have been describing the fist goals of gentoo. | Apr 27 02:15 |
| oiaohm | A working system providing what you are talking about with market dominance is not going to happen soon. | Apr 27 02:16 |
| _Hicham_ | packagekit found its way into ubuntu | Apr 27 02:16 |
| jose_X | the install instructions could be more general with the building being done on the users pc and aware of what already existed there | Apr 27 02:16 |
| _Hicham_ | but not into debian yet | Apr 27 02:16 |
| _Hicham_ | still, packagekit depends on a distribution package manager | Apr 27 02:17 |
| jose_X | not soon as in 2 years, but i can see this growing for sure | Apr 27 02:17 |
| oiaohm | packagekit allows packages to be installed not in the distributions package format. | Apr 27 02:17 |
| jose_X | the user's pc would cache past builds and reuse where possible | Apr 27 02:17 |
| _Hicham_ | oiaohm : how then? | Apr 27 02:18 |
| jose_X | the actual system the user sees would be like a database view | Apr 27 02:18 |
| oiaohm | Its interfaces _Hicham_ | Apr 27 02:18 |
| oiaohm | You still only need 1 database for installed packages. | Apr 27 02:18 |
| _Hicham_ | do u mean that we can mix formats? | Apr 27 02:19 |
| oiaohm | Yep | Apr 27 02:19 |
| jose_X | btw, i can see a case where you'd buy your pc from a linux vendor and it would allocate say 200 gigs for this framework.. the pc would come with a huge amount of prebuild stuff (and source of course) | Apr 27 02:19 |
| oiaohm | novell built a rpm installer that used packagekit. | Apr 27 02:19 |
| oiaohm | to a gentoo back end. | Apr 27 02:20 |
| oiaohm | behind packagekit. | Apr 27 02:20 |
| _Hicham_ | so we will have a unified database for all specific package managers? | Apr 27 02:20 |
| oiaohm | Hopefully. | Apr 27 02:20 |
| oiaohm | More like does not matther about package format. | Apr 27 02:21 |
| oiaohm | It can reg in what ever database you like using. | Apr 27 02:21 |
| _Hicham_ | it is problematic too | Apr 27 02:23 |
| _Hicham_ | since some distros have specific libs | Apr 27 02:23 |
| _Hicham_ | basically, we should just merge rpm and deb | Apr 27 02:27 |
| jose_X | why is it a problem to mix sources of debs or rmps etc? | Apr 27 02:27 |
| jose_X | .. because there are too many items that are hardwired | Apr 27 02:27 |
| jose_X | and the decisions taken differ among packagers | Apr 27 02:28 |
| jose_X | if you abstract all of these issues | Apr 27 02:28 |
| _Hicham_ | jose_X : abstracting is not evident | Apr 27 02:28 |
| jose_X | you don't have to be able to abstract everything | Apr 27 02:28 |
| jose_X | flexibility by some allows inflexibilities by others | Apr 27 02:28 |
| jose_X | but this is foss.. we can patch and homogenize as necessary.. if people get behind it | Apr 27 02:29 |
| jose_X | and what does "evident" mean? certainly not unsolvable | Apr 27 02:29 |
| jose_X | just that you couldn't do it with what we have today without roling up sleaves | Apr 27 02:29 |
| jose_X | end user centric has to make the concept of forking easy to execute | Apr 27 02:29 |
| jose_X | at least if you want to tap into the flexibility (the killer feature) of foss | Apr 27 02:30 |
| jose_X | the concept of distro and apps and whatever would meld into a single "current system configuration" | Apr 27 02:31 |
| _Hicham_ | just take for example Debian debs and Ubuntu debs | Apr 27 02:31 |
| jose_X | i'm all ears | Apr 27 02:31 |
| _Hicham_ | mixing them is not an option | Apr 27 02:31 |
| jose_X | we need to iron all of these issues out | Apr 27 02:31 |
| jose_X | i know | Apr 27 02:31 |
| oiaohm | There is a way to mix them _Hicham_ | Apr 27 02:32 |
| jose_X | they are inflexible recipes | Apr 27 02:32 |
| _Hicham_ | just like Mandriva, Fedora, and OpenSuse rpms | Apr 27 02:32 |
| jose_X | we need flexible recipes | Apr 27 02:32 |
| oiaohm | Supprising with a little bit of loader hacking can do. | Apr 27 02:32 |
| oiaohm | I have merged distributions in the past _Hicham_ | Apr 27 02:32 |
| _Hicham_ | oiaohm : I am not talking about libs | Apr 27 02:32 |
| jose_X | think declarative html vs something with less flexibility like an actual machine language byte stream that gives few outside options | Apr 27 02:32 |
| oiaohm | I know every dirty trick to do. | Apr 27 02:32 |
| _Hicham_ | I am talking about packages | Apr 27 02:32 |
| oiaohm | To cross the packages. | Apr 27 02:33 |
| jose_X | btw, oiaohm, i know you can blend the debs through a higher abstraction layer | Apr 27 02:33 |
| oiaohm | You need to source lower and upper levels. | Apr 27 02:33 |
| jose_X | never mind | Apr 27 02:33 |
| _Hicham_ | here is an example : some packages in Ubuntu try to write other packages contents in Debian | Apr 27 02:34 |
| jose_X | i got distracted.. the issue of allowing multiple package types is disctinct | Apr 27 02:34 |
| _Hicham_ | packages do not have the same contents | Apr 27 02:34 |
| jose_X | from saying that any two given packages are compat with each other | Apr 27 02:34 |
| oiaohm | Still can be handled _Hicham_ | Apr 27 02:34 |
| oiaohm | It does get really evil. | Apr 27 02:34 |
| oiaohm | Fun is the /etc directory and the home directory. | Apr 27 02:35 |
| _Hicham_ | oiaohm : u have to uncompress the package and recreate it | Apr 27 02:35 |
| oiaohm | No | Apr 27 02:35 |
| oiaohm | You high jack the package managers. | Apr 27 02:35 |
| oiaohm | Then cause each to use different loaders | Apr 27 02:36 |
| jose_X | anyway all of that would be faciliated if we moved around the recipes instead of the whole implemented recipe that is the package | Apr 27 02:36 |
| oiaohm | From the loader you can chroot. | Apr 27 02:36 |
| oiaohm | If required. | Apr 27 02:36 |
| oiaohm | So yes mergable yes messy as hell. | Apr 27 02:36 |
| jose_X | oiaohm, imagine taking that but standardizing so that it is not messy as hell | Apr 27 02:37 |
| jose_X | with declarative content it's easier to have these implemented differently depending on greater context | Apr 27 02:37 |
| _Hicham_ | Linux will never be merged | Apr 27 02:37 |
| jose_X | so the "implementing of the packages" if you will happens where the user is at | Apr 27 02:37 |
| jose_X | this is flexible | Apr 27 02:38 |
| jose_X | to make it efficient, we'd need to patch some things and basically help design for this.. also, people would have to start building these recipes | Apr 27 02:38 |
| jose_X | think of a large source base at the user PC | Apr 27 02:38 |
| jose_X | from it you can construct fedora v.X or ubuntu v.y or anything in between | Apr 27 02:39 |
| jose_X | all from saying with configurations would be current. | Apr 27 02:39 |
| jose_X | the system analyzes that and figures out all the other steps to take | Apr 27 02:39 |
| oiaohm | _Hicham_ I manual merged mandrake and Redhat in 1998 when things are not as standard as they are now. | Apr 27 02:39 |
| oiaohm | Including remaping common libs. | Apr 27 02:39 |
| oiaohm | That were in different locations. | Apr 27 02:40 |
| jose_X | all the careful consideration would go into building these.. and you can create as many exceptions as necessary (it's all about labels and interfaces) | Apr 27 02:40 |
| oiaohm | Merge of distributions is possiable just current day tools hard. | Apr 27 02:40 |
| _Hicham_ | oiaohm : mandrake diverged a lot from redhat | Apr 27 02:41 |
| jose_X | also, oiaohm, it's hard to take two implementations and match them (interoperate) | Apr 27 02:41 |
| jose_X | but its easier if you have the instructions of each as the starting point and these instructions share a common semantics | Apr 27 02:41 |
| oiaohm | There is more in comon between mandriva and redhat now than when I did it _Hicham_ | Apr 27 02:41 |
| jose_X | with exceptions here and there of course.. which can be managed in various ways (which are not ideal) | Apr 27 02:41 |
| oiaohm | Supprising lots of dlls even back then where compadible versions. | Apr 27 02:42 |
| oiaohm | opps .so | Apr 27 02:42 |
| oiaohm | So you could just use new version of the .so and everything worked. | Apr 27 02:42 |
| oiaohm | There is really not as much distribution difference as people make out. | Apr 27 02:43 |
| _Hicham_ | oiaohm : then u bypassed the package manager? | Apr 27 02:43 |
| oiaohm | Had custom prick. | Apr 27 02:43 |
| jose_X | i think he is talking about hacking them.. at least back then | Apr 27 02:43 |
| jose_X | custom.. right | Apr 27 02:43 |
| _Hicham_ | oiaohm : what about the difference between Debian and RedHat? | Apr 27 02:44 |
| oiaohm | Where I could map up that when application asked for this package it really was asking for this one. | Apr 27 02:44 |
| jose_X | and packagekit is a high level interface to abstract specific packagers right? | Apr 27 02:44 |
| oiaohm | And that included remaping tables. | Apr 27 02:44 |
| oiaohm | Mess. | Apr 27 02:44 |
| oiaohm | Debain and Redhat could be merged the same way. | Apr 27 02:44 |
| oiaohm | There is really nothing that specal. | Apr 27 02:45 |
| jose_X | yes,, part of the issue is in recognizing that when something says they need x, that they can use something else (maybe have the ports reconfigured) | Apr 27 02:45 |
| jose_X | you can leverage patching to fix many issues (pref the projects would incorp the patches) | Apr 27 02:45 |
| oiaohm | Its the complexity of building the conversion tables. | Apr 27 02:45 |
| jose_X | but all is made better if we standardize | Apr 27 02:45 |
| jose_X | projects don't reveal many of these issues | Apr 27 02:46 |
| jose_X | packagers figure them out | Apr 27 02:46 |
| oiaohm | Back then items like GTK was even in different directories. | Apr 27 02:46 |
| oiaohm | and named differently. | Apr 27 02:46 |
| oiaohm | These days it would not be as painful. | Apr 27 02:46 |
| jose_X | "packagers figure them out" meaning the people not the sw | Apr 27 02:47 |
| oiaohm | like libgtk-mdk-1.2 | Apr 27 02:47 |
| jose_X | manually | Apr 27 02:47 |
| oiaohm | Yes applications did not link to gtk | Apr 27 02:47 |
| oiaohm | they linked to gtk-mdk | Apr 27 02:47 |
| _Hicham_ | wow | Apr 27 02:47 |
| oiaohm | Mad the process insanely nasty. | Apr 27 02:47 |
| _Hicham_ | how awful | Apr 27 02:48 |
| oiaohm | made | Apr 27 02:48 |
| _Hicham_ | gtk-mdk | Apr 27 02:48 |
| _Hicham_ | as if they own gtk | Apr 27 02:48 |
| _Hicham_ | how insane | Apr 27 02:48 |
| oiaohm | Can you now see why I say not that bad today. | Apr 27 02:48 |
| _Hicham_ | but that means breaking package manager | Apr 27 02:54 |
| _Hicham_ | which is against distros philosophy | Apr 27 02:54 |
| oiaohm | How | Apr 27 02:54 |
| oiaohm | What I did was not breaking the package manager. | Apr 27 02:54 |
| oiaohm | It was putting a more functional package manager in. | Apr 27 02:55 |
| oiaohm | The package manager was still managing the package. | Apr 27 02:56 |
| oiaohm | s | Apr 27 02:56 |
| oiaohm | Just not taking them all from 1 source that is the difference. | Apr 27 02:56 |
| oiaohm | Idea of distrobution spliting has to exist is basically a myth. | Apr 27 02:58 |
| _Hicham_ | so u rewrited the package manager? | Apr 27 02:58 |
| jose_X | there is information being used to build packages that are known by people here and there but are not standardized.. so we keep reinventing the wheel.. of course, apps change all the time but a push to standardize some things should help out for the future. i don't think lsb covers any of this | Apr 27 02:58 |
| oiaohm | Altered rpm _Hicham_ lot of the fragments for package aliases end up main line. | Apr 27 03:01 |
| oiaohm | Parts for faking stuff did not end up mainline. | Apr 27 03:01 |
| oiaohm | Or supporting 2 100 percent incompadible package supply systems. | Apr 27 03:02 |
| jose_X | let's look at an example.. | Apr 27 03:07 |
| jose_X | an app specifies a bit of config info that designates a range of ports it can use (under circumstances x or versions y say) | Apr 27 03:07 |
| jose_X | the building system on the user's pc will know from this it can move apps around if ports might conflict | Apr 27 03:08 |
| oiaohm | Before I do my next attempt I am waiting on containers. | Apr 27 03:08 |
| jose_X | this particular prob is resolved already in some cases, but apply that to all sorts of resources that might overlap | Apr 27 03:08 |
| jose_X | then you don't need the debian and fedora folks to stay in sync | Apr 27 03:08 |
| jose_X | rather the apps specify their *needs* and the user can build an interoperable system | Apr 27 03:09 |
| jose_X | getting a deb and an rpm would be different because their might be a conflict which would have to be resolved manually and even then perhaps only if you had the source code which most people don't have | Apr 27 03:09 |
| oiaohm | With the network side. I am waiting on containers. | Apr 27 03:10 |
| oiaohm | Where you can issue applications to there own virtual network card. | Apr 27 03:11 |
| oiaohm | Again doable from loader. | Apr 27 03:11 |
| oiaohm | Lot of complexity to do what I did will be gone soon. | Apr 27 03:11 |
| jose_X | it can be tricky nailing down all the semantics properly. | Apr 27 03:11 |