5 ms·

This is a waste of time. Syslog is the standard for logging on *nix. You will bork everything if you replace it with something incompatible. Everybody knows thi

by maratd 15y ago

This is a waste of time. Syslog is the standard for logging on *nix. You will bork everything if you replace it with something incompatible. Everybody knows this. So whatever you replace it with must be Syslog compatible. If that's the case ... there are numerous alternatives to choose from. Like rsyslog. Which is already standard on RHEL, nevermind Fedora. Rsyslog has this nifty feature where you can immediately transfer all logs via TCP or UDP to another host. Hacking problem solved. Stop fixing things that aren't broken.

naner 15y ago
I disagree. A lot of these old *nix tools are showing their age and could use a refresh based on known deficiencies. Creating new tools won't harm the old ones so I don't see a problem.
- rbanffy 15y ago
  > Creating new tools won't harm the old ones Except when they become the default tool despite known deficiencies the previous ones didn't have.
- rhizome 15y ago
  What are a few examples of other "old *nix tools" that are showing their age and have "known deficiencies?"
  - alextingle 15y ago
    CVS?
    - oneweekwonder 15y ago
      I believe this is a bad example. Because CVS is only under maintenance there is no new feature getting added and the last stable release was in 2008. Also anyone that does a bit of research on version control software would realize CVS is only around for legacy purposes and there is enough paths to convert to SVN or a more "newish" DVCS.
      - alextingle 15y ago
        CVS uses a text-based format. SVN is an "improved" version that uses a binary format. I think the parallels are quite striking. (FWIW I don't think that syslog is broken, but then I'm a programmer. Source control is a key tool in my craft, so I'm keenly aware of CVS's limitations. If I were a ststems administrator, perhaps I'd feel the same way about syslog?)
  - marbu 15y ago
    Maybe cron? See http://www.fi.muni.cz/~kas/blog/index.cgi/computers/rethinking-cron.html http://www.fi.muni.cz/~kas/blog/index.cgi/computers/rethinki...
  - dredmorbius 15y ago
    init / sysvinit / upstart / systemd: dependencies, reliable process monitoring & restarts, parallelization. cron: take your pick, but I'd like a scheduler which would produce useful email / messaging reports when things go wrong, and shut the fuck up when they don't, while logging activity in markedly more detail than current jobs do. To accomplish this today you'd need to follow a strict template on your actual cronjobs. Stuff like: what host am I on, what crontab am I being run out of, what user am I running as, what script(s) / program(s) am I invoking. nfs: performance, reliability, security, arbitrary group limits. Generally: performance monitoring. We're still relying on top, uptime, vmstat, iostat, strace, ltrace, (sometimes systemtap/dtrace), wireshark, netstat, lsof, and related tools. There are a few new tricks coming out, and some ways to integrate data from multiple sources, but often tuning systems (especially where VMs or application engines are concerned) resembles a seance / archaeological dig / bro knowledge / myth / wishful thinking / Republican plank. For the love of Dennis, it's been 40 years, give me some goddamned insights. There are probably a bunch of others, though I'm trying to stick with basics that you might find in The UNIX Programming Environment or similar -- really foundational basics (or reasonable extensions of same). The barrier to change is that most of this stuff works well enough most of the time, and too much depends on it. I'm seeing a lot of exploration of alternatives around some core systems though, and suspect we'll see significant changes in the next 5-10 years. Possibly even sooner, though history suggests slower adoption.
  - naner 15y ago
    Well pretty much everything if you ask the plan9 guys. ;) Over the years a lot of the Linux system infrastructure has been reworked: /dev --> udev SysV init --> systemd/upstart su/sudo --> policykit (for desktop stuff) sockets/shmem for IPC --> dbus (IPC for desktop apps) xorg --> wayland (not quite yet) I personally think cron and atd need to be updated and combined and possibly integrated with init. If you're not running a server and instead are using Linux for a desktop or laptop then nearly all these daemons could be reconsidered as well. Of course, sometimes you might decide that known deficiencies are better than unknown deficiencies or that simplicity and familiarity means the old tools are still preferred. FreeBSD is pretty old school and very functional after all. But there is plenty of room for experimentation.
jbk 15y ago
Not to mention that Journal will depend on systemd which is Linux-only :D
rhizome 15y ago
Over the summer I worked at a company with so little institutional knowledge that an argument broke out about whether to use NTP or not, and what to replace it with (in a webapp, natch) to ensure a good timebase. I was so flustered by this line of discussion that I had trouble participating.
- InclinedPlane 15y ago
  What exactly was the argument against NTP?
  - rhizome 15y ago
    They weren't sure it was good enough, or good any more, and they were trying to figure out ways of maintaining a timebase completely within the application, from server to server. These were developers, both salary and contract, in their 30s. As a former sysadmin, now programmer, it was surreal.
    - InclinedPlane 15y ago
      It's sad that this is basically a microcosm of the way things typically are in our field.

