Announcement

Collapse
No announcement yet.

systemd 246-RC1 Released

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

  • RahulSundaram
    replied
    Originally posted by k1e0x View Post

    It's not so much about Linux..

    It's that OpenRC has comparable features for FreeBSD, it also has the right licence and scope.
    OP clearly wasn't talking about FreeBSD since he made the comparison to systemd explicitly. However if you are talking about openrc on freebsd, that's fairly off-topic but also previous attempts to propose just that have failed

    https://lists.freebsd.org/pipermail/...er/053740.html

    I haven't read about anything more recent happening in that space

    Leave a comment:


  • k1e0x
    replied
    Originally posted by RahulSundaram View Post

    There is plenty of features in systemd init that have no comparable equivalents in other init systems and they are heavily used in production. It is frankly not close. As a quick example, dozens of security hardening toggles. Also systemd doesn't have a DNS server. Maybe you are confusing a resolver with a server?
    netstat -plnt | grep 53 .. looks like a server to me.. what do I know? it's claiming the port for a real server.


    It's not so much about Linux.. Linux is a lost cause at this point and descending into a Server 2019 clone under the guidance of IBMHat.

    It's that OpenRC has comparable features for FreeBSD, it also has the right licence and scope.
    Last edited by k1e0x; 09 July 2020, 04:19 PM.

    Leave a comment:


  • Space Heater
    replied
    Originally posted by k1e0x View Post
    Also there is the problem of recovery of a binary file in emergency situations with failing equipment. Text is much easier to work with. Logs in a binary format can become corrupt and unusable. Even corrupt text is partly recoverable.
    Most fields are formatted as UTF-8 text strings, and in fact you can view damaged (or undamaged) journal file contents using strings(1). So frankly I don't believe the claim that systemd journal files are more susceptible to corruption than plain-text (which is of course also a binary format).

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by k1e0x View Post
    It isn't feature light. It can do all the state tracking, restarting, cgroup, limiting stuff systemd can. It doesn't have a DNS server in it though.. you know.. because you need that.
    There is plenty of features in systemd init that have no comparable equivalents in other init systems and they are heavily used in production. It is frankly not close. As a quick example, dozens of security hardening toggles. Also systemd doesn't have a DNS server. Maybe you are confusing a resolver with a server?

    Leave a comment:


  • k1e0x
    replied
    OpenRC at 33.7k lines can do:
    • Portable between Linux, TrueOS, FreeBSD, and NetBSD
    • Parallel service startup (Off by default)
    • Dependency based boot-up
    • Process segregation through cgroups
    • Per-service resource limits (ulimit)
    • Separation of code and configuration (init.d / conf.d)
    • Extensible startup scripts
    • Stateful init scripts (is it started already?)
    • Complex init scripts to start multiple components (Samba (smbd and nmbd), NFS (nfsd, portmap, etc.))
    • Automatic dependency calculation and service ordering
    • Modular architecture and separation of optional components (Cron, syslog)
    • Expressive and flexible network handling (including VPN, bridges, etc.)

    It isn't feature light. It can do all the state tracking, restarting, cgroup, limiting stuff systemd can. It doesn't have a DNS server in it though.. you know.. because you need that.
    Last edited by k1e0x; 09 July 2020, 01:34 PM.

    Leave a comment:


  • discordian
    replied
    Originally posted by andyprough View Post
    According to my handy little lines of code counter today:
    systemd - 1.4 million
    runit - 15.3k
    openrc - 33.7k
    s6 - 24.2k
    Thats some hilarious bullshit numbers, I attached some more reliable ones from actual systemd,
    and from some projects you will pretty much need to use if you are going to duct-tape everything with
    shellscripts.
    (note that systemd comes with a ton of tests and fuzzers aswell).


    Code:
    cloc /tmp/systemd-246-rc1
    3849 text files.
    3707 unique files.
    1385 files ignored.
    
    github.com/AlDanial/cloc v 1.82 T=3.09 s (799.2 files/s, 255548.5 lines/s)
    --------------------------------------------------------------------------------
    Language files blank comment code
    --------------------------------------------------------------------------------
    C 1027 117401 24769 403107
    XML 363 17858 1842 80113
    C/C++ Header 714 10739 13503 38049
    Python 27 1521 6656 17311
    PO File 29 4161 4546 12500
    NAnt script 55 1080 0 9423
    Markdown 41 1570 0 6845
    Bourne Shell 153 1332 588 4896
    HTML 7 103 3 3058
    Bourne Again Shell 9 339 318 2007
    Perl 2 69 40 1772
    m4 13 66 0 898
    CSS 1 15 7 325
    XSLT 2 38 54 275
    YAML 7 15 21 162
    JSON 2 13 0 138
    awk 9 0 0 93
    Lisp 2 3 9 30
    Dockerfile 1 9 12 16
    SVG 2 0 0 16
    make 3 6 7 14
    sed 1 0 0 1
    --------------------------------------------------------------------------------
    SUM: 2470 156338 52375 581049
    --------------------------------------------------------------------------------
    Code:
    cloc /tmp/busybox-1.32.0/
    2655 text files.
    2029 unique files.
    1702 files ignored.
    
    github.com/AlDanial/cloc v 1.82 T=1.33 s (715.4 files/s, 223698.5 lines/s)
    --------------------------------------------------------------------------------
    Language files blank comment code
    --------------------------------------------------------------------------------
    C 673 27295 59828 178031
    Bourne Shell 180 1575 1477 8799
    C/C++ Header 67 1354 2567 6310
    HTML 9 420 32 3934
    C++ 1 166 62 1197
    make 6 307 451 911
    Glade 1 56 0 592
    yacc 1 93 20 570
    Perl 3 100 185 337
    lex 1 40 12 303
    NAnt script 1 84 0 260
    Bourne Again Shell 5 51 94 234
    Python 1 12 13 110
    IDL 1 0 0 33
    awk 1 2 8 30
    bc 1 10 0 25
    diff 1 1 8 15
    --------------------------------------------------------------------------------
    SUM: 953 31566 64757 201691
    --------------------------------------------------------------------------------

    Leave a comment:


  • andyprough
    replied
    Originally posted by intelfx View Post
    Unacceptable? Hmm, I do accept it somehow... must be some kind of black magic (c)
    Copyright infringement - I'm calling my lawyer.

    Leave a comment:


  • andyprough
    replied
    Originally posted by re:fi.64 View Post

    You're including documentation in at least systemd's line count.
    Probably so. Documentation is bloat.

    Leave a comment:


  • andyprough
    replied
    Originally posted by intelfx View Post

    I think we then should agree that the result of this quick look is completely useless.
    It's a discussion starter. Think of it like a 1.4 million line coffee table book.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by intelfx View Post

    Unacceptable? Hmm, I do accept it somehow... must be some kind of black magic (c)

    I fully concur. Proprietary formats must die. Though... this is kinda irrelevant to the discussion of systemd.

    The end result is that I can view, analyze and archive my logs. That's the only end result that matters.
    The problem comes down to being forced to use their tools to view the logs and not my tools. I don't only manage Linux, also FreeBSD and Solaris and until they all use the same thing, I need to use my tools. Also there is the problem of recovery of a binary file in emergency situations with failing equipment. Text is much easier to work with. Logs in a binary format can become corrupt and unusable. Even corrupt text is partly recoverable. I've also found a situation where a corrupt journald log prevented a system from being able to boot.

    This is really important to sysadmins when their bosses want real answers as to why something failed. Recovery and root cause are very important.

    Systemd team is often blind or "don't care" towards real working issues people have.
    Last edited by k1e0x; 09 July 2020, 01:01 PM.

    Leave a comment:

Working...
X