On 06/24/2014 11:54 AM, Carlos E. R. wrote:
It is just up to the system administrator to decide if HE wants /tmp to be a directory in "/", a separate disk partition, or tmpfs. HE decides, based on what he is going to use the machine for.
We've got many people saying what they do, what they need, and a few with an absolutist attitude saying what /tmp should be. This isn't like buying a car where GM decides (limited by government regulations) what you should have and offers a few meaningless 'options' like colour and and trim and transmission (if you are lucky). And its not s if you can change the engine size or the gearbox ratios. But the whole point of open source is that you CAN. Yes, its an absolute that few take but we've seen recently discussions about file system choices, boot loader choices and Linda makes it very clear that even inird is a choice. Its one reason I get fed up with the people who think that KDE4 or systemd is a fascist conspiracy. That you can't do certain mix-and-match combinations with some distributions isn't the point. I can't fit a full size refrigerator in the trunk of my Buick (though I could in my Volvo wagon!). But the real point is the one Carlos is making. You have an incredible amount for flexibility and control. Rather than bitching about the immediate past (and all to often in ignorance of the more distance past since change has been persistent), learn the new. Its the ability to keep learning that keeps you young :-) I roll my eyes whenever I hear to myth about systemd being for a faster boot. Its about system management, and the booting is just part of that. Systemd implements with its 'units' what amounts to a DECLARATIVE rather than a _procedural_ language. Declarative programming is when you write your code in such a way that it describes what you want to do, and not how you want to do it. If you, for example, view a compiler as an 'expert system' on code production, then this is a good approach as the computer - systemd - know more about what else is going on. The important this is that a declarative approach is context-independent. Since such systems only declare what the ultimate goal is, but not the intermediary steps to reach that goal, the same program can be used in different contexts. This is hard to do with imperative programs, because they often depend on the context (e.g. Hidden state). An example here might be the contrast with re-running one of the sysvinit scripts _after_ boot or a state change. The result could be inappropriate since it was not run as part of a sequence of scripts. I keep saying 'context is everything' and that phrase has a lot of implications. Many human actions, programming included, are concerned with just a single matter and don't consider the side effects of the 'emergent properties' or the 'implied space'. See also http://www.forbes.com/sites/danwoods/2013/04/17/why-adopting-the-declarative... I found the reference to Puppet interesting. <quote> Most complex computing systems are controlled by various levels of configuration files. These files are the equivalent of the controls on an airplane dashboard. But while a typical cockpit may have a hundred or so switches, a single Linux server has hundreds of config files with thousands of controls. When you add networking equipment, firewalls, storage area networks, intrusion detection systems, and many other types of devices, the number of files to maintain skyrockets. </quote> Of course coming from a background of using YACC/LEX as a 'swiss army knife' for many application specific situation I'm biased toward the declarative approach. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org