Announcement

Collapse
No announcement yet.

Flatpak 1.8 Released For This Leading Linux App Sandboxing / Distribution Tech

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by Candy View Post

    a) you shouldn't be using abandoned software in first place
    b) if your software isn't maintained anymore, then it must be worth nothing

    At least I haven't seen or been using any software, that requires ancient libraries

    AND

    The frequency in how many distributions change versioning means - people keep updating their systems for the sake of updating, not for the sake of using old software.

    AND

    Nobody knows how long flatpaks guarantees you a running runtime on newer linux installations.

    So at the end flatpak is just another saussage that is hanging in the air - trying to convince people with the "security" and/or "breaking dependencies" kind of garbage, that no one really gives a flying shit for. Its just all a compendium of meaningless words - trying to catch those, who try to believe.
    Interesting deduction. Too bad it's wrong.

    First - I wasn't trying using abandoned software. Just software outside repository because it wasn't available on repository. Second - not always abandoned software has good alternative. Simple example - games. What if I want to play again game I've bought years ago? Also this software wasn't using "ancient libraries". It was using some library that basically changed ABI after update. Of course my software would work perfectly fine after recompiling but, well, it needs recompiling. Only because one library changed ABI. As for Flatpak runtime - yeah, it's not perfect either but it doesn't break as often and gives some stable platform. Of course I could use some old stable distro with ancient packages but it's not the right solution. Especially not for Windows users where they can use their software from Windows XP on up to date Windows 10. Ask Valve why they created Steam Runtime for Linux and why it doesn't exist on Windows or macOS. Keeping projects (especially big) up to date can be hard even for open source developers (for example - GIMP still using GTK+2) and for commercial developers is simply not worth. Not in situation when you release package for Windows and macOS and it will work fine after updates and same package will break after update on Linux and you need to recompile it or even change source to make it work again with updated dependencies.

    Comment


    • #42
      Originally posted by dragon321 View Post
      Ask Valve why they created Steam Runtime for Linux and why it doesn't exist on Windows or macOS.
      To be correct this is not as straight forwards. Valve support older Linux native games on Linux than Windows native games on Windows and that is because of the chroot. Also valve wine work is also about being still able to sell games that no longer run on Windows. Something like the Steam Runtime is not able to be done on Windows as well reason Linux kernel has stable syscall system windows does not same with macOS.

      Not all software from Xp works on Windows 10 heck there is Windows 7 software that don't work on windows 10.

      This is not as straight forwards at all for Valve. Linux kernel syscalls are stable this allows valve to provide a different runtime to the OS/Distribution provided so support software Distribution/OS does not support this is steam runtime. Windows and Mac OS syscalls are not stable so you have to use Vendor provided OS runtime like it or not in cases applications no longer work Valve has to provide refunds where on the Linux side they can tweak the runtime and do in fact tweak the runtime.

      Windows and OS X do have more stable userspace ABI compared to the distribution provides userspace ABI so Valve works around this problem with the steam runtime as well.

      Main reason why valve is willing to invest so much into Steam Runtime for Linux is to be able to sell games they would have to stop selling because they will not run on current Windows or macOS any more.

      The problem is very multi side with upsides and down sides.

      Comment


      • #43
        Originally posted by oiaohm View Post

        To be correct this is not as straight forwards. Valve support older Linux native games on Linux than Windows native games on Windows and that is because of the chroot. Also valve wine work is also about being still able to sell games that no longer run on Windows. Something like the Steam Runtime is not able to be done on Windows as well reason Linux kernel has stable syscall system windows does not same with macOS.

        Not all software from Xp works on Windows 10 heck there is Windows 7 software that don't work on windows 10.

        This is not as straight forwards at all for Valve. Linux kernel syscalls are stable this allows valve to provide a different runtime to the OS/Distribution provided so support software Distribution/OS does not support this is steam runtime. Windows and Mac OS syscalls are not stable so you have to use Vendor provided OS runtime like it or not in cases applications no longer work Valve has to provide refunds where on the Linux side they can tweak the runtime and do in fact tweak the runtime.

        Windows and OS X do have more stable userspace ABI compared to the distribution provides userspace ABI so Valve works around this problem with the steam runtime as well.

        Main reason why valve is willing to invest so much into Steam Runtime for Linux is to be able to sell games they would have to stop selling because they will not run on current Windows or macOS any more.

        The problem is very multi side with upsides and down sides.
        You're right. Linux problems begins on GUI. While it has stable core (kernel, X11, OpenGL or libc) it's missing stability on higher level. Linux is missing something compared to WinAPI or Cocoa - API which let's you write graphical app and you won't need to rewrite it after new library will be released. For example - you wrote app using GTK 2. It won't work with GTK 3 without rewrite and GTK 2 will be abandoned and lacks several features like HiDPI support. Same goes with Qt (well, at least Qt5 is mostly source compatible with Qt4). In the same time your application written using WinAPI and Cococa will likely work fine on recent versions of operating systems and if not you can easily recompile it with some or even none changes to source.

        Of course you are also right with the fact not every application that worked on XP will work fine on 10. On macOS situation is even worse (like Catalina dropping 32 bit support). It's also not like every app for Linux written 10 years ago won't work on recent OS but from my experiences it's easier to develop and maintain application for Windows or macOS than for Linux. That's why I appreciate Flatpak. I can target one runtime and release application without worrying that some library will broke compatibility or that my app won't work after one target distribution will update. Yes, it's not perfect but makes this a lot easier.

        Comment


        • #44
          Originally posted by dragon321 View Post
          It won't work with GTK 3 without rewrite and GTK 2 will be abandoned and lacks several features like HiDPI support.
          Really you have not looked closely at Windows. If you think of GTK like Microsoft Foundation Class its not much better really. The difference is bundling. Lots of old windows applications don't support HiDPI either instead MS Windows auto scales them. Windows keep on expanding it install required size because the number of old legacy libraries they keep on adding to the install some with questionable maintenance keep on increasing.

          Reality is if you look inside WinAPI on Windows 10 you will find there are like 10 different GTK like things with different levels of maintenance and some of those options are not HiDPI compatible so trigger auto scaling these days. The frequency of how often you should change how you create your graphical windows between Linux and Windows is in fact about the same. There is one catch of course Linux Distributions pull the rug out from under you and remove the old interface so you have to update or bundle yourself.

          Originally posted by dragon321 View Post
          In the same time your application written using WinAPI and Cococa will likely work fine on recent versions of operating systems and if not you can easily recompile it with some or even none changes to source.
          The likely hood that you did not use some library from Visual studio that has now changed is very low. It not always easy to recompile a windows application to newer particularly when the issue is newer version of windows need newer Microsoft compiler and it not compatible. Cococa from Apple has maintained very solid API comparability even with the compilers used.

          I am not saying that flatpak or some other standard runtime solution like the steam runtime one is a bad idea. Its a really good idea to make developers life simpler. But the reality the life on Windows is not as easy as it first appears either.

          Comment

          Working...
          X