by maratd 15y ago

naner 15y ago

I disagree. A lot of these old *nix tools are showing their age and could use a refresh based on known deficiencies. Creating new tools won't harm the old ones so I don't see a problem.

rbanffy 15y ago
> Creating new tools won't harm the old ones Except when they become the default tool despite known deficiencies the previous ones didn't have.
rhizome 15y ago
What are a few examples of other "old *nix tools" that are showing their age and have "known deficiencies?"
- alextingle 15y ago
  CVS?
  - oneweekwonder 15y ago
    I believe this is a bad example. Because CVS is only under maintenance there is no new feature getting added and the last stable release was in 2008. Also anyone that does a bit of research on version control software would realize CVS is only around for legacy purposes and there is enough paths to convert to SVN or a more "newish" DVCS.
    - alextingle 15y ago
      CVS uses a text-based format. SVN is an "improved" version that uses a binary format. I think the parallels are quite striking. (FWIW I don't think that syslog is broken, but then I'm a programmer. Source control is a key tool in my craft, so I'm keenly aware of CVS's limitations. If I were a ststems administrator, perhaps I'd feel the same way about syslog?)
- marbu 15y ago
  Maybe cron? See http://www.fi.muni.cz/~kas/blog/index.cgi/computers/rethinking-cron.html http://www.fi.muni.cz/~kas/blog/index.cgi/computers/rethinki...
- dredmorbius 15y ago
  init / sysvinit / upstart / systemd: dependencies, reliable process monitoring & restarts, parallelization. cron: take your pick, but I'd like a scheduler which would produce useful email / messaging reports when things go wrong, and shut the fuck up when they don't, while logging activity in markedly more detail than current jobs do. To accomplish this today you'd need to follow a strict template on your actual cronjobs. Stuff like: what host am I on, what crontab am I being run out of, what user am I running as, what script(s) / program(s) am I invoking. nfs: performance, reliability, security, arbitrary group limits. Generally: performance monitoring. We're still relying on top, uptime, vmstat, iostat, strace, ltrace, (sometimes systemtap/dtrace), wireshark, netstat, lsof, and related tools. There are a few new tricks coming out, and some ways to integrate data from multiple sources, but often tuning systems (especially where VMs or application engines are concerned) resembles a seance / archaeological dig / bro knowledge / myth / wishful thinking / Republican plank. For the love of Dennis, it's been 40 years, give me some goddamned insights. There are probably a bunch of others, though I'm trying to stick with basics that you might find in The UNIX Programming Environment or similar -- really foundational basics (or reasonable extensions of same). The barrier to change is that most of this stuff works well enough most of the time, and too much depends on it. I'm seeing a lot of exploration of alternatives around some core systems though, and suspect we'll see significant changes in the next 5-10 years. Possibly even sooner, though history suggests slower adoption.
- naner 15y ago
  Well pretty much everything if you ask the plan9 guys. ;) Over the years a lot of the Linux system infrastructure has been reworked: /dev --> udev SysV init --> systemd/upstart su/sudo --> policykit (for desktop stuff) sockets/shmem for IPC --> dbus (IPC for desktop apps) xorg --> wayland (not quite yet) I personally think cron and atd need to be updated and combined and possibly integrated with init. If you're not running a server and instead are using Linux for a desktop or laptop then nearly all these daemons could be reconsidered as well. Of course, sometimes you might decide that known deficiencies are better than unknown deficiencies or that simplicity and familiarity means the old tools are still preferred. FreeBSD is pretty old school and very functional after all. But there is plenty of room for experimentation.

jbk 15y ago

Not to mention that Journal will depend on systemd which is Linux-only :D

rhizome 15y ago

Over the summer I worked at a company with so little institutional knowledge that an argument broke out about whether to use NTP or not, and what to replace it with (in a webapp, natch) to ensure a good timebase. I was so flustered by this line of discussion that I had trouble participating.

InclinedPlane 15y ago
What exactly was the argument against NTP?
- rhizome 15y ago
  They weren't sure it was good enough, or good any more, and they were trying to figure out ways of maintaining a timebase completely within the application, from server to server. These were developers, both salary and contract, in their 30s. As a former sysadmin, now programmer, it was surreal.
  - InclinedPlane 15y ago
    It's sad that this is basically a microcosm of the way things typically are in our field.