Announcement

Collapse
No announcement yet.

Slackware 14.1 Goes Into Beta, Brings New Packages

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

  • hoohoo
    replied
    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.

    ...

    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

    ...
    int facility = command_line_options.facility;
    openlog("MYPROGRAM", LOG_PID|LOG_NDELAY, facility);
    // ...
    syslog(LOG_DEBUG, "%s", "Some people think this code is a royal pain in the ass!");
    // ..
    closelog();

    This ^^^ is simple stuff.

    The UNIX way, if I may be so pedantic, is to be configurable. If you compare Ubuntu to, say, Suse, well the logs are named differently. That's nothing to do with C++, it's to do with your syslog daemon config file.

    You can change the syslog daemon's config if you want.

    Leave a comment:


  • Ramiliez
    replied
    Originally posted by finalzone View Post
    Could you show your journald.conf and your logrotate.conf? What is the size limit you set? Sometime the issue could be triggered by your own setting.
    http://pastebin.ca/2457050
    Sorry but those moronic pastebins were cutting my dmesg
    im using defaults i cannot afford to lose logs right now

    Leave a comment:


  • finalzone
    replied
    Originally posted by Ramiliez View Post
    http://pastebin.sabayon.org/pastie/13384 i cant boot to desktop with 3.11 kernel older 3.10 is working.
    The issue with journald we already discussed the problem is journald binary storage logrotate doesnt work no backup and random deletion of logs when you restrict log size.
    Theres not a big need for fast boot since there are bigger problems which prevent short boot times just look at dmesg
    Could you show your journald.conf and your logrotate.conf? What is the size limit you set? Sometime the issue could be triggered by your own setting.
    Last edited by finalzone; 21 September 2013, 01:56 PM.

    Leave a comment:


  • Ramiliez
    replied
    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
    http://pastebin.sabayon.org/pastie/13384 i cant boot to desktop with 3.11 kernel older 3.10 is working.
    The issue with journald we already discussed the problem is journald binary storage logrotate doesnt work no backup and random deletion of logs when you restrict log size.
    Theres not a big need for fast boot since there are bigger problems which prevent short boot times just look at dmesg

    Leave a comment:


  • gens
    replied
    Originally posted by jrch2k8 View Post
    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
    http://lwn.net/Articles/270891/
    in short, as i understand, things not 512b aligned will wait a while to write fully (will wait in disk cache)
    this was in 2k8 anyway (maybe was fixed, idk)

    this brings up a fun thought
    what if the last couple bytes of a hashed file were not written over by the change
    i know plain text could still be read, but could a hashed file ?


    anyway you got battery backed RAID so wth.
    just a tip, check your raid hardware against the red hat bug database
    RAID is known to be buggy


    on the systemd lists you have been writing;
    you still did not say anything that cant be done easy in userspace or hasn't been done in the kernel for a long time already
    (and can thus be done in userspace easy thanks to "everything is a file" philosophy)

    so relax, have some tee then look at the big picture

    Leave a comment:


  • LinuxGamer
    replied
    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

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • Ramiliez
    replied
    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

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:

Working...
X