4 ms·

Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that secur

Is now 'ignoring security' the free pass that is thrown into every argument against opposing positions? I'm being facetious about that; but you know that security risks can be reasoned and mitigated with different means (sometimes less costly) than simply upgrading software.

sametmax 9y ago
s/security/bug I don't think that centos 6 is bug free yet it EOL in 2010 too. Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox. My client won't upgrade. They pay support, expensive support, to keep their old version. In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't migrate.
- toyg 9y ago
  Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work is extremely unfashionable.
  - sametmax 9y ago
    It's not the opensource movement. It's IT in general. A lot of software stopped working with the windows 10 update that was forced on the users. Android breaks the API regularly by changing the permission game. The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.
    - vetinari 9y ago
      Actually, Android doesn't break the API, even by changing the definition of permissions. If you have a breakage, investigate your app manifest, what API version you are targeting. Android frameworks shim the old behaviors for the apps that declare the use of the old API versions.
      - sametmax 9y ago
        E.G: Since API Level 19, the Alarm system has been completely remade. One must check the API Level to act some how or some differently. The same is for permissions after the advent of Android OS 6.0+. But we still need the support library to give Fragments and the ActionBar to API Levels lower than 11. And VectorDrawables to API Levels lower than 23. And many more objects. It's not that simple.
        vetinari 9y ago
        The shims are managed by targetSdkVersion, i.e. if you declare targetSdkVersion >= 23, you will get the new permission system (because it was introduced in 23) if running on [23,maxSdkVersion] device; if it is running on device that has API level [minSdkVersion,23), you get the old one; if you declare it < 23, you will get the old one, always, on newer devices too. The targetSdkVersion says what you designed against. If you claim supporting the new API, you should handle the new API (and that includes detecting what the underlying device supports). That does not preclude you from including the support library needed for lower API levels still supported.
        phonon 9y ago
        Except if you release a new/updated app, it MUST target a recent (less than a year) targetSdkVersion. "2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher." https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html https://android-developers.googleblog.com/2017/12/improving-...
  - asdfk 9y ago
    the old trick is to get your changes to the main branch so you dont need to maintain your it. that is also why anyone bothers to do so in the first place
- crististm 9y ago
  More power to you, but my initial argument was contingent on "for your definition of works". Eventually, your client will see that money spent on maintaining old (more appropriately rusty) packages will better be spent on upgrading.
solatic 9y ago
Companies who cannot upgrade their codebases are companies who cannot maintain their codebases. Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will. (small and non-notable exceptions for the literal handful of types of orgs where this is not the case)
- crististm 9y ago
  True, but is there a situation where upgrading will hurt instead of benefit? Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme. For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, they simply have different opinions on what is valuable than you do. It
  - solatic 9y ago
    Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time. But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features. Nobody in their right mind thinks you can have a company with zero technical debt, there's always a balancing act in play, but if your managers are just playing the risk card without, you know, doing an actual risk analysis which includes the risk of not being able to deliver future features, then your company isn't making smart decisions. Now, there do exist codebases where you can make the logical conclusion that there really will not be any future feature work, but it's still running in production and so it will need support, and it's a fairly large codebase, and so there would be an enormous cost to re-certifying for the upgrade with very little apparent benefit. That happens, but it only (really, truly, only) happens in large enterprises with many, large codebases and only so many engineers. Those enterprises do have the resources to hire new employees and/or outside contractors to pay down the technical debt on these half-alive projects - they just aren't prioritizing those resources on the technical debt, even long after it became clear that the clock couldn't be stretched out any longer. Through painful personal experiences, I have zero sympathy for companies in that position who think that they can solve their problems with more firewalls.

sametmax 9y ago

s/security/bug I don't think that centos 6 is bug free yet it EOL in 2010 too. Actually i'm using it right now and I'm positive it has at least one bug when running in virtualbox. My client won't upgrade. They pay support, expensive support, to keep their old version. In 2020 I'll open a shop to convert old Python code bases or fix bugs in them. I'll charge 4 times market rate. For me it's a net win that people don't migrate.

