12 ms·

nosh does not solve every problem that launchd, mach, and libdispatch does, which is why launchd will still exist in the BSD world through Jordan, iXSystems, an

by feld 11y ago

nosh does not solve every problem that launchd, mach, and libdispatch does, which is why launchd will still exist in the BSD world through Jordan, iXSystems, and NextBSD. bringing in launchd provides many more features, but is also the stepping stone to: * networkd * configuration files that are never directly edited by humans * Never having to HUP a process again * The proper death of cron * Processes never being stuck in the wrong state just because something in the system changed, and being able to take intelligent action based on state changes nosh probably can get into FreeBSD faster, but really -- whoever can replace rc scripts first wins. nosh is far with the base system rc scripts, but ports... oh, ports....

dijit 11y ago
I would argue the validity of some of these statements. why does my init system need anything to do with my networking, they're completely separate systems in my mind. Cron has a use, it's not like it's overused or underused, it has a niche and it fills it well, what is your argument that it's bad and needs to go into init? Config files will always be hand edited, wether you facilitate that or punish that is up to you, most tools that exist for managing config files exist based on the premise that they can be changed by hand and that you "probably didn't want that" (a-la config management) but having hand-editable config files for testing things is a good thing. HUP'ing a process hasn't been an "issue" for some time, initscripts tend to wrap HUP with a "reload" command, and I'd like people to keep signal handling inside their programs.. since that's well understood as a standard and is POSIX compliant. Now, I won't argue that POSIX is the best thing ever, but unless there is a new better standard to supersede it comfortably, I am not in favour of adopting radical ideologies "because it seems like a good idea" right now, and, evidently, it doesn't anyway.
- feld 11y ago
  This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is terrible. Paul Vixie says so himself. Get over it. (everyone, not directed at you) Config files: you're inferring the wrong thing HUP: I shouldn't have to HUP a process to make it learn new things. It should be able to learn them automatically by listening for an event. Please, take a listen of exactly the scenarios Jordan lays out in the latest BSDNow podcast. It makes sense. If we want to be able to build really cool reliable non-kludgey things in the future we need these kinds of features. If your Unix is a server that never moves or changes this is going to sound uninteresting and overkill. But I want the future to allow us to be able to do really awesome stuff. I envision being able to live migrate servers from my basement to Amazon to Vultr to Digital Ocean and not have a single process puke because of changes (network interfaces, IPs, hostnames, etc)
  - lvh 11y ago
    Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.
    - feld 11y ago
      Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily jobs shouldn't run if the system is being crushed. I don't want to update my locate database during a backup or during a zpool resilver. If I pause/suspend a {VM, server, laptop} and wake it, jobs are missed ... because it's not time to run them. What if I'm live migrating a VM and there's an important job that needs to run during the time it momentarily freezes the VM for migration? VM resumes on new cluster, job wasn't run. Sure if you're doing this once by hand you can be smart about making sure the timing of migration is safe and the job actually runs. But what if you're running thousands of servers? Ok, so now we throw a ton of code at the wall customized to our environment and hope we don't miss any edge cases. Or we can stop reinventing the wheel and use a job scheduling system that solves this problem. Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up, each one starting the job over from scratch, I/O grinding to a halt as the server gasps for breath under their weight? Alright, lesson learned, customers were angry, now we know we should wrap the job with a lockfile (and hope it's a proper BSD lockf(1) which guarantees atomicity) ... or you can have an intelligent scheduling system that knows not to do such a thing. The possibilities are endless when you feed intelligence into a cron replacement.
      - dijit 11y ago
        there is a lead programmer where I work, a fiercely intelligent man.. the kind of person you want to be an architect of a project.. the kind of man that invents solid things _ALWAYS_ says. "Do a thing, do it well, do only that thing; if you build things stupid and predictable they can be robust and reliable" He's a C++ Developer working on windows. Not some GNU nut. intelligence is fine, but it's hard to code, does unpredictable things and becomes a burden. also, you can turn Cron off, it's not like it's a required system, it doesn't even come enabled by default for desktop distros (such as would be used on a laptop)
profquail 11y ago
What does libdispatch have to do with nosh or launchd? libdispatch is already in FreeBSD, are you saying it'd be removed if they switched to nosh?
JdeBP 11y ago
> nosh is far with the base system rc scripts, but ports... oh, ports... I recommend reading the nosh Guide. It has a whole chapter on creating service bundles, and lays out in detail the three-pronged approach to ports that nosh enables. This is just a précis. * run scripts are short and simple. One can just write one for a port. It can be a shell script, a perl script, a python program, an execline script, a nosh script, or something else. * You'll find that ports are growing systemd unit files. Indeed, they not only are but have been. The writing has been on the wall about this development for some years, now, and it's well into actually happening. The nosh toolset includes a mechanism that can take the majority of such unit files and generate a native service bundle from them. * One can just take the stuff that's already out there and that's already supplied. Recently the 157 rc.d scripts part of the project has hit the Russian news. That's only part of the story, though. Read the nosh Guide, and you'll find pointers to four prominent collections of daemontools/runit scripts that have existed for years. Look into the package itself, and you'll find almost four hundred service bundles pre-made and supplied in the box. Which of course feeds into the first approach: One can take an existing service bundle for a similar program and adapt it.

