5 ms·

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

by 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.

by 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.