| |||||||||||||
|
| |||||||||||||
Elektrified X.org releasedElektrified X.org releasedPosted Nov 30, 2004 18:23 UTC (Tue) by bk (guest, #25617)Parent article: Elektrified X.org released
In the project's own words, this is an effort to "leverage" technologies to assist "ISVs" in deploying products. This is a roundabout way of trying to make Linux/Unix more accessible to the proprietary software market.
I have absolutely zero interest in making my systems: a) less Unix like, b) more complex to administer, and c) less free.
(Log in to post comments)
Elektrified X.org released Posted Nov 30, 2004 18:40 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
system-config-display can be considered a "ISV" for xorg configuration file. Not all ISV's sell proprietary software. Another example was Ximian Gnome..
Elektrified X.org released Posted Nov 30, 2004 18:50 UTC (Tue) by juanjux (guest, #11652) [Link] I don't think that are the only reasons. One important reason would be to make Unix systems easier to administer. Every time I hit a new config file with a new `cat /proc/urandom` format I've to study (or google a lot) to change a few parameters I certainly feel something is wrong, and I've been using Unix for 10 years (not much for uber-guru standarts, I know).
Elektrified X.org released Posted Nov 30, 2004 18:54 UTC (Tue) by tzafrir (subscriber, #11501) [Link] Do you want to claim that Linux should stirve to be inaccessible to propritary applications?
Elektra allows some cool stuff at the distro level. You can have a separate {rpm|deb} package of a certain configuration variant for a specific software.
Remming out a whole subtree can be done by prefixing its name with a '.' . The usage of symlinks allows many cool tricks (try to emulate that with XML). You can give different permissions to different parts of your config file.
Is that worth the price of making the system more accessible to propietary software packages?
Elektrified X.org released Posted Nov 30, 2004 21:05 UTC (Tue) by evgeny (guest, #774) [Link] > The usage of symlinks allows many cool tricks (try to emulate that with XML)
Refer by ID?
Elektrified X.org released Posted Nov 30, 2004 23:06 UTC (Tue) by khim (subscriber, #9252) [Link] Not the same. You'll need application to deciper such references and use them. Doable - yes, convenient - no.
Elektrified X.org released Posted Dec 1, 2004 10:26 UTC (Wed) by evgeny (guest, #774) [Link] > You'll need application to deciper such references and use them. Doable - yes, convenient - no.
Expat and libxml can do this. And, BTW, what d'ya'think kernel is doing when resolving symlinks?
Elektrified X.org released Posted Dec 1, 2004 17:51 UTC (Wed) by tzafrir (subscriber, #11501) [Link] Who should keep the whole XML file in the memory?
Now what about caching those small changes?
Elektrified X.org released Posted Dec 1, 2004 20:22 UTC (Wed) by evgeny (guest, #774) [Link] > Who should keep the whole XML file in the memory?
1. Which is the "whole XML file"?
2. There is no need to keep the "whole XML" (whatever it means) in memory. There are alternative methods of parsing XML, e.g. SAX.
3. You probably should argue with another person anyway. My suggestion was to use an RDBMS, not XML file(s). I did say an XML-based DB (notice the word _database_ - I never meant plain XML files, especially not one huge file) could be used as well, in principle.
> Now what about caching those small changes?
Same here.
Elektrified X.org released Posted Dec 2, 2004 23:15 UTC (Thu) by tzafrir (subscriber, #11501) [Link] > > Who should keep the whole XML file in the memory?
Any software that needs to resolve IDs to nodes.
Elektrified X.org released Posted Dec 3, 2004 20:27 UTC (Fri) by evgeny (guest, #774) [Link] > > > Who should keep the whole XML file in the memory?
> Any software that needs to resolve IDs to nodes.
So do you say the kernel keeps the whole inode table/whatever in memory? And why memory requirements are different than that for similar task for a filesystem?
|
|
||||||||||||