4 ms·

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

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

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