by feld 11y ago

dijit 11y ago

I would argue the validity of some of these statements. why does my init system need anything to do with my networking, they're completely separate systems in my mind. Cron has a use, it's not like it's overused or underused, it has a niche and it fills it well, what is your argument that it's bad and needs to go into init? Config files will always be hand edited, wether you facilitate that or punish that is up to you, most tools that exist for managing config files exist based on the premise that they can be changed by hand and that you "probably didn't want that" (a-la config management) but having hand-editable config files for testing things is a good thing. HUP'ing a process hasn't been an "issue" for some time, initscripts tend to wrap HUP with a "reload" command, and I'd like people to keep signal handling inside their programs.. since that's well understood as a standard and is POSIX compliant. Now, I won't argue that POSIX is the best thing ever, but unless there is a new better standard to supersede it comfortably, I am not in favour of adopting radical ideologies "because it seems like a good idea" right now, and, evidently, it doesn't anyway.

feld 11y ago
This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is terrible. Paul Vixie says so himself. Get over it. (everyone, not directed at you) Config files: you're inferring the wrong thing HUP: I shouldn't have to HUP a process to make it learn new things. It should be able to learn them automatically by listening for an event. Please, take a listen of exactly the scenarios Jordan lays out in the latest BSDNow podcast. It makes sense. If we want to be able to build really cool reliable non-kludgey things in the future we need these kinds of features. If your Unix is a server that never moves or changes this is going to sound uninteresting and overkill. But I want the future to allow us to be able to do really awesome stuff. I envision being able to live migrate servers from my basement to Amazon to Vultr to Digital Ocean and not have a single process puke because of changes (network interfaces, IPs, hostnames, etc)
- lvh 11y ago
  Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.
  - feld 11y ago
    Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily jobs shouldn't run if the system is being crushed. I don't want to update my locate database during a backup or during a zpool resilver. If I pause/suspend a {VM, server, laptop} and wake it, jobs are missed ... because it's not time to run them. What if I'm live migrating a VM and there's an important job that needs to run during the time it momentarily freezes the VM for migration? VM resumes on new cluster, job wasn't run. Sure if you're doing this once by hand you can be smart about making sure the timing of migration is safe and the job actually runs. But what if you're running thousands of servers? Ok, so now we throw a ton of code at the wall customized to our environment and hope we don't miss any edge cases. Or we can stop reinventing the wheel and use a job scheduling system that solves this problem. Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up, each one starting the job over from scratch, I/O grinding to a halt as the server gasps for breath under their weight? Alright, lesson learned, customers were angry, now we know we should wrap the job with a lockfile (and hope it's a proper BSD lockf(1) which guarantees atomicity) ... or you can have an intelligent scheduling system that knows not to do such a thing. The possibilities are endless when you feed intelligence into a cron replacement.
    - dijit 11y ago
      there is a lead programmer where I work, a fiercely intelligent man.. the kind of person you want to be an architect of a project.. the kind of man that invents solid things _ALWAYS_ says. "Do a thing, do it well, do only that thing; if you build things stupid and predictable they can be robust and reliable" He's a C++ Developer working on windows. Not some GNU nut. intelligence is fine, but it's hard to code, does unpredictable things and becomes a burden. also, you can turn Cron off, it's not like it's a required system, it doesn't even come enabled by default for desktop distros (such as would be used on a laptop)

profquail 11y ago

What does libdispatch have to do with nosh or launchd? libdispatch is already in FreeBSD, are you saying it'd be removed if they switched to nosh?

JdeBP 11y ago

> nosh is far with the base system rc scripts, but ports... oh, ports... I recommend reading the nosh Guide. It has a whole chapter on creating service bundles, and lays out in detail the three-pronged approach to ports that nosh enables. This is just a précis. * run scripts are short and simple. One can just write one for a port. It can be a shell script, a perl script, a python program, an execline script, a nosh script, or something else. * You'll find that ports are growing systemd unit files. Indeed, they not only are but have been. The writing has been on the wall about this development for some years, now, and it's well into actually happening. The nosh toolset includes a mechanism that can take the majority of such unit files and generate a native service bundle from them. * One can just take the stuff that's already out there and that's already supplied. Recently the 157 rc.d scripts part of the project has hit the Russian news. That's only part of the story, though. Read the nosh Guide, and you'll find pointers to four prominent collections of daemontools/runit scripts that have existed for years. Look into the package itself, and you'll find almost four hundred service bundles pre-made and supplied in the box. Which of course feeds into the first approach: One can take an existing service bundle for a similar program and adapt it.