5 ms·

> They aren't kids playing with toys that we need to nanny over In my experience (university), yes they are, and they should do that at home. Why do you need

> They aren't kids playing with toys that we need to nanny over In my experience (university), yes they are, and they should do that at home. Why do you need the latest bleeding versions in the first place? In my sysadmin experience, people believe software gets bad and deprecated as soon as the glory next breaking version appears. I don't think I need to argue why this is an illogical stance. With my developers hat on, bumping to the next version mid-process reliably introduces more friction than is worth it. People think the next version solves that one weird issue but ignore that it introduces two new ones and that the software must be changed to fix five new incompatibilities. But the solution reliably is to just not use that weird feature that caused the bug in the first place, and think what a clean solution would have been. And guess what, the result is a cleaner and more compatible code base. It's a tip that works for me again and again: If there is friction, think - before spending the next hours with an update that will soon lead to new problems. It's great that you can for example compile Linux without too much friction. It's great that arcane shell scripts can run on any system. Stability (in a compatibility sense) is not a nice-to-have, it's basic sanity.

treehau5 10y ago
My comment to you two is -- why not both? Stability, sanity, all that is amazing, and a must have. But also bug-fixes, security improvements, and performance improvements are wonderful too, which tends to come with using up-to-date dependencies. The problem with the latter, as you mentioned, is when it introduces breaking API changes and is wholly not backwards compatible. This is not a "kids playing with toys wanting to experiment problem" this is a bad software problem, which is why I like Go, and why I liked Java when I was doing it full time. If the language you use has backwards compatibility as a first-class citizen, most likely the package authors will act that way too, and then the maintainers, and eventually the developers. Limit your software choices to those who care about not breaking everyone's shit every 2 weeks. Heck even when I write my own API's now that I know only my company is going to use internally I am thinking about this.
- jstimpfle 10y ago
  I like your answer. It's civilized, balanced, and I agree with every word of it :-) I'll add as an anecdote that I do follow your practices (limiting dependencies). It works wonderfully on Debian stable (most of the software there is now >2 years old, the next version has just been soft frozen). I have the occasional package pulled from testing: I recently toyed with Perl6. And currently I use a newer version of python3-sphinx for a nicer doc syntax but I could do without. It causes no headaches at all.
