I feel most productive, as well as a lot of other things, in Linux.
For me, It's not the OS (kernel) but the feel of my workspace. it's more fair to compare GNOME or KDE with Mac/Windows than Linux, since my Linux is very bare and decidedly not KDE.
Of course, my requirements are simple: A good text editor, a command line for recompiling or executing utility commands and gathering tidbits of information (man 3 whatever) and that's it. Having few flashy distractions helps.
I could be just as produtive in Windows (cygwin + windows port of emacs) or OS X or Solaris or *BSD. My most productive environment is emacs, a couple xterms and a web browser (for when man lets me down). Hell, I could even just use 6 VTs if I can have more than 80x25.
On Windows I find there are too many hard-to-disable distractions (plus, on XP even if you disable stuff there are a ton of things slowing the system down). Disabling eye candy on OS X was not a design goal, so I find it hard to concentrate (plus, that damn command key keeps oopsing me). Any other kind of *nix (with bash, please) is perfectly all right by me, since you can disable 99% of everything if you want to.
Of course, what some users need to be productive is different. Some people need Photoshop or a word processor with good layout capabilities. Or maybe fancy wizards and I-see-you're-bored-would-you-like-to-play-a-game? dectection. Windows and the Macintosh are better for those at the moment, but probably not for long. Eventually Linux will be as good a desktop for those types as it already is for me, and then everyone will automatically think "Linux" and we wont need polls like this.
It's not got to be that complicated. It's simply a transaction layer. You tell me in what ever language you want how to do something, and I'll translate it to another language so that another GUI can do what you asked. If done right, it wouldn't require ANY recompilation of the programs existing today, and would simply reduce the amount of libraries needed in memory. Of course, the trade off is translation time, which can be a lot or a little depending on how alike the two windowing systems are.
Okay, great!!!! Let's do it. But I want a NEW fantastic widget which is absolutely essential (no, really) but which isn't supported by the lower-level GUI you're translating for. So, what do I do? I can:
A) Do without. Sometimes you can, sometimes you can't This time I can't. B) Go ask the developers to add this feature to the lower level GUI. They wont, because it's bloat, or it breaks the clean API, or maybe they will but I have to wait for the next stable release for my application to work. C) Extend the lower level myself. Whoo boy! That's dangerous ground. And anyway, do I evn know the language it's written in? I'm using ++Cool Widgets! because I like the API, I'm not going to go muck with the C backend it all gets translated into. No way. D) Implement my own widget directly into ++Cool Widgets! This is what will happen.
Okay, so NOW my example is like xlibs. Xlibs keeps it so simple everything has to be an extension on top, they don't even try to make you do it their way. But, also, my example is like Win32, where MS themselves implement new widgets by hand and at a higher layer all the time, because they have to do it that way. Then you need the new DLLs from Office if you want to use the new widgets Office adds. Normally MS adds these DLLs into the next release/service pack of Windows just to keep things interesting.
Congratulations! You have just re-invented Xlibs! The problem is that if you limit your widget set to something that can be conformable to xlibs, you limit the areas you can improve. And if you expand xlibs to provide more stuff... whoops, you've just broken a stable API everyone uses!
You can have an API-soup low level lib which higher levels libs write to. You can have a simple low level lib which higher levels libs write to but don't try to expand upon. You can have a simple low level lib which higher levels libs write to and expand in massive duplication of effort and look incompatibility.
I was trying to start learning Linux on a 300MHz K6-2 with less than supported hardware(ISA 16-bit soundcard-ugh!)
Tch, kids these days think they have it rough. I ad to get an ISA *modem* working back with a 2.2 kernel (this is when isapnptools was not in the kernel, mind you) and I had no manuals and no money for manuals or books. Just a Red Hat CD and a lot of determination. If it weren't for my dial-up connection on a nearby win98 to look up docs for me I'd never have succeeded.
This was where I fell in love with Linux; I loved the documentation. Even then it was not good, but it was filled with the nectar of life: Details! Lots and LOTS of little nitty gritty little details. I could tell I was getting close to answers when the HOWTOs and manuals started to say things that were recognizably wrong. Ahh, learning!
I think I learned more about networking from the NET3-HOWTO than I have from anywhere else.
... of course, having more than one implementation pretty much guarantees that you have good interoperation or none at all. For example, there are many MTAs, they seem to work just fine together.
So why not have the people working on Hurd work on something new instead, or work on improving Linux?
This is a common question. Why work on PROJECT-A when it's just duplication of effort, why not instead work on PROJECT-B?
The answer to this one is that FOSS developers are not assets which you can assign. You can have X number of people working on Linux and Y number of people working on HURD, or you can have X number of people working on Linux and zero people working on HURD. Which is better? The former. Killing HURD will never give you X+Y number of people working on Linux.
It took Linux a long time to be recognized as a viable alternative to other Unices. I don't think this can be easily done again.
Linux will die soon. Within ten years nobody will run it, probably within five years. What Linux is doing that no one else has been able to do is commoditize the OS kernel. The future most popular operating system will not be Linux, but the end user wont be able to tell. If you take Red Hat, swap out the Linux kernel, and swap in (say) the NetBSD kernel, what has changed? From my mother's perspective, nada. All of her software still runs.
Linux will break the monopoly strangehold on the OS market. Then, because it isn't the perfect solution, it will be marginalized by better kernels and systems... almost all of which will be FOSS and all of which will re-use quickly ported FOSS software.
The people who have to watch out are the driver writers, that's all. All higher-level libraries will be ported as needed to all new systems.
Work on Linux alternatives is not harmful or fruitless. Maybe the HURD will (once, if ever, complete) be so technically superior to anything else that people will switch in droves. Switching will be easy, and few will mourn Linux, just as few mourned modutils when module-init-tools replaced it.
The OS kernel will, in the future, be just a module.
The reason MS can't beat Google in searching is simple: Microsoft is a third-rate technology company. They can do generic software opretty well, but anything truly complex like search is beyond them..
Anecdotal evidence: Since MSN search launched and has a Near Me button, Google moved Location search to the front page. Being a fair-minded kind of guy, I decided to compare them. I went to each, filled in my location, and did the quintessential local search: pizza. The results:
On Google the first four were real Pizza places near me. Two I use frequently, one I didn't even know existed. After that were more Pizza places near me as the crow flies, but very far by road (and bridge). A map was provided, centered on my location, depicting each of the locations. The address of each shop was included in the results.
On MSN, the titles of the first four hits were (in order!) as follows:
A local church directory listing a weekly activity which included free pizza.
A link to "Pizz Today" boards, and to a forum having to do with cheese prices.
The Nerhood amily web log. Appearantly someone in that family recently had pizza!
The page in my county's Tourism web site listing things to do here, which happens to includes going to a name local pizza place.
If I am anyone, I already know of and probably use Google search. They have the mindshare already. If I try MSN search and get results of this... quality, then I will immediately laugh and go back to Google. MSN... well, it's a nice search engine for 1998.
This is what I was talking about: People proposing that Linux be forcibly converted to app bundles are thinking "Linux is the new MacOS, everybody's desktop OS." The reality is that Linux cannot be a desktop OS only, it must be *all things to all people*. If you break its usefulness as a corporate desktop or as a server, than you've screwed up.
Sure, you could have seperate distributions for seperate user bases. If you think that's a good idea, go help with GoboLinux. In the mean time, stop trying to insist that app bundles are god for servers.
My Mac is MY computer, and I want to be able to organize things MY way, so the computer makes sense to me.
So run Mac OS 9. Mac OS X has rules you just don't/can't violate, just as Linux distros do.
Application bundles pose some technical challenges, concerns about shared libraries, etc. But the point is to figure out the best user experience, and let the geniuses work out the software details to make that happen.
Well it's all about how you define "user" isn't it? When I think user I think me, the user of my computer--and I strongly dislike app bundles. When you think user you think yourself but probably also think the proverbial granma, whereas I think hacker.
At the moment, I believe the Linux userbase largely fits my definition. If you can find a way to solve the negatives of app bundles, or to make a new system that offers similar benefits while not imposing as nasty side effects, then I'm sure you'll find many interested users.
Are you a GNOMEite? At a fundamental level computers are different for different levels of users. The thing which improves usabilty is a smooth transition from level to level.
Don't think that having an "Expert mode" UI is inherently bad, it just happened to be a bad idea for a certain file manager.
App bundles are okay for some people, but they are not the holy grail most seem to be touting them as here.
Sure, library updates are a problem. But that isn't why app bundles are a bad idea.
App bundles are a bad idea because they solve more problems than exist, and cause more problems than they solve.
For every definciency in the way UNIX traditionally works there is a workaround. The problems with the system are well known. The system has a very few flaws... but one of those flaws is really glaring to desktop users, especially Mac heads.
Because they see only what is broken and not what isn't they propose a Mac-like system. The app bundle idea isn't new and it isn't bad, but it does not solve the right problems. It solves one, perhaps two, problems, mostly for one class of users. And, while those problems are being solved, it creates dozens of difficult problems for several classes of users.
The people who have the new problems tend to be the uber-admins, the developers, and the people who create distros. Those people do not adopt app bundles because the "sense" that they make is non, from thei point of view. In a admin-centric cost-benefit analysis app bundles nearly always lose to the *nix way.
If someone could figure out a way to solve the problem that app bundles solve for desktop users without screwing over the admins and developers, distros would convert in droves. Since the existing solution is to "Screw different people, screw more people, just unscrew ME!" no one really feels obliged to comply.
No, not Mockup. Mockup might be fun after a while, if it tkaes off, which it wont. Elektra is a good thing.
The Elektra guys need to go have a chat with the Gobolinux guys. These two groups were MADE for each other.
What Elektra does is not new or exciting, it's old and simple. This is a "Finally! At last!" more than a "Oooh, shiney!" They are attempting, once gain, to sanify/etc. They're doing it without requiring every program to be changed at once. They're doing it without assuming everything will be world writable. They're doing it without discarding command line configuration editing.
Everything is a text file, so it's easy to edit by hand. Everything is regular, so it's easy to build GUIs for editing it automatically. What they're saying meshes really well with what Hans Reiser has said about filesystems and namespaces, and that guy knows his stuff.
They absolutely do not add anything fancy, which is really good.
I'd like to see some few expansions of the idea:
The ability of they command line tool (kdb edit) to return editable text in more formats than just XML; specifically, for it to use YAML. The biggest drawback to spliting config data into multiple files is the difficulty in editing many related options, which their XML idea nicely solves... but since't it's hell to edit XML but fairly easy to edit YAML, a YAML mode would be nice.
A renaming of their tool, maybe to cfg or conf or something pretentious like that. That way the directory could be/etc/cfg, and perhaps eventually just/cfg if the idea takes off.
Lose the UTF-8 requirements. While nice, it does not mesh well with command line tools, and should be left to the application anyway.
As another poster mentioned, remove comments from the config files themselves. I propose appending a # prefix to files which are comments for files with the same name, e.g.: system/sw/Foo/firstrun and then the comment: system/sw/Foo/#firstrun
Which is semantically very understandable and does not too greatly reduce the available symbols for key names.
As another poster said, make using the library optional, since it's almost is as things stand. There is value to the library for application developers, for consistency and convenience, but it should not be in any way necessary.
The greatest value Elektra adds is "just" sane namespace management, although there is nothing paltry about that.
Aside from that, Elektra suffers from the exact same problems as the registry. The main problem with this sort of hierarchical key/value database -- and that's what it is -- is that it's just a mass of data, inherently structured but semantically shapeless; the context of any key/value pair is the parent node, and the context of any node is its parent node. As such, it's no better or worse than a bunch of files in a file system.
Did you RTFA? Elektra IS just a bunch of files in the filesystem. WHat elektra provides over just random files is: A standard C API for accessing the files, for those who don't like doing so directly, and a standard naming scheme for the hierarchy of files, something/etc does not have across distros. They also go on a bit about effectively standardizing file formats, but I don't consider that to be such a virtue.
Don't get me wrong, I went in very not-thrilled with yet another "Let's make a registry for Linux!!" effort, but I came out more or less pleased. The elektra project people seem to get what it is that makes/etc so well liked and have gone to lengths to preserve as much as possible. I'll be curious to see what they can get done. Maybe a whole rebuilt-for-elektra distro will be forthcoming; maybe GoboLinux will adopt it first. It will be fun to watch.
Instead of a single monolithic database, I suggest an aggregated database. Install a piece of software Foo into/usr and its database goes into/etc/foo, then mount it logically under a well-known named node. Thus the "registry", or whatever you call it, is the product of all known sub-registries. Delete an app, and its database can go away as well.
You didn't RTFA? Elektra seems to solve this with their naming scheme, such that system/sw/Foo always contains everything you can change about Foo. I am not an expert in elektra, but from reading their page that's what it looks like to me.
Fortunately, some people "get" it; the relational nature of RDF triples is one such recent example, and I would rather see RDF (although not necessarily its XML syntax) adopted, because it's such a simple, elegant, extensible system.
Do I rush to get home and catch my favorite show? Nah, no need. I can obey the speed limits, arrive late, download the episode, and then watch it.
I would gladly pay a reasonable monthly fee to have DRM-free legal downloads of TV episodes that have aired during the previous two weeks. Just charge me what they charge me for cable TV so I can drop that, and pass a percentage of the fee back to the network which would have aired it in my area in lieu of ad revenue (which is wasted on me anyway).
Just do what I do: Focus so totally on what you're doing that the world falls away and people have to say your name sharply, twice, before you look up and utter a vague "Wha...?"
Slashdot Mirror
if you need text files with a structure you probably want YAML and not XML.
I feel most productive, as well as a lot of other things, in Linux.
For me, It's not the OS (kernel) but the feel of my workspace. it's more fair to compare GNOME or KDE with Mac/Windows than Linux, since my Linux is very bare and decidedly not KDE.
Of course, my requirements are simple: A good text editor, a command line for recompiling or executing utility commands and gathering tidbits of information (man 3 whatever) and that's it. Having few flashy distractions helps.
I could be just as produtive in Windows (cygwin + windows port of emacs) or OS X or Solaris or *BSD. My most productive environment is emacs, a couple xterms and a web browser (for when man lets me down). Hell, I could even just use 6 VTs if I can have more than 80x25.
On Windows I find there are too many hard-to-disable distractions (plus, on XP even if you disable stuff there are a ton of things slowing the system down). Disabling eye candy on OS X was not a design goal, so I find it hard to concentrate (plus, that damn command key keeps oopsing me). Any other kind of *nix (with bash, please) is perfectly all right by me, since you can disable 99% of everything if you want to.
Of course, what some users need to be productive is different. Some people need Photoshop or a word processor with good layout capabilities. Or maybe fancy wizards and I-see-you're-bored-would-you-like-to-play-a-game? dectection. Windows and the Macintosh are better for those at the moment, but probably not for long. Eventually Linux will be as good a desktop for those types as it already is for me, and then everyone will automatically think "Linux" and we wont need polls like this.
might be propitary, but so be it. Easy to use and works...I'll pay for that!
Paying for easy is fine, I'm happy to do that. Sacrificng freedom for ease... that I am not willing to do.
okay, but apt still wins vs. yum. I've notr tried urpmi or yast2, but yum is a jok compared to apt.
It's not got to be that complicated. It's simply a transaction layer. You tell me in what ever language you want how to do something, and I'll translate it to another language so that another GUI can do what you asked. If done right, it wouldn't require ANY recompilation of the programs existing today, and would simply reduce the amount of libraries needed in memory. Of course, the trade off is translation time, which can be a lot or a little depending on how alike the two windowing systems are.
Okay, great!!!! Let's do it. But I want a NEW fantastic widget which is absolutely essential (no, really) but which isn't supported by the lower-level GUI you're translating for. So, what do I do? I can:
A) Do without. Sometimes you can, sometimes you can't This time I can't.
B) Go ask the developers to add this feature to the lower level GUI. They wont, because it's bloat, or it breaks the clean API, or maybe they will but I have to wait for the next stable release for my application to work.
C) Extend the lower level myself. Whoo boy! That's dangerous ground. And anyway, do I evn know the language it's written in? I'm using ++Cool Widgets! because I like the API, I'm not going to go muck with the C backend it all gets translated into. No way.
D) Implement my own widget directly into ++Cool Widgets! This is what will happen.
Okay, so NOW my example is like xlibs. Xlibs keeps it so simple everything has to be an extension on top, they don't even try to make you do it their way. But, also, my example is like Win32, where MS themselves implement new widgets by hand and at a higher layer all the time, because they have to do it that way. Then you need the new DLLs from Office if you want to use the new widgets Office adds. Normally MS adds these DLLs into the next release/service pack of Windows just to keep things interesting.
Congratulations! You have just re-invented Xlibs! The problem is that if you limit your widget set to something that can be conformable to xlibs, you limit the areas you can improve. And if you expand xlibs to provide more stuff... whoops, you've just broken a stable API everyone uses!
You can have an API-soup low level lib which higher levels libs write to.
You can have a simple low level lib which higher levels libs write to but don't try to expand upon.
You can have a simple low level lib which higher levels libs write to and expand in massive duplication of effort and look incompatibility.
It's very hard to have anything else.
Because the kernel should be irrelevant.
Ever use LiteStep? What do you say to LiteStep users? Do you say "Why not just use NeXT?"? "Why not just use AfterStep or WindowMaker?"?
Do you like commercial games?
Do you see my points?
I was trying to start learning Linux on a 300MHz K6-2 with less than supported hardware(ISA 16-bit soundcard-ugh!)
Tch, kids these days think they have it rough. I ad to get an ISA *modem* working back with a 2.2 kernel (this is when isapnptools was not in the kernel, mind you) and I had no manuals and no money for manuals or books. Just a Red Hat CD and a lot of determination. If it weren't for my dial-up connection on a nearby win98 to look up docs for me I'd never have succeeded.
This was where I fell in love with Linux; I loved the documentation. Even then it was not good, but it was filled with the nectar of life: Details! Lots and LOTS of little nitty gritty little details. I could tell I was getting close to answers when the HOWTOs and manuals started to say things that were recognizably wrong. Ahh, learning!
I think I learned more about networking from the NET3-HOWTO than I have from anywhere else.
... of course, having more than one implementation pretty much guarantees that you have good interoperation or none at all. For example, there are many MTAs, they seem to work just fine together.
So why not have the people working on Hurd work on something new instead, or work on improving Linux?
This is a common question. Why work on PROJECT-A when it's just duplication of effort, why not instead work on PROJECT-B?
The answer to this one is that FOSS developers are not assets which you can assign. You can have X number of people working on Linux and Y number of people working on HURD, or you can have X number of people working on Linux and zero people working on HURD. Which is better? The former. Killing HURD will never give you X+Y number of people working on Linux.
It took Linux a long time to be recognized as a viable alternative to other Unices. I don't think this can be easily done again.
Linux will die soon. Within ten years nobody will run it, probably within five years. What Linux is doing that no one else has been able to do is commoditize the OS kernel. The future most popular operating system will not be Linux, but the end user wont be able to tell. If you take Red Hat, swap out the Linux kernel, and swap in (say) the NetBSD kernel, what has changed? From my mother's perspective, nada. All of her software still runs.
Linux will break the monopoly strangehold on the OS market. Then, because it isn't the perfect solution, it will be marginalized by better kernels and systems... almost all of which will be FOSS and all of which will re-use quickly ported FOSS software.
The people who have to watch out are the driver writers, that's all. All higher-level libraries will be ported as needed to all new systems.
Work on Linux alternatives is not harmful or fruitless. Maybe the HURD will (once, if ever, complete) be so technically superior to anything else that people will switch in droves. Switching will be easy, and few will mourn Linux, just as few mourned modutils when module-init-tools replaced it.
The OS kernel will, in the future, be just a module.
anybody see the gruntmaster 6000 episode of dilbert?
Anyone NOT see that episode of Dilbert?
Thought so.
I have not read the article.
The reason MS can't beat Google in searching is simple: Microsoft is a third-rate technology company. They can do generic software opretty well, but anything truly complex like search is beyond them..
Anecdotal evidence: Since MSN search launched and has a Near Me button, Google moved Location search to the front page. Being a fair-minded kind of guy, I decided to compare them. I went to each, filled in my location, and did the quintessential local search: pizza. The results:
On Google the first four were real Pizza places near me. Two I use frequently, one I didn't even know existed. After that were more Pizza places near me as the crow flies, but very far by road (and bridge). A map was provided, centered on my location, depicting each of the locations. The address of each shop was included in the results.
On MSN, the titles of the first four hits were (in order!) as follows:
A local church directory listing a weekly activity which included free pizza.
A link to "Pizz Today" boards, and to a forum having to do with cheese prices.
The Nerhood amily web log. Appearantly someone in that family recently had pizza!
The page in my county's Tourism web site listing things to do here, which happens to includes going to a name local pizza place.
If I am anyone, I already know of and probably use Google search. They have the mindshare already. If I try MSN search and get results of this... quality, then I will immediately laugh and go back to Google. MSN... well, it's a nice search engine for 1998.
I'm still laughing.
Fans *mostly* don't dub. There is a Sailr Moon fandub going on. Yes, gah, I know.
This is what I was talking about: People proposing that Linux be forcibly converted to app bundles are thinking "Linux is the new MacOS, everybody's desktop OS." The reality is that Linux cannot be a desktop OS only, it must be *all things to all people*. If you break its usefulness as a corporate desktop or as a server, than you've screwed up.
Sure, you could have seperate distributions for seperate user bases. If you think that's a good idea, go help with GoboLinux. In the mean time, stop trying to insist that app bundles are god for servers.
My Mac is MY computer, and I want to be able to organize things MY way, so the computer makes sense to me.
So run Mac OS 9. Mac OS X has rules you just don't/can't violate, just as Linux distros do.
Application bundles pose some technical challenges, concerns about shared libraries, etc. But the point is to figure out the best user experience, and let the geniuses work out the software details to make that happen.
Well it's all about how you define "user" isn't it? When I think user I think me, the user of my computer--and I strongly dislike app bundles. When you think user you think yourself but probably also think the proverbial granma, whereas I think hacker.
At the moment, I believe the Linux userbase largely fits my definition. If you can find a way to solve the negatives of app bundles, or to make a new system that offers similar benefits while not imposing as nasty side effects, then I'm sure you'll find many interested users.
In the mean time, back off.
No.
Are you a GNOMEite? At a fundamental level computers are different for different levels of users. The thing which improves usabilty is a smooth transition from level to level.
Don't think that having an "Expert mode" UI is inherently bad, it just happened to be a bad idea for a certain file manager.
App bundles are okay for some people, but they are not the holy grail most seem to be touting them as here.
Sure, library updates are a problem. But that isn't why app bundles are a bad idea.
App bundles are a bad idea because they solve more problems than exist, and cause more problems than they solve.
For every definciency in the way UNIX traditionally works there is a workaround. The problems with the system are well known. The system has a very few flaws... but one of those flaws is really glaring to desktop users, especially Mac heads.
Because they see only what is broken and not what isn't they propose a Mac-like system. The app bundle idea isn't new and it isn't bad, but it does not solve the right problems. It solves one, perhaps two, problems, mostly for one class of users. And, while those problems are being solved, it creates dozens of difficult problems for several classes of users.
The people who have the new problems tend to be the uber-admins, the developers, and the people who create distros. Those people do not adopt app bundles because the "sense" that they make is non, from thei point of view. In a admin-centric cost-benefit analysis app bundles nearly always lose to the *nix way.
If someone could figure out a way to solve the problem that app bundles solve for desktop users without screwing over the admins and developers, distros would convert in droves. Since the existing solution is to "Screw different people, screw more people, just unscrew ME!" no one really feels obliged to comply.
This is a very good thing.
/etc. They're doing it without requiring every program to be changed at once. They're doing it without assuming everything will be world writable. They're doing it without discarding command line configuration editing.
/etc/cfg, and perhaps eventually just /cfg if the idea takes off.
No, not Mockup. Mockup might be fun after a while, if it tkaes off, which it wont. Elektra is a good thing.
The Elektra guys need to go have a chat with the Gobolinux guys. These two groups were MADE for each other.
What Elektra does is not new or exciting, it's old and simple. This is a "Finally! At last!" more than a "Oooh, shiney!" They are attempting, once gain, to sanify
Everything is a text file, so it's easy to edit by hand. Everything is regular, so it's easy to build GUIs for editing it automatically. What they're saying meshes really well with what Hans Reiser has said about filesystems and namespaces, and that guy knows his stuff.
They absolutely do not add anything fancy, which is really good.
I'd like to see some few expansions of the idea:
The ability of they command line tool (kdb edit) to return editable text in more formats than just XML; specifically, for it to use YAML. The biggest drawback to spliting config data into multiple files is the difficulty in editing many related options, which their XML idea nicely solves... but since't it's hell to edit XML but fairly easy to edit YAML, a YAML mode would be nice.
A renaming of their tool, maybe to cfg or conf or something pretentious like that. That way the directory could be
Lose the UTF-8 requirements. While nice, it does not mesh well with command line tools, and should be left to the application anyway.
As another poster mentioned, remove comments from the config files themselves. I propose appending a # prefix to files which are comments for files with the same name, e.g.:
system/sw/Foo/firstrun
and then the comment:
system/sw/Foo/#firstrun
Which is semantically very understandable and does not too greatly reduce the available symbols for key names.
As another poster said, make using the library optional, since it's almost is as things stand. There is value to the library for application developers, for consistency and convenience, but it should not be in any way necessary.
The greatest value Elektra adds is "just" sane namespace management, although there is nothing paltry about that.
Aside from that, Elektra suffers from the exact same problems as the registry. The main problem with this sort of hierarchical key/value database -- and that's what it is -- is that it's just a mass of data, inherently structured but semantically shapeless; the context of any key/value pair is the parent node, and the context of any node is its parent node. As such, it's no better or worse than a bunch of files in a file system.
/etc does not have across distros. They also go on a bit about effectively standardizing file formats, but I don't consider that to be such a virtue.
/etc so well liked and have gone to lengths to preserve as much as possible. I'll be curious to see what they can get done. Maybe a whole rebuilt-for-elektra distro will be forthcoming; maybe GoboLinux will adopt it first. It will be fun to watch.
/usr and its database goes into /etc/foo, then mount it logically under a well-known named node. Thus the "registry", or whatever you call it, is the product of all known sub-registries. Delete an app, and its database can go away as well.
Did you RTFA? Elektra IS just a bunch of files in the filesystem. WHat elektra provides over just random files is: A standard C API for accessing the files, for those who don't like doing so directly, and a standard naming scheme for the hierarchy of files, something
Don't get me wrong, I went in very not-thrilled with yet another "Let's make a registry for Linux!!" effort, but I came out more or less pleased. The elektra project people seem to get what it is that makes
Instead of a single monolithic database, I suggest an aggregated database. Install a piece of software Foo into
You didn't RTFA? Elektra seems to solve this with their naming scheme, such that system/sw/Foo always contains everything you can change about Foo. I am not an expert in elektra, but from reading their page that's what it looks like to me.
Fortunately, some people "get" it; the relational nature of RDF triples is one such recent example, and I would rather see RDF (although not necessarily its XML syntax) adopted, because it's such a simple, elegant, extensible system.
Could you expand on that?
A big me too on timeshifting.
Do I rush to get home and catch my favorite show? Nah, no need. I can obey the speed limits, arrive late, download the episode, and then watch it.
I would gladly pay a reasonable monthly fee to have DRM-free legal downloads of TV episodes that have aired during the previous two weeks. Just charge me what they charge me for cable TV so I can drop that, and pass a percentage of the fee back to the network which would have aired it in my area in lieu of ad revenue (which is wasted on me anyway).
If you ask the GNOME guys they'll tell you that's what they're doing. They're wrong, of course, but at least they think that's what they're doing.
Just do what I do: Focus so totally on what you're doing that the world falls away and people have to say your name sharply, twice, before you look up and utter a vague "Wha...?"
See this post.
I'll bite: It makes a difference to me, personally. I would personally, deeply object to changing the name.
It appears that you are unfamiliar with mp2
Mad props to McVaffe! You know he's three people on OCRemix, right?