3 ms·

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 r

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-...
        vetinari 9y ago
        That's Play Store policy for new apps and app updates, not a technical limitation of the OS. Old apps will keep working just like they did before, the new APIs will not break them.
- 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.

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-...
        vetinari 9y ago
        That's Play Store policy for new apps and app updates, not a technical limitation of the OS. Old apps will keep working just like they did before, the new APIs will not break them.
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.