4 ms·

Simplicity of systemd timers? Right.

kuschku 9y ago
Compared to the alternatives? Definitely. As an application developer and hobby sysadmin, systemd is a godsend over the misconfigured and broken stuff distributions have delivered for years. systemd has made my work a lot more effective, and I’ve gained massive productivity.
- jacquesm 9y ago
  > As an application developer and hobby sysadmin, systemd is a godsend over the misconfigured and broken stuff distributions have delivered for years. And that is roughly the size of the problem. If you're an application developer or a hobby sysadmin then probably systemd is good for you, but if you're an experienced sysadmin it spells 'fixed what wasn't broken' and it re-introduces many issues that were already thought about, taken care of and laid to rest.
  - digi_owl 9y ago
    Bingo. Way way too much of Linux these days is by devs for devs, and screw everyone else. Note the rise of "devops" that is basically about getting a straight line from devs to management so devs can sideline ops and their naysaying of the latest shinies devs wnats to sprinkle the projects with. Another thing is that there is less and less interest in maintenance, because maintenance is not fun. The GNU generation i slowly leaving, and is being replaced with the "fun" generation that is hell bent on rewriting working, if crufty, systems using the latest language fads over a caffeine fueled weekend...
    - jacquesm 9y ago
      There are two jobs that were rolled into the developer role that we will sorely miss in the longer term, the first was 'analyst', the second 'sysadmin/sysop'. Dumbing these down to make it possible to run these highly skilled and specialized jobs as part-time job without relevant training is one of the main reasons the state of software is what it is.
      - spydum 9y ago
        Exactly this. I have seen hundreds of systems built by experienced gray beard Unix admins, which have been steady as rocks, some lasting 15+ years without ever a peep of trouble. however I have seen many "new" boxes built by "devops", which can't survive a single upgrade cycle. If left alone for more than a few weeks, usually eat themselves and cause an outage. On one hand, am a little thankful of the devops box, it will be crashed long before it gets compromised due to neglect.
        bitwize 9y ago
        Devops is doing their job. No one really cares about the uptime of a single box anymore at cloud scale. Servers are cattle, not pets. If one instance goes down, spin up a new one to take the load. P.S. this is why, contrary to graybeard whinging, boot time matters and sysvinit cannot possibly keep up with systemd in the cloud. The faster your instances boot, the less capacity you lose while they're down.
        digi_owl 9y ago
        http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... Mooo...
        hedora 9y ago
        This is only really true for compute instances that don't have big caches or long warmup times. Even then, I think you'll find you want the bare metal the instances to run on to have high uptimes (on the order of years, not minutes), since the hardware with optimal $/perf can fit more and more workloads per machine (I think this is all Moore's law is doing to help compute these days). That means you need a decreasing number of physical machines to hold your workload. At some point your "cloud" has 10 nodes instead of 1000. Fun exercise: "cloud scale" code is typically 5-100 slower per node than single machine scale up code. How much money would you save by consolidating smaller workloads to big machines? More importantly, how much developer productivity would you gain by eliminating network latency / marshalling for internal requests? I think you'll see an increase of developers "coding around" devops over the next few years. I could be wrong, of course.
    - hedora 9y ago
      This is the CADT development model, and has been working (sort of) for at least a decade: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
      - digi_owl 9y ago
        Yep, "working"...
  - deleted 9y ago
    [deleted]
  - kuschku 9y ago
    But that’s exactly the issue, isn’t it? We need a system that people can install at home, and that never needs someone to configure or maintain it. We need a system that people can throw on a VPS, and that needs no maintenance or configuration. We need a system that a company can deploy over clusters of tenthousands of systems, and just works. If you need a human to manually configure this stuff, it’s broken. The only situation where systemd isn’t useful is when you’re a small company, but large enough to be able to afford an ops guy for every issue there is. Generally, if you need ops to configure the base OS, you’re doing stuff wrong. This whole point about devops and system is about automating sysadmins away, and this is a very necessary and worthy step.
    - digi_owl 9y ago
      https://en.wikiquote.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy#Chapter_12_4 https://en.wikiquote.org/wiki/The_Hitchhiker's_Guide_to_the_... >The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
      - kuschku 9y ago
        You can make all these quotes, and comments, but they don’t help in the real world. If you want that every child can run linux, that you can run linux on physical Internet of Things devices that are supposed to run for decades without maintenance (because you cannot access them), then you either have to build something so this can work, or you end up with Windows 10 IoT and Windows 10 Cloud running everything. No one’s gonna hire a sysadmin so they can manually upgrade every lightbulb and fire alarm on the planet, and so they can upgrade all of the servers running your containers manually. Do you think Google has sysadmins manually pulling every update for every server, writing every config? Do you think they will just because you eliminate automation?
        digi_owl 9y ago
        And i take it you side with John Deere...
  - acdha 9y ago
    > if you're an experienced sysadmin it spells 'fixed what wasn't broken' and it re-introduces many issues that were already thought about, taken care of and laid to rest As an experienced sysadmin that's a really sweeping claim to toss out without details or supporting evidence — the latter being especially important given the amount of hyperbole bandied about. The next largest SysV replacement was Upstart, which solved many problems but had curious oversights (e.g. restart with a delay or backoff, needing many releases before adding stdout/ stderr logging or launching as a user other than root), and SMF/launchd which weren't compelling enough to overcome their respective platforms’ drawbacks. Yes, you can install alternate init systems or run things under something like supervisord but supporting that was quite tedious compared to a solid standard init. As a software developer, being able to target one init system which has all of the features I need and no real drawbacks is similarly a very nice change from the past needing to support variants for each major Linux distribution while wishing they'd hit feature-parity with Windows NT 3.1 (1993!). The fact that every major Linux distribution has adopted systemd suggests that whatever reintroduced issues aren't gross exaggerations aren't as important as claimed; similarly, the features commonly dismissed as unnecessary inevitably turn out to be useful to part of the larger Linux community even if a particular detractor doesn't share those needs.
    - jacquesm 9y ago
      > As an experienced sysadmin > As a software developer So which will it be? No true Scotsman fallacy creeping in here but it seems to me that anybody that has time enough to be a developer likely isn't a full time sysadmin. Now of course there are some miracle workers out there but I've met enough syadmins to know I'm not one of them even though I can probably hold my own on the UNIX command line and manage to get through a working day without having a feeling I've wasted my time. > The fact that every major Linux distribution has adopted systemd suggests that whatever reintroduced issues aren't gross exaggerations aren't as important as claimed It might simply mean that when RedHat moves the crowd follows because it is impossible to sustain the parallel development of two init systems. And I'm all for that, I'd rather have one system than yet another fragmentation but it feels as if in this particular case that decision was not arrived at in a way that takes into account all the criticisms leveled against the 'upstart' new init system. (Pun intended.)

Compared to the alternatives? Definitely. As an application developer and hobby sysadmin, systemd is a godsend over the misconfigured and broken stuff distributions have delivered for years. systemd has made my work a lot more effective, and I’ve gained massive productivity.

jacquesm 9y ago
> As an application developer and hobby sysadmin, systemd is a godsend over the misconfigured and broken stuff distributions have delivered for years. And that is roughly the size of the problem. If you're an application developer or a hobby sysadmin then probably systemd is good for you, but if you're an experienced sysadmin it spells 'fixed what wasn't broken' and it re-introduces many issues that were already thought about, taken care of and laid to rest.
- digi_owl 9y ago
  Bingo. Way way too much of Linux these days is by devs for devs, and screw everyone else. Note the rise of "devops" that is basically about getting a straight line from devs to management so devs can sideline ops and their naysaying of the latest shinies devs wnats to sprinkle the projects with. Another thing is that there is less and less interest in maintenance, because maintenance is not fun. The GNU generation i slowly leaving, and is being replaced with the "fun" generation that is hell bent on rewriting working, if crufty, systems using the latest language fads over a caffeine fueled weekend...
  - jacquesm 9y ago
    There are two jobs that were rolled into the developer role that we will sorely miss in the longer term, the first was 'analyst', the second 'sysadmin/sysop'. Dumbing these down to make it possible to run these highly skilled and specialized jobs as part-time job without relevant training is one of the main reasons the state of software is what it is.
    - spydum 9y ago
      Exactly this. I have seen hundreds of systems built by experienced gray beard Unix admins, which have been steady as rocks, some lasting 15+ years without ever a peep of trouble. however I have seen many "new" boxes built by "devops", which can't survive a single upgrade cycle. If left alone for more than a few weeks, usually eat themselves and cause an outage. On one hand, am a little thankful of the devops box, it will be crashed long before it gets compromised due to neglect.
      - bitwize 9y ago
        Devops is doing their job. No one really cares about the uptime of a single box anymore at cloud scale. Servers are cattle, not pets. If one instance goes down, spin up a new one to take the load. P.S. this is why, contrary to graybeard whinging, boot time matters and sysvinit cannot possibly keep up with systemd in the cloud. The faster your instances boot, the less capacity you lose while they're down.
        digi_owl 9y ago
        http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... Mooo...
        hedora 9y ago
        This is only really true for compute instances that don't have big caches or long warmup times. Even then, I think you'll find you want the bare metal the instances to run on to have high uptimes (on the order of years, not minutes), since the hardware with optimal $/perf can fit more and more workloads per machine (I think this is all Moore's law is doing to help compute these days). That means you need a decreasing number of physical machines to hold your workload. At some point your "cloud" has 10 nodes instead of 1000. Fun exercise: "cloud scale" code is typically 5-100 slower per node than single machine scale up code. How much money would you save by consolidating smaller workloads to big machines? More importantly, how much developer productivity would you gain by eliminating network latency / marshalling for internal requests? I think you'll see an increase of developers "coding around" devops over the next few years. I could be wrong, of course.
  - hedora 9y ago
    This is the CADT development model, and has been working (sort of) for at least a decade: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
    - digi_owl 9y ago
      Yep, "working"...
- deleted 9y ago
  [deleted]
- kuschku 9y ago
  But that’s exactly the issue, isn’t it? We need a system that people can install at home, and that never needs someone to configure or maintain it. We need a system that people can throw on a VPS, and that needs no maintenance or configuration. We need a system that a company can deploy over clusters of tenthousands of systems, and just works. If you need a human to manually configure this stuff, it’s broken. The only situation where systemd isn’t useful is when you’re a small company, but large enough to be able to afford an ops guy for every issue there is. Generally, if you need ops to configure the base OS, you’re doing stuff wrong. This whole point about devops and system is about automating sysadmins away, and this is a very necessary and worthy step.
  - digi_owl 9y ago
    https://en.wikiquote.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy#Chapter_12_4 https://en.wikiquote.org/wiki/The_Hitchhiker's_Guide_to_the_... >The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
    - kuschku 9y ago
      You can make all these quotes, and comments, but they don’t help in the real world. If you want that every child can run linux, that you can run linux on physical Internet of Things devices that are supposed to run for decades without maintenance (because you cannot access them), then you either have to build something so this can work, or you end up with Windows 10 IoT and Windows 10 Cloud running everything. No one’s gonna hire a sysadmin so they can manually upgrade every lightbulb and fire alarm on the planet, and so they can upgrade all of the servers running your containers manually. Do you think Google has sysadmins manually pulling every update for every server, writing every config? Do you think they will just because you eliminate automation?
      - digi_owl 9y ago
        And i take it you side with John Deere...
- acdha 9y ago
  > if you're an experienced sysadmin it spells 'fixed what wasn't broken' and it re-introduces many issues that were already thought about, taken care of and laid to rest As an experienced sysadmin that's a really sweeping claim to toss out without details or supporting evidence — the latter being especially important given the amount of hyperbole bandied about. The next largest SysV replacement was Upstart, which solved many problems but had curious oversights (e.g. restart with a delay or backoff, needing many releases before adding stdout/ stderr logging or launching as a user other than root), and SMF/launchd which weren't compelling enough to overcome their respective platforms’ drawbacks. Yes, you can install alternate init systems or run things under something like supervisord but supporting that was quite tedious compared to a solid standard init. As a software developer, being able to target one init system which has all of the features I need and no real drawbacks is similarly a very nice change from the past needing to support variants for each major Linux distribution while wishing they'd hit feature-parity with Windows NT 3.1 (1993!). The fact that every major Linux distribution has adopted systemd suggests that whatever reintroduced issues aren't gross exaggerations aren't as important as claimed; similarly, the features commonly dismissed as unnecessary inevitably turn out to be useful to part of the larger Linux community even if a particular detractor doesn't share those needs.
  - jacquesm 9y ago
    > As an experienced sysadmin > As a software developer So which will it be? No true Scotsman fallacy creeping in here but it seems to me that anybody that has time enough to be a developer likely isn't a full time sysadmin. Now of course there are some miracle workers out there but I've met enough syadmins to know I'm not one of them even though I can probably hold my own on the UNIX command line and manage to get through a working day without having a feeling I've wasted my time. > The fact that every major Linux distribution has adopted systemd suggests that whatever reintroduced issues aren't gross exaggerations aren't as important as claimed It might simply mean that when RedHat moves the crowd follows because it is impossible to sustain the parallel development of two init systems. And I'm all for that, I'd rather have one system than yet another fragmentation but it feels as if in this particular case that decision was not arrived at in a way that takes into account all the criticisms leveled against the 'upstart' new init system. (Pun intended.)