Systemd 197 released
| From: | Lennart Poettering <lennart-AT-poettering.net> | |
| To: | systemd Mailing List <systemd-devel-AT-lists.freedesktop.org> | |
| Subject: | [ANNOUNCE] systemd 197 | |
| Date: | Tue, 8 Jan 2013 03:14:48 +0100 | |
| Message-ID: | <20130108021448.GA30913@tango.0pointer.de> | |
| Archive‑link: | Article |
Heya, There's quite some cool new stuff in this release: http://www.freedesktop.org/software/systemd/systemd-197.t... CHANGES WITH 197: * Timer units now support calendar time events in addition to monotonic time events. That means you can now trigger a unit based on a calendar time specification such as "Thu,Fri 2013-*-1,5 11:12:13" which refers to 11:12:13 of the first or fifth day of any month of the year 2013, given that it is a thursday or friday. This brings timer event support considerably closer to cron's capabilities. For details on the supported calendar time specification language see systemd.time(7). * udev now supports a number of different naming policies for network interfaces for predictable names, and a combination of these policies is now the default. Please see this wiki document for details: http://www.freedesktop.org/wiki/Software/systemd/Predicta... * Auke Kok's bootchart implementation has been added to the systemd tree. It's an optional component that can graph the boot in quite some detail. It's one of the best bootchart implementations around and minimal in its code and dependencies. * nss-myhostname has been integrated into the systemd source tree. nss-myhostname guarantees that the local hostname always stays resolvable via NSS. It has been a weak requirement of systemd-hostnamed since a long time, and since its code is actually trivial we decided to just include it in systemd's source tree. It can be turned off with a configure switch. * The read-ahead logic is now capable of properly detecting whether a btrfs file system is on SSD or rotating media, in order to optimize the read-ahead scheme. Previously, it was only capable of detecting this on traditional file systems such as ext4. * In udev, additional device properties are now read from the IAB in addition to the OUI database. Also, Bluetooth company identities are attached to the devices as well. * In service files %U may be used as specifier that is replaced by the configured user name of the service. * nspawn may now be invoked without a controlling TTY. This makes it suitable for invocation as its own service. This may be used to set up a simple containerized server system using only core OS tools. * systemd and nspawn can now accept socket file descriptors when they are started for socket activation. This enables implementation of socket activated nspawn containers. i.e. think about autospawning an entire OS image when the first SSH or HTTP connection is received. We expect that similar functionality will also be added to libvirt-lxc eventually. * journalctl will now suppress ANSI color codes when presenting log data. * systemctl will no longer show control group information for a unit if a the control group is empty anyway. * logind can now automatically suspend/hibernate/shutdown the system on idle. * /etc/machine-info and hostnamed now also expose the chassis type of the system. This can be used to determine whether the local system is a laptop, desktop, handset or tablet. This information may either be configured by the user/vendor or is automatically determined from ACPI and DMI information if possible. * A number of PolicyKit actions are now bound together with "imply" rules. This should simplify creating UIs because many actions will now authenticate similar ones as well. * Unit files learnt a new condition ConditionACPower= which may be used to conditionalize a unit depending on whether an AC power source is connected or not, of whether the system is running on battery power. * systemctl gained a new "is-failed" verb that may be used in shell scripts and suchlike to check whether a specific unit is in the "failed" state. * The EnvironmentFile= setting in unit files now supports file globbing, and can hence be used to easily read a number of environment files at once. * systemd will no longer detect and recognize specific distributions. All distribution-specific #ifdeffery has been removed, systemd is now fully generic and distribution-agnostic. Effectively, not too much is lost as a lot of the code is still accessible via explicit configure switches. However, support for some distribution specific legacy configuration file formats has been dropped. We recommend distributions to simply adopt the configuration files everybody else uses now and convert the old configuration from packaging scripts. Most distributions already did that. If that's not possible or desirable, distributions are welcome to forward port the specific pieces of code locally from the git history. * When logging a message about a unit systemd will now always log the unit name in the message meta data. * localectl will now also discover system locale data that is not stored in locale archives, but directly unpacked. * logind will no longer unconditionally use framebuffer devices as seat masters, i.e. as devices that are required to be existing before a seat is considered preset. Instead, it will now look for all devices that are tagged as "seat-master" in udev. By default framebuffer devices will be marked as such, but depending on local systems other devices might be marked as well. This may be used to integrate graphics cards using closed source drivers (such as NVidia ones) more nicely into logind. Note however, that we recommend using the open source NVidia drivers instead, and no udev rules for the closed-source drivers will be shipped from us upstream. Contributions from: Adam Williamson, Alessandro Crismani, Auke Kok, Colin Walters, Daniel Wallace, Dave Reisner, David Herrmann, David Strauss, Dimitrios Apostolou, Eelco Dolstra, Eric Benoit, Giovanni Campagna, Hannes Reinecke, Henrik Grindal Bakken, Hermann Gausterer, Kay Sievers, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Marcel Holtmann, Martin Pitt, Matthew Monaco, Michael Biebl, Michael Terry, Michal Schmidt, Michal Sekletar, Michał Bartoszkiewicz, Oleg Samarin, Pekka Lundstrom, Philip Nilsson, Ramkumar Ramachandra, Richard Yao, Robert Millan, Sami Kerola, Shawn Landden, Thomas Hindoe Paaboel Andersen, Thomas Jarosch, Tollef Fog Heen, Tom Gundersen, Umut Tezduyar, Zbigniew Jędrzejewski-Szmek Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Posted Jan 8, 2013 19:37 UTC (Tue)
by cesarb (subscriber, #6266)
[Link] (20 responses)
The only wart seems to be that the USB interface names will change if they are moved to a different port. The rule based on the MAC address might avoid this problem, but the resulting names are very ugly.
Posted Jan 8, 2013 19:53 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (19 responses)
Ultimately we decided to just stick to the path-based naming for everything, since it would be weird to deviate only for USB for this, and given that none of the two options is clearly better than the other we think uniformity is a good thing to have.
You could see this from a different perspective: the new predictable names are really useful for admins to know which physical RJ45 ethernet port to plug their cat5 cable into. With the scheme we opted for as a default now you can now consider the USB ethernet adapter simply a trivial converter of cat5, so that instead of having to map cat5 cables to RJ45 port you now just have to map a cat5 cable to a USB port. Looking at it that way makes this choice kinda natural, doesn't it? If you think about it this way the USB ethernet adapter is really just a converter you can randomly replace, and the focus is stricly on matching up cables and physical ports on the computer itself.
That all said, this all isn't set in stone. We are very open to changes.
Lennart
Posted Jan 8, 2013 21:02 UTC (Tue)
by dave_malcolm (subscriber, #15013)
[Link] (11 responses)
Posted Jan 8, 2013 21:26 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (10 responses)
Posted Jan 8, 2013 21:51 UTC (Tue)
by jimparis (guest, #38647)
[Link] (1 responses)
Posted Jan 8, 2013 22:52 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link]
Posted Jan 9, 2013 2:30 UTC (Wed)
by dave_malcolm (subscriber, #15013)
[Link]
Posted Jan 9, 2013 5:34 UTC (Wed)
by jthill (subscriber, #56558)
[Link]
Posted Jan 9, 2013 23:18 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
I suppose there's a 'DFINSIZ' limit for the length of variable names too. Either that or the 'E' key was broken that day…
Posted Jan 9, 2013 23:53 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
I always wondered how EIEIO did happen.
Posted Jan 10, 2013 11:20 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
Posted Jan 11, 2013 20:30 UTC (Fri)
by pcarrier (guest, #65446)
[Link] (2 responses)
Posted Jan 11, 2013 20:49 UTC (Fri)
by s_hoop (guest, #49503)
[Link]
Posted Jan 12, 2013 10:19 UTC (Sat)
by zwenna (guest, #64777)
[Link]
Posted Jan 8, 2013 22:46 UTC (Tue)
by DarrenJThompson (guest, #88685)
[Link] (6 responses)
Can the device be mapped into more than one namespace (e.g. eth0 and MAC and path-based) at the same time?
Posted Jan 8, 2013 22:54 UTC (Tue)
by mezcalero (subscriber, #45103)
[Link] (5 responses)
Posted Jan 8, 2013 23:01 UTC (Tue)
by ovitters (guest, #27950)
[Link] (4 responses)
Posted Jan 9, 2013 0:20 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
There's also a special API to interact with them which actually uses device _indexes_, not names. As far as I remember, there was not even a way to lookup index by name - one has to enumerate all the devices and get their names using SIOCGIFNAME (though I might be mistaken here).
It's a legacy mess, in short.
Posted Jan 9, 2013 7:36 UTC (Wed)
by dankamongmen (subscriber, #35141)
[Link]
Posted Jan 10, 2013 10:10 UTC (Thu)
by justincormack (subscriber, #70439)
[Link]
Posted Jan 9, 2013 0:29 UTC (Wed)
by mezcalero (subscriber, #45103)
[Link]
Posted Jan 9, 2013 2:03 UTC (Wed)
by mgb (guest, #3226)
[Link] (15 responses)
I strongly disapprove of Mr Poettering's ongoing attempts to morph the supremely flexible Linux world into some Microsoft-ish monolithic Lennux thing.
Posted Jan 9, 2013 2:39 UTC (Wed)
by dirtyepic (guest, #30178)
[Link] (5 responses)
Posted Jan 9, 2013 12:38 UTC (Wed)
by Zack (guest, #37335)
[Link] (4 responses)
Assuming he's the same that is involved with Debian GNU/kFreeBSD, there might be a correction of Lennart's dismissal of all that's not to his liking, and systemd might, after all, become a universal init for GNU systems.
(Although, after a cursory search of the systemd-devel list I can't find any patches)
Posted Jan 9, 2013 14:19 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (2 responses)
The best thing for the kFreeBSD people to do would be to create their own non-portable init replacement and use all the FreeBSD goodies such as kqueue, jails, capsicum, devd and whatnot. This project should share the portable subset of systemd's interfaces and add its own extensions for kFreeBSD specific functionality. I can't think of another way to bring systemd's advantages to kFreeBSD while retaining an easily understandable and hackable code base. Yes, there'd be some duplication of functionality, but you can't have everything.
Besides, the main obstacle for wide-spread systemd adoption isn't lack of portability but Ubuntu. They are the only distro with a relevant user base that doesn't offer systemd at least as an option.
Posted Jan 9, 2013 16:23 UTC (Wed)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
I think it's more fair to say that a FreeBSD port won't happen soon. Once systemd has settled down, there's a better chance that necessary changes to enable it on systems other than Linux will happen. FreeBSD may adopt some Linux-like features that will make porting systemd practical (especially once they've proven their worth in Linux) and Lenaert Poettering will probably move on to a new project, so systemd may have a maintainer who's more willing to tolerate some
Posted Jan 10, 2013 10:34 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Of course, things would be different if FreeBSD were to adopt the essential Linux APIs that systemd needs. But I don't think they will as most of the functionality is already there, just in different form. Linux has devtmpfs/udev, FreeBSD has devfs/devd. Linux has epoll/inotify/fanotify, FreeBSD has kqueue/kevent.
Posted Jan 9, 2013 15:49 UTC (Wed)
by mbiebl (subscriber, #41876)
[Link]
Hope that clarifies.
[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d...
Posted Jan 9, 2013 5:10 UTC (Wed)
by nteon (subscriber, #53899)
[Link] (5 responses)
Posted Jan 9, 2013 6:00 UTC (Wed)
by mgb (guest, #3226)
[Link] (4 responses)
Linux and the Gnu tools combine to create an extremely flexible platform that is optimal for almost all use cases.
Poettering seems determined to create a monolithic monstrosity more akin to Microsoft than Gnu and Linux.
Not only is this technically abhorrent in and of itself, but the process whereby he takes control of a key feature and then leverages it to force other unnecessary changes is morally abhorrent, and incidentally also in the Microsoft vein.
Posted Jan 9, 2013 6:35 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> Linux and the Gnu tools combine to create an extremely flexible platform that is optimal for almost all use cases.
Posted Jan 9, 2013 11:01 UTC (Wed)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Jan 9, 2013 12:43 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted Jan 9, 2013 6:51 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
And besides, I don't even care whether it's monolithic or unix-ish or whatever other labels you'll come up with. What I care about is that it is faster, more reliable and more powerful than any of its alternatives. And unlike you, Poettering posted long and detailed rationale for the systemd design in his blog, while you completely fail to give any technical arguments against it. That makes it a lot easier to agree with him than with you.
Posted Jan 9, 2013 8:35 UTC (Wed)
by tnoo (subscriber, #20427)
[Link]
For me, systemctl is much nicer to use than random init scripts, and journalctl much more convenient than the traditional Unix chaos of randomly formatted logfiles.
So I highly welcome Poetterings work on this, which is much more useful than your comment that Linux is morphed by him into Windows (whatever that means).
Posted Jan 9, 2013 9:41 UTC (Wed)
by tao (subscriber, #17563)
[Link] (1 responses)
Posted Jan 9, 2013 9:49 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 9, 2013 9:23 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (6 responses)
This seems a bit vague - What specific configuration file formats have been dropped?
Posted Jan 9, 2013 10:18 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (5 responses)
Posted Jan 9, 2013 13:17 UTC (Wed)
by sorpigal (guest, #36106)
[Link] (4 responses)
Hostname will be read from /etc/hostname instead of
/etc/sysconfig/network (Mandriva/Mageia, ALT)
Locale information will be read from /etc/locale.conf instead of
/etc/sysconfig/i18n (Mandriva/Mageia, ALT)
Time zone information will be read from /etc/localtime instead of
/etc/timezone (Debian)
Strangely it still reads /etc/timezone on Debian, but does not write it (?)
Console/keyboard config will be read from /etc/vconsole.conf instead of
/etc/sysconfig/keyboard (SuSE, ALT, Mandriva/Mageia)
I think that's everything, and it's a bit of a mess as-is since some of these files are in slightly different formats even if the path is the same.
Posted Jan 9, 2013 15:36 UTC (Wed)
by Zack (guest, #37335)
[Link]
On the upside though, once package management gets integrated, we'll finally have an answer as to whether 'deb or rpm' constitutes the "one true way".
Posted Jan 9, 2013 17:31 UTC (Wed)
by james (subscriber, #1325)
[Link] (1 responses)
Posted Jan 9, 2013 17:41 UTC (Wed)
by sorpigal (guest, #36106)
[Link]
I wouldn't call that "missed" since it's essentially in the summary anyway:
Posted Jan 10, 2013 8:06 UTC (Thu)
by nhippi (subscriber, #34640)
[Link]
Systemd 197 released
Systemd 197 released
Minor bikesheddery: are underscores (or dashes) allowed within names?
Systemd 197 released
en_x000000000466
en_p5_s0
en_s1
ww_x028037ec0200
seems to me to be easier for (this human) to parse than
enx000000000466
enp5s0
ens1
wwx028037ec0200
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Does anyone value being able to sight-read the actual address values? Why not base64 them?
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
them _all_ for the 'eieio' instruction so that we wouldn't have to use
them anywhere else"
-- Linus Torvalds
Systemd 197 released
Systemd 197 released
Indeed, the error message corresponding to EIEIO is Computer bought the farm.
Systemd 197 released
Systemd 197 released
From what i read, the udev naming rules/mapping thing still works but it would be nice to have that confirmed.
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
ifdefs to bring in other Unix-like systems. Not going to happen soon, but never is a very long time.
Systemd 197 released
https://lwn.net/Articles/524920/
There are real technical issues going on here, to the point that "porting" systemd to kFreeBSD would mean to essentially rewrite it. At least that is the impression that Poettering's comment left me with, and he should know given that he wrote the thing.
Nevertheless, it *might* happen, just like we *might* one day genetically engineer pigs to grow wings and fly. But it's coffee cup reading more than anything else.
Systemd 197 released
Robert Millan is mentioned, because nss-myhostname was merged into systemd, including its git history, where Robert had provided a kfreebsd build fix [1]. That non-Linux support was dropped later on [2].
[2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=07...
Systemd 197 released
Systemd 197 released
Systemd 197 released
Android and uClibc/Busybox systems are very monolithic non-GNU-ish systems. And they FAR outnumber 'traditional' desktop/server Linux (and other Unixes, for that matter).
Systemd 197 released
Systemd 197 released
It's great iff there is a substantial benefit to be gained by doing so. If there isn't, the ability to replace components only makes things more complex and harder to integrate and test. Poettering understands that, and most 'Unix philosophy' whiners either don't or have very strange ideas about what a substantial benefit is.
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
Systemd 197 released
> legacy configuration file formats has been dropped. We
> recommend distributions to simply adopt the configuration
> files everybody else uses now
Systemd 197 released
Systemd 197 released
/etc/HOSTNAME (Slackware)
/etc/conf.d/hostname (Gentoo)
/etc/sysconfig/language (SuSE)
/etc/default/locale (Debian, Angstrom)
/etc/profile.env (Gentoo)
/proc/cmdline (Fedora: locale.LANG now required, won't read just LANG)
/etc/sysconfig/console (SuSE)
/etc/sysconfig/consolefont (ALT, Gentoo)
/etc/rc.conf (Gentoo)
/etc/conf.d/keymaps (Gentoo)
/etc/sysconfig/i18n (Mandriva/Mageia)
/etc/sysconfig/console/default.kmap (Mandriva/Mageia)
Systemd 197 released
One thing you missed is this:
Systemd 197 released
If downstream distributions want to maintain compatibility with their old configuration files, they are welcome to do so, but need to maintain this as patches downstream. The burden needs to be on the distributions to maintain differences here. Our suggestion however is to just convert the old configuration files on upgrade, as multiple distributions already do.
Systemd 197 released
We
recommend distributions to simply adopt the configuration
files everybody else uses now and convert the old
configuration from packaging scripts. Most distributions
already did that. If that's not possible or desirable,
distributions are welcome to forward port the specific
pieces of code locally from the git history.
I was listing specifics that weren't in the summary.
Systemd 197 released