Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Ericg View Post
    Don't know the exact command for it off the top of my head, just remember that there IS a way.
    Actually, no. You may want to have a look at this thread from the systemd mailing list: http://www.mail-archive.com/systemd-.../msg05287.html

    Lennart Poetterings opinion on building udev without having to build systemd:
    Besides that it would
    probably be the first package where you can disable building the main
    component.
    My recommendation for distros who want udev without the rest of systemd
    is to build systemd normally and just pick the files you are interested
    in from "make install".

    Comment


    • #32
      Originally posted by Rallos Zek View Post
      This


      SystemD is to shell scripts what the Windows registry is to plain text configs.
      Really? Can you give some examples? I found systemd to be very fast, sane and simple unlike Windows registry which is a terrible, bloated mess.

      Comment


      • #33
        Originally posted by Ericg View Post
        Unsure, I know there's a way to export journal's binary logs into a plaintext format. But I am unsure (off the top of my head) if theres a way to have an external journal binary read a mounted system's journals. But as I've said before in this thread: journal doesnt take exclusive access to logs. I've got syslog-ng and journal both running on this laptop simultaneously. If for some reason journal's logs get screwed over, or they arent enough, I can just cd into /var/log and read the plaintext ones that syslog caught.
        It exist support for remote journals with the -m flag. Maybe you can use that some way. It's supposed to read all available logs.
        But when I had destroyed my dbus installation, I chrooted into the installation and readed the log in the usual way with journalctl.


        I had a bit of a reaction to LP's stuff at first too but nothing's perfect. Pulse had its problems, but they got fixed. NetworkManager wasn't perfect (still missing Bridging support though I think thats coming in the next version, or at least the groundwork is), and systemd once upon a time would fail to boot every once and awhile. Bugs were found. Bugs were fixed. Projects improved. I can very confidently say now that on all of my arch machines, with varying hardware, I have zero second-thoughts about installing systemd + Pulseaudio + Networkmanager + Avahi. They just ARE the standard to me now because I know they DO work.
        I don't think the networkamanger project has anything to do with Lennart Poettering.

        Comment


        • #34
          Originally posted by Rallos Zek View Post
          This


          SystemD is to shell scripts what the Windows registry is to plain text configs.
          .....Not even remotely. The only thing systemd stores in a binary format is the logs. Service files? plaintext. Startup control? symlinks
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #35
            Originally posted by Akka View Post
            I don't think the networkamanger project has anything to do with Lennart Poettering.
            Whoops, howd that get in there? XD knew i shouldve gone to bed earlier last night lol
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #36
              eh meh and eh meh

              Was I pissed when UDEV got forced to systemd, yeah, I got over it.

              Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

              edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.
              Last edited by nightmarex; 27 January 2013, 04:02 PM.

              Comment


              • #37
                Originally posted by nightmarex View Post
                Was I pissed when UDEV got forced to systemd, yeah, I got over it.

                Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

                edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.
                Not on mainline systemd. A few release back the requirement to always add ".service" got removed. now you can just do "systemctl enable servicename1 servicename2 servicename3" Your distro may not have that version yet, but Arch-current does
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #38
                  Originally posted by nightmarex View Post
                  Was I pissed when UDEV got forced to systemd, yeah, I got over it.

                  Do I like systemd? I guess, I am warming up to it.. still not super fond of the daemon setup however.

                  edit: by not being fond of the daemons I mean this crap "systemctl enable servicename.service" <- do I really need to type .service all the time? fuck.
                  No, you don't. Try it.

                  Comment


                  • #39
                    Originally posted by Ericg View Post
                    Systemd can also parse init.d/rc.d scripts so theres that OR you could set it up where the .service file for your app actually just calls your custom written rc.d/init.d script. Make a script for mediatomb, drop it in /etc/init.d/ then just whip up a quick mediatomb.service file, drop it in /etc/systemd/system. have:

                    ExecStart=/etc/init.d/mediatomb start
                    ExecStop=/etc/init.d/mediatomb stop

                    this way you dont have to really mix and match init systems. a quick "systemctl enable mediatomb" will tell it to start on boot. and a "systemctl start mediatomb" will run ExecStart. Because its in /etc/systemd/system you dont have to worry about it ever being overwritten. The only problem would be if mediatomb did ever ship a default .service file, yours would automatically override it because they have the same name. So you might want to make it be "my-mediatomb.service" or something like that.
                    I could use the gentoo init file, except that it's not a sysV init file. It is not standalone and depends on other bits of software to work (namely runscript) and includes dependancy info in the init file. I don't really want to write init scrips just so that I can use a different init system, when the one I have works well and is fast enough. So, until everything is shipping with .system files I think I'll stick with the distro default, and a distro that doesn't use systemd.

                    As for the journal thing, why would I want two logs on the same machine? Either make sure that I can recover the logs, from a mostly corrupt HDD as long as I can read at least some of the file, or let me not run journal at all, and pass everything to syslog-ng. chrooting and running the installed copy of journal is not good enough and not being able to get anything out on a partially corrupted file is also not good enough.

                    Comment


                    • #40
                      Originally posted by cynyr View Post
                      I could use the gentoo init file, except that it's not a sysV init file. It is not standalone and depends on other bits of software to work (namely runscript) and includes dependancy info in the init file. I don't really want to write init scrips just so that I can use a different init system, when the one I have works well and is fast enough. So, until everything is shipping with .system files I think I'll stick with the distro default, and a distro that doesn't use systemd.
                      Gentoo's wiki (http://en.gentoo-wiki.com/wiki/Systemd#Services) has a mediatomb .service, for the record. And if mediatomb doesn't ship a .service file then thats mediatomb's fault, just as it would be if they didnt ship a sysV init or an upstart job

                      Originally posted by cynyr View Post
                      As for the journal thing, why would I want two logs on the same machine? Either make sure that I can recover the logs, from a mostly corrupt HDD as long as I can read at least some of the file, or let me not run journal at all, and pass everything to syslog-ng. chrooting and running the installed copy of journal is not good enough and not being able to get anything out on a partially corrupted file is also not good enough.
                      syslogs are only there in an emergency, same way you would use a remote syslog server in the emergency event of a break in on a production machine. So far i haven't had a situation where the journal wasn't enough. "Or let me rn the journal not at all and pass everything to syslog-ng" Thats what im doing. Journal and syslog both capture log messages. Journal doesnt block syslog in any way. In fact they made it a point to allow syslog and journal to be running simultaneously.
                      All opinions are my own not those of my employer if you know who they are.

                      Comment

                      Working...
                      X