Announcement

Collapse
No announcement yet.

Slackware 14.1 Goes Into Beta, Brings New Packages

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

  • #16
    Originally posted by rvdboom View Post
    My systems obviously run quite well without it and I don't feel I miss any particularly important features. Any infos would be appreciated.
    yeah you can work without systemd just fine[less new features ill say later] is just a lot hackier and ugly and error prone, ill get to the point of more info

    Advantages from user perspective

    1.) lots easier to write init files[20 lines for real badass service] very rock solid and less error prone
    2.) habilty to start/stop service ondemand[nginx start only when someone try to access your webpage and goes down after it for example]
    3.) resouce jailing and nice level for service [for example, my nginx should have 512mb ram max, nice 20 and X% of cpu use]
    4.) start service by specific timeframes [nginx is only available each friday from 3am to 5pm] aka no more need for cron
    5.) journald is alot faster than grep[since is indexed] and provide more information than syslog + it can integrate with r/syslog too
    6.) freaking fast boot speed and no more init levels
    7.) don't require VT but it emulate the needed info to start X very cleanly
    8.) easy integration with any session system [ldap,afs,kerberos,radius,unix,AD,etc]

    Advantages from security perspective

    1.) every process or subprocess is tracked correctly from the origin process and are ended properly after main process is gone, aka no more zombie/abandoned processes
    2.) polkit integration allow secure privileges policies per process
    3.) process sandboxing through cgroups
    4.) secure logs per process in journals with the specific privileges used and timestamps
    5.) virtualization aware, yes systemd can tell your an in a virtualized enviroment or not[awesome for devs]
    6.) logind finally a proper and secure session system with a very badass API for devs

    Advantages from developers perspective

    1.) superB API
    2.) finally proper and fast child process tracking, yes no more cat/grep/hacksish PID files/dealing with wild child sisegvs/querying half kernel sys tree to be sure all your child die properly/no more bash-perl hacks
    3.) proper secure subprocess spawn with feedback control and always under your main PID, bye bye exec() [just with this you can nuke the entire startkde/startx/kdm(the process spawn code) code and replace it with 20 dbus calls]
    4.) dealing with services programatically in runtime, aka i can keep a service file in and std::stringlist modify it at will and pass it through dbus to systemd to spawn my processes/services with all the goodies mentioned
    5.) finally proper user session way to acess privileges information and proper policy usage with polkit+logind, aka no more querying ENV vars/pid/xsession info to find out the current user and no more su/sudo hacks
    6.) Runtime log per process id query, awesome for bug reports and is a lot faster than using rsyslog with sql or grep
    7.) secure sub/process de/attach thanks to logind+polkit+cgroups, aka i can from c++ attach gdb to X process and capture the output with 2 or 3 simple dbus calls and in case you need more permission polkit query the user for autorization if needed for you
    8.) hardware info tracking in realtime thanks to udev DBUS api
    9.) easy to query your process information and all childs using DBUS


    there are more features, but so far those are the more meaningful to me, systemd site have more interesting info

    Comment


    • #17
      Originally posted by stiiixy View Post
      Happy English grammar helper tip of the day for our English-as-not-your-first-language friends;

      since = <specific time>
      for = <general time-frame>

      I've been running Slackware since about 10 years
      I've been running Slackware for about 10 years

      I'm happily running slackware-current since a few months
      I'm happily running slackware-current for a few months

      Better yet;

      I have been happily running slackware-current for a few months



      I've noticed 'since' used quite a lot. Not sure why, just trying to help out a bit for those who would like to speak better generic English*


      Eins, zwei, drei, PROST!

      Thank you

      I thought that saying "I'm using slackware for a few months" would mean that I plan to use it for a few month, but you don't know the date I began to use it.

      Comment


      • #18
        Reading about this on the wider web I learn that the guy who wrote systemd also wrote pulse audio. Pulse was a bit of a stillbirth in the end, it seems he needs glory, so ginned up systemd.

        There's a lot of passive/agressive posts from him in forums where this thing was discussed - anyone not liking it subtly cast as somehow wrongheaded, or primitive, or otherwise subhuman, or merely incapable of understanding systemd's greatness.

        And then here I find teho & jrch2k8 posting omnibus expositions of systemd's advantages. Curiously no disadvantages noted. I am forced to consider the possibility that teho & jrch2k8 are merely cat's paws in a game of propaganda.

        Much like I dislike Ubuntu's use on "one runlevel to rule them all", I don't like the gutting of the system mgmt level of the OS and replacing it with brand new code.

        It's not that init is good because it's old, it's that init is good because there is nothing particularly wrong with it. Nor was there anything wrong with the old session management stuff.

        This is kind of like M$, changing the system middleware in every new release of a server version of Windows. Nothing is really gained by it, and it just means I have to learn a new way of doing the same stuff. I like BASH, I like shell scripts, I like that the UNIX way is text files for config and logging.

        Comment


        • #19
          Originally posted by hoohoo View Post
          Pulse was a bit of a stillbirth in the end, it seems he needs glory, so ginned up systemd.
          ...or just maybe because the current status of Linux core-os was lacking and he was interested in improving it? The end result was so good that first Fedora, then openSUSE, Mageia, Manriva, Arch Linux, Chakra, Tizen, Sabayon, mer (Sailfish), WebOS-Ports, GENIVI Alliance and numerous other projects decided to adopt it. Both Red Hat Enterprise Linux 7 and SUSE Linux Enterprise 12 are set to adopt systemd later this year and in 2014 respectively.

          Originally posted by hoohoo View Post
          There's a lot of passive/agressive posts from him in forums where this thing was discussed - anyone not liking it subtly cast as somehow wrongheaded, or primitive, or otherwise subhuman, or merely incapable of understanding systemd's greatness.
          Right... I guess you also noticed how clueless people can be about systemd and still spend their time bashing it and Lennart personally. However I'm really curious what comments you refering to here.

          Originally posted by hoohoo View Post
          I am forced to consider the possibility that teho & jrch2k8 are merely cat's paws in a game of propaganda.
          Propaganda? Was there something I said that wasn't factually correct? Why do you think so many collaboratively developed and open source projects adopted systemd? Why do you think so many people from various companies and communites contribute to systemd? Is this all just a conspiracy? Seriously?

          Originally posted by hoohoo View Post
          t's not that init is good because it's old, it's that init is good because there is nothing particularly wrong with it.
          Only that it's slow, initscripts are complex, there's no proper process tracking, it assumes that the system doesn't change after bootup and so on and so forth.

          Originally posted by hoohoo View Post
          Nor was there anything wrong with the old session management stuff.
          ...and you know this how?

          Originally posted by hoohoo View Post
          Nothing is really gained by it, and it just means I have to learn a new way of doing the same stuff.
          I love how you can just dismiss everything that was said to you and say "nothing is really gained by it". I guess that really explains the wide adoption of systemd, even between direct competitors like SUSE and Red Hat. You think they did it just for fun?

          Originally posted by hoohoo View Post
          I like that the UNIX way is text files for config and logging.
          systemd uses text files for (all) config and you can use syslog with systemd if you want.

          Comment


          • #20
            i think the base problem is systemd attack a problem that most regular can't perceive because most distros have very dedicated packagers, Desktop Enviroments are really good at hidding the problem and ISV have tackled the issue with very bastardic hacks to make things works in most distros.

            Current issues invisible to users:

            1.) bash init file are really complex beast in sysv like systems and for most packages maintainers have to heavily modified them to work well in your specific init system for your distro, aka an openrc init file probably won't work unmodified in upstart and won't work in sysV either without a maintainer wasting hours adapting it.

            2.) startX/startkde+kdm[the thing that start your kde desktop after you log in] scripts are probably the most barbaric example of extreme branching i ever seen to support every init/session system out there "automatically" but still most kde start issues are related to this mammut of script

            3.) KDM well basically every operation check for every possible distro variant in existance, needless to say is damn ugly and slow[gdm ain't pretty either and don't make me talk about xdm]

            4.) most developers out there avoid like the plague any linux specific session code to the point is just easier to make a new session system inside your app than suffer through the nightmare of sysV/VT/ENVs/ConsoleKit, thats why most linux apps that require root access for even a small operation have to run under sudo or spawn separated specific processes as root <-- not exactly secure

            5.) no sane linux developer will ever try to track spawned subprocess, is just impossible to make it work right in every distro. just make a huge monoprocess statically compiled blob and duplicate the subprocesses you need inside your code or avoid to death spawn subprocesses at all<-- not exactly efficient

            6.) make sane installers on linux is impossible, every freaking distro finds amusing have different path for everything important. that is the reason most commercial apps just pick a distro and send everyone else to fly

            7.) syslog is a royal pain in the ass to use from C/C++ without a bunch of layers[mostly DE's] since every distro out there find entertaining to modify default socket path/log paths and to put the sweet caramel touch you have like 4 types of syslog servers + stderr that not always points to the distro log path but to the default <-- in the end many devs just make their own log files and dump them somewhere in /var

            so this make everyone's life in the backstage a living hell but when it reach you[the user] it almost kinda works all togheter in an kinda good enough way, systemd most important and killer features are for those in the backstage and ISV than the users, ofc users get some sweets too but most is going for backstage ppl and devs that at some will allow all that wasted time to go for more useful things for the user

            fixed
            Last edited by jrch2k8; 09-19-2013, 08:57 PM.

            Comment


            • #21
              Originally posted by jrch2k8 View Post
              i think the base problem is systemd attack a problem that most regular can't perceive because most distros have very dedicated packagers, Desktop Enviroments are really good at hidding the problem and ISV have tackled the issue with very bastardic hacks to make things works in most distros.

              Current issues invisible to users:

              1.) bash init file are really complex beast in sysv like systems and for most packages maintainers have to heavily modified them to work well in your specific init system for your distro, aka an openrc init file probably won't work unmodified in upstart and won't work in sysV either without a maintainer wasting hours adapting it.

              5.) no sane linux developer will ever try to track spawned subprocess, is just impossible to make it work right in every distro. just make a huge monoprocess statically compiled blob and duplicate the subprocesses you need inside your code or avoid to death spawn subprocesses at all<-- not exactly efficient
              Init dosen't have anything to do with your DE, nor does a DE "cover up" anything (example dwm)

              slackware init scripts are not in bash, but in POSIX shell (ksh, ash etc.) (bash implements almost all POSIX, and lot more)
              they have been almost unchanged for years now, and they are the same for x86 x64 and ARM

              what sub processes are you talking about ?

              what DE's ?
              what does a desktop have with init or syslog ?

              other stuff i havent even read, am too tired now

              PS see how grub 2 is an option
              even thou lilo is still default you still have a choice to go all fancy
              but you dont have to grub for anything as theres elilo for the efi thing
              Last edited by gens; 09-20-2013, 01:44 AM.

              Comment


              • #22
                Originally posted by jrch2k8 View Post
                yeah you can work without systemd just fine[less new features ill say later] is just a lot hackier and ugly and error prone, ill get to the point of more info

                Advantages from user perspective

                1.) lots easier to write init files[20 lines for real badass service] very rock solid and less error prone
                2.) habilty to start/stop service ondemand[nginx start only when someone try to access your webpage and goes down after it for example]
                3.) resouce jailing and nice level for service [for example, my nginx should have 512mb ram max, nice 20 and X% of cpu use]
                4.) start service by specific timeframes [nginx is only available each friday from 3am to 5pm] aka no more need for cron
                5.) journald is alot faster than grep[since is indexed] and provide more information than syslog + it can integrate with r/syslog too
                6.) freaking fast boot speed and no more init levels
                7.) don't require VT but it emulate the needed info to start X very cleanly
                8.) easy integration with any session system [ldap,afs,kerberos,radius,unix,AD,etc]
                Thanks for the list. Seems to me that the advantages for servers administrators and developers far outweight the ones for users. I mean : what is "fast boot" when my old HD booted on console in less than 10 secondes and my new SSD in less than 4? What's particularly interesting in not using cron? Grep takes less than 5 secondes on my system to check the various systems logs, what's important in being 2 seconds faster? What do I do if my X session borks and I can't switch to VT? Reboot? Udev and ConsoleKit work already very well through DBUS without systemd on my Slackware, so I don't see that as a particular improvement coming from systemd.
                And you should check Slackware init scripts. They're not more complicated than what you seem to describe.
                Honestly, as a simple user, systemd doesn't bring anything to the table as is that will change my life in a particularly interesting way. And I would be very pissed off if it was not possible to switch to a VT if something went wrong with my X session, for instance.

                On the other hand, I think that providing a better experience for system administrators and developers is indeed a good reason to offer a new init and login system so I don't reject it altogether.

                Comment


                • #23
                  Originally posted by jrch2k8 View Post
                  7.) syslog is a royal pain in the ass to use from C/C++ without a bunch of layers[mostly DE's] since every distro out there find entertaining to modify default socket path/log paths and to put the sweet caramel touch you have like 4 types of syslog servers + stderr that not always points to the distro log path but to the default <-- in the end many devs just make their own log files and dump them somewhere in /var
                  Um, what? openlog() is dead-simple to use, and it does not take any paths.

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    Um, what? openlog() is dead-simple to use, and it does not take any paths.
                    is not always thrustworthy, of course for simple log stuff is more than enough but for critical data that need warranty of always be logged is not 100% thrustworthy between distros/version/options.[i specially hate rsyslog with sql option]

                    ofc this applies mostly to commercial apps that process very important data like finance, industrial operations, etc.

                    in my tests so far journald is very very thrustworthy even on forced shutdowns and is the same in every systemd able distro + other goodies, ofc i still maintain my fsynced hard logs in /var/log

                    Comment


                    • #25
                      Originally posted by jrch2k8 View Post
                      ...ofc i still maintain my fsynced hard logs in /var/log
                      fsync() is not 100% trustworthy on linux

                      Comment


                      • #26
                        Originally posted by gens View Post
                        fsync() is not 100% trustworthy on linux
                        maybe is true[i haven't tracked every possible usecase scenario], but as far i used it, works as expected. of course for me a batery backed 4+ drives RAID 10/60 is a must and for my apps i normally add to all ext4 fs in fstab commit=1[1 seconds forced sync] that i guess helps to get it closer to 100% and a good backup policy per commit blocks through automated rsync helps in case the shit hit the fan

                        Comment


                        • #27
                          Originally posted by rvdboom View Post
                          Thanks for the list. Seems to me that the advantages for servers administrators and developers far outweight the ones for users. I mean : what is "fast boot" when my old HD booted on console in less than 10 secondes and my new SSD in less than 4? What's particularly interesting in not using cron? Grep takes less than 5 secondes on my system to check the various systems logs, what's important in being 2 seconds faster? What do I do if my X session borks and I can't switch to VT? Reboot? Udev and ConsoleKit work already very well through DBUS without systemd on my Slackware, so I don't see that as a particular improvement coming from systemd.
                          And you should check Slackware init scripts. They're not more complicated than what you seem to describe.
                          Honestly, as a simple user, systemd doesn't bring anything to the table as is that will change my life in a particularly interesting way. And I would be very pissed off if it was not possible to switch to a VT if something went wrong with my X session, for instance.
                          VT session is not related to tty switch and is important if you are in ARM or MIPS or X86_64 ULP embedded systems for example

                          Comment


                          • #28
                            Originally posted by jrch2k8 View Post

                            Advantages from user perspective

                            1.) lots easier to write init files[20 lines for real badass service] very rock solid and less error prone
                            4.) start service by specific timeframes [nginx is only available each friday from 3am to 5pm] aka no more need for cron
                            5.) journald is alot faster than grep[since is indexed] and provide more information than syslog + it can integrate with r/syslog too
                            6.) freaking fast boot speed and no more init levels
                            Disadvantages from real users perspective
                            1 Soo rock solid when it fails to boot on my machine and really like the delays in initializing processes (when service misbehaves systemd waits for process)
                            4 Its new its cool and cron is old why use old thing when you have new right?
                            5 That indexing is just band-aid journald produced massive binary files which are slow to search and cannot be easily backupped
                            6 not sure now but i think init levels are still emulated somehow by systemd also init levels are sometimes really useful for me
                            Whats really slowing down boot times on my machine is SlowFI and systemd waiting for services

                            Comment


                            • #29
                              Originally posted by Ramiliez View Post
                              Disadvantages from real users perspective
                              1 Soo rock solid when it fails to boot on my machine and really like the delays in initializing processes (when service misbehaves systemd waits for process)
                              4 Its new its cool and cron is old why use old thing when you have new right?
                              5 That indexing is just band-aid journald produced massive binary files which are slow to search and cannot be easily backupped
                              6 not sure now but i think init levels are still emulated somehow by systemd also init levels are sometimes really useful for me
                              Whats really slowing down boot times on my machine is SlowFI and systemd waiting for services
                              1.) you should be using old script compat mode, because networkmanager+systemd allow deferred connections, i have wifi and other types of slow connections and a pure systemd system never wait for network. either waybe more specific
                              4.) is nice to have integrated tools especially in ARM/mips and helps a bit with the fact that not every distro ship the same cron daemon
                              5.) well for me in rPI is wicked fast and so far not much bigger than regular syslog files, again smells like rant be more specific
                              6.) no systemd start all services in parallel and defer some services until its dependecy is up(or kill the whole dep tree) but never stops, be more specific it seems maybe is your installation that is giving you issue but is hard to figure it out without more info

                              Comment


                              • #30
                                Originally posted by jrch2k8 View Post
                                1.) you should be using old script compat mode, because networkmanager+systemd allow deferred connections, i have wifi and other types of slow connections and a pure systemd system never wait for network. either waybe more specific
                                4.) is nice to have integrated tools especially in ARM/mips and helps a bit with the fact that not every distro ship the same cron daemon
                                5.) well for me in rPI is wicked fast and so far not much bigger than regular syslog files, again smells like rant be more specific
                                6.) no systemd start all services in parallel and defer some services until its dependecy is up(or kill the whole dep tree) but never stops, be more specific it seems maybe is your installation that is giving you issue but is hard to figure it out without more info
                                Just tell the newbs systemd RULES and all others suck systemd>all

                                Comment

                                Working...
                                X