On Tue, 30 Sep 2014 00:41:59 -0500 Doug Newgard <scimmi...@outlook.com> wrote:
> > > ---------------------------------------- > > Date: Tue, 30 Sep 2014 15:08:04 +1000 > > From: onef...@gmail.com > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] libeeze.so: undefined reference to > >`udev_device_set_sysattr_value' > > > > On Mon, 29 Sep 2014 23:28:53 -0500 Doug Newgard > ><scimmi...@outlook.com> wrote: > > > > > > Date: Tue, 30 Sep 2014 14:07:52 +1000 > > > > From: onef...@gmail.com > > > > To: enlightenment-devel@lists.sourceforge.net > > > > Subject: Re: [E-devel] libeeze.so: undefined reference to > > > >`udev_device_set_sysattr_value' > > > > > > > > On Tue, 30 Sep 2014 13:19:20 +0930 Graham Gower > > > > <graham.go...@gmail.com> wrote: > > > > > > > >> On 30 September 2014 11:37, Doug Newgard > ><scimmi...@outlook.com> > >> wrote: > > > >>> If you're entire system is that old, I'm sure EFL from 2.5 > >years > >>> ago will run just fine as well. > > > > > > > > Actually, EFL from 2.5 years ago was just as bleeding edge at > >the > >time as it is now, and still unlikely to run on stable > >systems from > >2.5 years ago, which did not use bleeding edge stuff > >from 2.5 years > > ago. :-P > > > > > > I don't know if you didn't understand my point or if you're just > > > ignoring it. If it takes 2.5 years for software to be considered > > > "stable", go back and install the various libs from 1.4 and you > > > should be great! Match the version of EFL to the rest of your > >system. > > You missed my point, the 2.5 year old EFL was bleeding edge 2.5 > >years ago, and still not good for a 2.5 year old stable system. > > Oh I understood your point perfectly, but it's totally irrelevant. > I'm not telling you to install 2.5 year old libs on a 5 year old > system, but 2.5 year old libs on a 2.5 year old system. Makes a > twisted kind of sense, doesn't it? Your own reasoning says that the > pre-1.7 libs are just now becoming "stable", so why not use them? > > > >>> Slackware 14.1, released Nov 2013. This is not old unless you're > > >>> accustomed to releasing a new version of your software every 2-3 > > >>> weeks. > > >> > > >> There's no arguing with those that insist every one use the most > > >> bleeding edge systems. You can't change their minds. It also > >seems >> useless trying to keep the large and every growing list of > > >>dependencies down to a manageable roar. > > > > > > It is indeed hard to argue with someone who insists on installing > > > bleeding edge software when everything else on their system is > > > ancient. Can you really not see that that's a recipe for disaster? > > > > "Stable", not "ancient". Get that through your head please. There > >are many many people that use stable systems, this is why such > >systems are provided by popular Linux distros. This is the point of > >the "long term" part of "long term stable", you can rely on them > >being stable over a long term of many years. > > I'll stick with "ancient", since it really describes the situation > better. "Stable" is not determined by time, "ancient" is and that > seems to be what's important in these distros that use ancient > software. > > > > > It's not a recipe for disaster, it's done all the time. Install a > > bleeding edge window manager, fine it shouldn't impact the rest of > >the system. The stable window manager the OS defaults to can be left > >alone and used as a backup for when the bleeding edge one falls > >over. Install a bleeding edge window manager that gratuitously > >depends on a bleeding edge version of an important sub system, yep > >THAT's a recipe for disaster, and exactly why it's not such a good > >idea for said window manager to depend on bleeding edge stuff. > >Installing a window manager that gratuitously depends on an > >important sub system that is itself graciously different from what > >some others do is even worse. > > The base OS is stable, but you can use a stable OS for development > >of bleeding edge software, or install bleeding edge bits. Lots of > > development companies do that. So long as you don't replace stable > > bits that are crucial to the OS in general with bleeding edge bits, > > it's all good. Things like udev and systemd are kinda crucial bits, > >or replace crucial bits in stable systems that didn't use systemd or > >udev in the first place. > > And this is the crux of the issue. You believe that all software must > be backwards compatible to the beginning of time, I do not. By the > time your current software gets into distros, the current version of > libs will as well. Having to add a bunch of logic for APIs that have > been obsolete for 5+ years does nothing except dirty up the code. > > Note that the lib in question here is already a year and a half old. > By the time EFL is shipped in a distro, it *should* already have the > necessary version. Calling this bleeding edge is really stretching > things beyond belief. Like I said, pointless arguing against the bleeding edge people, they just don't get it. sigh > > There was mention in this thread that eeze being just a thin layer > >was a bad idea, and it should have been a higher abstraction API. > >Then you wouldn't be depending on ONE bleeding edge important sub > >system that some people don't use for various reasons. Flexibility > >in this area is important. A bit less important for stuff that's not > >so crucial. > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS > Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download > White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with > EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS > Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download > White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with > EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