- brightball 10y ago
  Backwards compatibility is seriously under appreciated. When I tell developers to ensure that their changes are backwards compatible, they tend to look at me like I'm green. I do not understand the disconnect that developers have with understanding all of the benefits that it brings. Yes, you have some extra code in your code base so it's less clean. You also have a stable environment as a result. The first affects only your personal preference. The latter affects all of your developers and users. Unless you have a situation where it's impossible to maintain, not insisting on it is pure self interest.
  - gaius 10y ago
    I do not understand the disconnect that developers have with understanding all of the benefits that it brings. Because they've never worked on an old codebase, because front-end technologies change so often and everything just gets re-written anyway. It's a waste of time worrying about this when the code won't make it to is first birthday. If you were speaking to seasoned C and DB developers about stability in the tools and the platform, you'd be preaching to the choir.
    - bandrami 10y ago
      This gets to the complaint that so much of the open source ecosystem gets to version 0.8.6 (whether it's named that or not) and then completely rewritten "this time the right way". That's not actually a good thing.
rch 10y ago
No offense intended, but your university probably isn't competing for top engineers. Grad students and postdocs aren't professionals yet either. The sysadmin role has traditionally been a focus in that environment (e.g. controlling access to cluster resources).
- jstimpfle 10y ago
  Define "professional". And let me claim that "top engineers" are actually the prudent ones - which you didn't refute.
  - rch 10y ago
    I think we agree on the prudence of professional engineers. The definition of 'professional' is up for debate, but I'd encourage people to weigh in on the following (to IEEE, not me): - an appropriate engineering education background (ABET/EAC)[1] - at least four years of engineering experience in your field and under the supervision of qualified engineers - passed two exams (the Fundamentals of Engineering [FE] exam, which is now a computer-based test available essentially year round, and the eight-hour PE exam) - kept current by as a minimum meeting your state's continuing education requirements. -- http://insight.ieeeusa.org/insight/content/careers/97473 http://insight.ieeeusa.org/insight/content/careers/97473 [1] I think it would be worthwhile to consider apprenticeships, equivalent to the 'law office study' path to attorneys' bar certification.
jtreminio 10y ago
> Why do you need the latest bleeding versions in the first place? Because the newest version has several features that we would like to take advantage of immediately? Look at PHP 7.0 which introduced return types, and 7.1 which introduced nullable return types. These are features I really want in my application, so we upgrade.
shuntress 10y ago
I think the pain of keeping any project fully up-to-date is (sometimes far) less than the pain of updating an out-of-date project.
- jstimpfle 10y ago
  If it is, your project has a problem.
Declanomous 10y ago
For one thing, if there is any place to treat software like a toy and to play around with the latest version, it would be a college or university. I don't particularly care about having my software on the latest version. I personally prefer using the old version for six months while the newest version gets the bugs worked out of it. I know sysadmins value reliability and security, but it's really frustrating when every upgrade takes dozens of hours of work to approve. Questions like "What features do you need in the new version" miss the point. It isn't about the features of the software, it is about maintaining a modern code base. Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later. Ultimately, sticking with a version of software because it works is trading a little stability now for an absolute mess down the line.
- jstimpfle 10y ago
  I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. I don't think this thread is about "maintaining a modern code base" at all. Whatever that should mean -- My impression is you've fallen victim to the hype train. In my perception the thread is about always catching up with the latest and greatest. Would you say in all earnest that my code is not modern because I make a point of developping against solid standards and not constantly longing for things that are not in my distribution (the software there is usually 0.5-2.5 years old)? You can check some of my code at https://github.com/jstimpfle https://github.com/jstimpfle. Is it "not modern"? I'm a reasonable but not outstanding developer, and not saying that everything will work on your computer (since I'm usually the only tester) -- but I'm pretty sure I can get everything there to run on your computer with minor effort. > When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. No. Breakages are less frequent because the software is not brand new, and they are better known because all people using the stable release are on the same version. Documentation comes with the distribution, but I don't have any problems googling it by giving the version string either. > Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. This thread was never about security and I don't approve. I don't think you are familiar with the concept of a stable release. > Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later. No. If you develop against solid standards you have less breakage. It's not about incompatibility with the most recent versions. That would be a stupid idea. It's about compatibility with releases other than the latest and greatest. This means not depending on the hot new features that are only in these versions, simple as that.

treehau5 10y ago

My comment to you two is -- why not both? Stability, sanity, all that is amazing, and a must have. But also bug-fixes, security improvements, and performance improvements are wonderful too, which tends to come with using up-to-date dependencies. The problem with the latter, as you mentioned, is when it introduces breaking API changes and is wholly not backwards compatible. This is not a "kids playing with toys wanting to experiment problem" this is a bad software problem, which is why I like Go, and why I liked Java when I was doing it full time. If the language you use has backwards compatibility as a first-class citizen, most likely the package authors will act that way too, and then the maintainers, and eventually the developers. Limit your software choices to those who care about not breaking everyone's shit every 2 weeks. Heck even when I write my own API's now that I know only my company is going to use internally I am thinking about this.

jstimpfle 10y ago
I like your answer. It's civilized, balanced, and I agree with every word of it :-) I'll add as an anecdote that I do follow your practices (limiting dependencies). It works wonderfully on Debian stable (most of the software there is now >2 years old, the next version has just been soft frozen). I have the occasional package pulled from testing: I recently toyed with Perl6. And currently I use a newer version of python3-sphinx for a nicer doc syntax but I could do without. It causes no headaches at all.
brightball 10y ago
Backwards compatibility is seriously under appreciated. When I tell developers to ensure that their changes are backwards compatible, they tend to look at me like I'm green. I do not understand the disconnect that developers have with understanding all of the benefits that it brings. Yes, you have some extra code in your code base so it's less clean. You also have a stable environment as a result. The first affects only your personal preference. The latter affects all of your developers and users. Unless you have a situation where it's impossible to maintain, not insisting on it is pure self interest.
- gaius 10y ago
  I do not understand the disconnect that developers have with understanding all of the benefits that it brings. Because they've never worked on an old codebase, because front-end technologies change so often and everything just gets re-written anyway. It's a waste of time worrying about this when the code won't make it to is first birthday. If you were speaking to seasoned C and DB developers about stability in the tools and the platform, you'd be preaching to the choir.
  - bandrami 10y ago
    This gets to the complaint that so much of the open source ecosystem gets to version 0.8.6 (whether it's named that or not) and then completely rewritten "this time the right way". That's not actually a good thing.

rch 10y ago

No offense intended, but your university probably isn't competing for top engineers. Grad students and postdocs aren't professionals yet either. The sysadmin role has traditionally been a focus in that environment (e.g. controlling access to cluster resources).

jstimpfle 10y ago
Define "professional". And let me claim that "top engineers" are actually the prudent ones - which you didn't refute.
- rch 10y ago
  I think we agree on the prudence of professional engineers. The definition of 'professional' is up for debate, but I'd encourage people to weigh in on the following (to IEEE, not me): - an appropriate engineering education background (ABET/EAC)[1] - at least four years of engineering experience in your field and under the supervision of qualified engineers - passed two exams (the Fundamentals of Engineering [FE] exam, which is now a computer-based test available essentially year round, and the eight-hour PE exam) - kept current by as a minimum meeting your state's continuing education requirements. -- http://insight.ieeeusa.org/insight/content/careers/97473 http://insight.ieeeusa.org/insight/content/careers/97473 [1] I think it would be worthwhile to consider apprenticeships, equivalent to the 'law office study' path to attorneys' bar certification.

jtreminio 10y ago

> Why do you need the latest bleeding versions in the first place? Because the newest version has several features that we would like to take advantage of immediately? Look at PHP 7.0 which introduced return types, and 7.1 which introduced nullable return types. These are features I really want in my application, so we upgrade.

shuntress 10y ago

I think the pain of keeping any project fully up-to-date is (sometimes far) less than the pain of updating an out-of-date project.

jstimpfle 10y ago
If it is, your project has a problem.

Declanomous 10y ago

For one thing, if there is any place to treat software like a toy and to play around with the latest version, it would be a college or university. I don't particularly care about having my software on the latest version. I personally prefer using the old version for six months while the newest version gets the bugs worked out of it. I know sysadmins value reliability and security, but it's really frustrating when every upgrade takes dozens of hours of work to approve. Questions like "What features do you need in the new version" miss the point. It isn't about the features of the software, it is about maintaining a modern code base. Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later. Ultimately, sticking with a version of software because it works is trading a little stability now for an absolute mess down the line.

jstimpfle 10y ago
I said it elsewhere, but personally I'm a Debian stable evangelist. There is one major upgrade every 2 years or so. It often goes without friction. The rest is mostly security updates. Breakage between major upgrades is very rare. I don't think this thread is about "maintaining a modern code base" at all. Whatever that should mean -- My impression is you've fallen victim to the hype train. In my perception the thread is about always catching up with the latest and greatest. Would you say in all earnest that my code is not modern because I make a point of developping against solid standards and not constantly longing for things that are not in my distribution (the software there is usually 0.5-2.5 years old)? You can check some of my code at https://github.com/jstimpfle https://github.com/jstimpfle. Is it "not modern"? I'm a reasonable but not outstanding developer, and not saying that everything will work on your computer (since I'm usually the only tester) -- but I'm pretty sure I can get everything there to run on your computer with minor effort. > When you upgrade often, it is easier to read the documentation and find where changes might break something, and when things do break it is easier to fix them. No. Breakages are less frequent because the software is not brand new, and they are better known because all people using the stable release are on the same version. Documentation comes with the distribution, but I don't have any problems googling it by giving the version string either. > Upgrades always have the potential to break things, but when you keep up with the upgrades it is easier to achieve the stability and security goals the sysadmin wants. This thread was never about security and I don't approve. I don't think you are familiar with the concept of a stable release. > Upgrades that jump over several versions at a time are a nightmare to debug, and it creates a lot of technological debt that you have to work out later. No. If you develop against solid standards you have less breakage. It's not about incompatibility with the most recent versions. That would be a stupid idea. It's about compatibility with releases other than the latest and greatest. This means not depending on the hot new features that are only in these versions, simple as that.