On Tue, Mar 31, 2015 at 10:00 AM, Alessandro Selli <[email protected]> wrote: > Got the picture, thank you. I now wonder how did tzconfig find it's > way into an explicit mention in the exam's objectives.
Commonality and/or legacy, etc... Commonality because some distros might ship a utility. Legacy kinda like the POSIX "TZ" environment is still there, even though it is strongly recommended to _never_ set it at all. Not only are their conflicting, legacy TZ values, but even different UNIX distros disagree on how TZ could possible be modernized for Zoneinfo paths. Now "tzselect" is very much included in the upstream toolset last time I checked. > At a point I did notice Fedora, after a major upgrade, was showing at > each boot warnings that the separate /usr partition layout was no longer > supported and might have caused the system to fail starting up. However > that warning eventually disappeared and the /usr is still mounted on a > different partition on that machine now running Fedora21. Correct. The developers in the project, owning to their common Red Fedora background, tend to be overly cautious and will throw out warnings and deprecation notices, even if things work without any issue. It's why they are very hesitant to add various file system support, or mark it as unstable, etc... as well. > I was told they backpedalled from their initial plans to prohibit this > filesystem > layout out of pressure from community users/sysadmins. But what does Fedora really "prohibit" other than things that cause indemnification issues? It's not so much that it "prohibits" anything but, more or less, recommends or otherwise warns of possible issues and combinations that might not be tested. In reality, the Python stack (Anaconda, systemd, YUM, etc...) toolset does a phenominal job of dealing with upgrades, compared to a lot of other distros out there. If you've ever been through the code, or had Fedora installed alongside Ubuntu (even LTS), this readily becomes apparent. Most people assume otherwise, because Fedora doesn't ship or offer any components that have indemnification issues, not even post-install (one has to manually hit RPM Fusion/Livna), but as far as various subsystem/upgrade solutions, it works very well in my experience. SIDE NOTE: I'm biased right now because I'm fighting the infamous Ubuntu dmraid v. mdraid detail, even though I can completely unload dmraid and manually install mdraid in the install run-time, I cannot get its dracut to create an usable mdraid. This has already caused more than one rebuild in Fedora when I've dual-booted (as dmraid doesn't support rebuilding and some other, meta-tracking). I also have some driver and other userspace support issues with my notebook in Ubuntu that aren't issues in Fedora, and I've used the Fedora configuration (setup by the stack during install or update) to address the Ubuntu issues that were not during install or update. Part of the reason I like running 2 distros, 1 distro usually has the configuration I need to fix the other (Fedora heavily as of late), although legacy, static tools (scripts) v. dynamic, real-time subsystems (*d) is preventing that more and more. > I can tell for sure Fedora21 does support, relative to the root one, a > separate /usr > that is both a RAID1 and a dmcrypt partition. Yes, it works in most cases. But I still recommend people not do it, or test, or have an use case for it, such as a stateless, remote, etc... /usr or portion of it. But that's another debate. Always keep in mind, Fedora tends to be very, very conservative with its warnings, including the common, "We've changed this, drastically, you've been warned" type comments. I don't know how many times people don't bother to read the Release, let alone deep Technical, Notes for a new version, and have gotten bitten by them. > I guess you do not mean just the systemd-related commands, right? Define "systemd"? Indirectly, the whole philosophy behind Fedora changes related to the *d solutions have resulted in most developers taking a hard look at all the "one-offs" and other things, including separate and/or even redundant information in /etc/sysconfig/ and elsewhere, and saying, "why are we adding something else?" The direct result, regardless of systend or not, has been a number of *ctl programs replacing the system-config-* utilities, and dropping a lot of the one-offs. E.g., timedatectl is just one of the new *ctl solutions. This is separate, although related, to the various default or optional, lightweight libraries and/or services one can use with the *d set for various time inquiries, protocols, etc... as well. People commonly call this systemd, but it's not always systemd, sometimes not even part of the extended project (although timedatectl is). At some point, given their popularity, even outside of the full systemd adoption, LPI will have to take a hard look at them. I.e., people are complaining about the systemd project "absorbing" other projects and allegedly making them "monolithic," when that is anything but the sort. Most are original, new developments and do not require systemd at all. Yes, one has to download the systemd project's release to get various components, but many are very much "segmented" and not so "monolithic." In fact, that's no different than a lot of Upstream projects where only portions, even a subset, are built and used, and the rest not. But it's often easier for people to just call it "systemd," despite people like myself saying "*d" and "*ctl" to differentiate. I also do it because people refuse to believe systemd is anything but monolithic, but that's another debate. SIDE NOTE: It is funny to go back through the history of Linux and note similar complaints, only for everyone to agree that the new components are better, and eventually adopt them. The same is happening with a lot of *d and *ctl solutions, even if the "core" systemd dynamic engine is not utilized. -- bjs -- Bryan J Smith - http://www.linkedin.com/in/bjsmith _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