toyg 9y ago
Sometimes I wonder if the opensource movement, with its perennial “update anxiety”, is actually busy generating an industry of legacy maintenance. In a way, it’s a natural extension of the original “development is free but you pay for support” idea, but I don’t think anyone openly elaborated it into a long-term revenue-generating strategy. It looks like a slam-dunk, to be honest, with the only caveat being that work is extremely unfashionable.
- sametmax 9y ago
  It's not the opensource movement. It's IT in general. A lot of software stopped working with the windows 10 update that was forced on the users. Android breaks the API regularly by changing the permission game. The PSF has limited resources (3 million of dollar of budget) to exists (this includes running pypi and organising pyconf), but I think it's track record is quite good, even comparing to commercial products.
  - vetinari 9y ago
    Actually, Android doesn't break the API, even by changing the definition of permissions. If you have a breakage, investigate your app manifest, what API version you are targeting. Android frameworks shim the old behaviors for the apps that declare the use of the old API versions.
    - sametmax 9y ago
      E.G: Since API Level 19, the Alarm system has been completely remade. One must check the API Level to act some how or some differently. The same is for permissions after the advent of Android OS 6.0+. But we still need the support library to give Fragments and the ActionBar to API Levels lower than 11. And VectorDrawables to API Levels lower than 23. And many more objects. It's not that simple.
      - vetinari 9y ago
        The shims are managed by targetSdkVersion, i.e. if you declare targetSdkVersion >= 23, you will get the new permission system (because it was introduced in 23) if running on [23,maxSdkVersion] device; if it is running on device that has API level [minSdkVersion,23), you get the old one; if you declare it < 23, you will get the old one, always, on newer devices too. The targetSdkVersion says what you designed against. If you claim supporting the new API, you should handle the new API (and that includes detecting what the underlying device supports). That does not preclude you from including the support library needed for lower API levels still supported.
        phonon 9y ago
        Except if you release a new/updated app, it MUST target a recent (less than a year) targetSdkVersion. "2019 onwards: Each year the targetSdkVersion requirement will advance. Within one year following each Android dessert release, new apps and app updates will need to target the corresponding API level or higher." https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html https://android-developers.googleblog.com/2017/12/improving-...
- asdfk 9y ago
  the old trick is to get your changes to the main branch so you dont need to maintain your it. that is also why anyone bothers to do so in the first place
crististm 9y ago
More power to you, but my initial argument was contingent on "for your definition of works". Eventually, your client will see that money spent on maintaining old (more appropriately rusty) packages will better be spent on upgrading.

solatic 9y ago

Companies who cannot upgrade their codebases are companies who cannot maintain their codebases. Eventually, the technical debt hurts your ability to deliver with both speed and safety. When your org can't do that, your org stops being competitive in the market, and if the market doesn't kill your company then the brain drain will. (small and non-notable exceptions for the literal handful of types of orgs where this is not the case)

crististm 9y ago
True, but is there a situation where upgrading will hurt instead of benefit? Not every solution is just as good for everyone. Think of the delayed upgrade game that some people play. They wait for others to upgrade first to get rid of new bugs at their expense. Now take this game at a 10 year extreme. For them, the new branch (e.g. new language etc.) is simply too risky. It's not that they are not smart to upgrade, they simply have different opinions on what is valuable than you do. It
- solatic 9y ago
  Yes, upgrading is an engineering expenditure like any other. If you devote manpower to maintaining your codebase you're not devoting it to user-facing features. As such, upgrading your codebase can hurt your ability to deliver some priority feature on-time. But that kind of zero-sum thinking is myopic. My whole point is that if you only ever prioritize feature work, eventually you lose the ability to deliver features. Nobody in their right mind thinks you can have a company with zero technical debt, there's always a balancing act in play, but if your managers are just playing the risk card without, you know, doing an actual risk analysis which includes the risk of not being able to deliver future features, then your company isn't making smart decisions. Now, there do exist codebases where you can make the logical conclusion that there really will not be any future feature work, but it's still running in production and so it will need support, and it's a fairly large codebase, and so there would be an enormous cost to re-certifying for the upgrade with very little apparent benefit. That happens, but it only (really, truly, only) happens in large enterprises with many, large codebases and only so many engineers. Those enterprises do have the resources to hire new employees and/or outside contractors to pay down the technical debt on these half-alive projects - they just aren't prioritizing those resources on the technical debt, even long after it became clear that the clock couldn't be stretched out any longer. Through painful personal experiences, I have zero sympathy for companies in that position who think that they can solve their problems with more firewalls.