Announcement

Collapse
No announcement yet.

Windows 10 To Be A Free Upgrade: What Linux Users Need To Know

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

  • Originally posted by Michael_S View Post
    Why not open source too?
    Because if it's open source then maintaining your software is usually up to the distribution specific maintainers, not you the software developer. So in the case of it being open source it literally doesn't even matter what language you choose as long as it's something reasonable. Further if it's open source then someone can just go in and update the dependencies if it falls behind.

    Comment


    • Originally posted by Luke_Wolf View Post
      Because if it's open source then maintaining your software is usually up to the distribution specific maintainers, not you the software developer. So in the case of it being open source it literally doesn't even matter what language you choose as long as it's something reasonable. Further if it's open source then someone can just go in and update the dependencies if it falls behind.
      But if you package your software in a JVM-compatible .jar file or whatever the equivalent is for .NET, there's nothing to maintain. I can use a fifteen year old .jar file unmodified right now.

      Now of course for video editing or cutting edge 3D games, the performance hit of a VM/interpreted language is too high and you must rely upon native code. And for security-related code like OpenSSL, OpenSSH, GPG, MOSH, and web browsers you never want to be running an older version because most of the updates are security-related fixes.

      But I think one of the biggest reasons Android succeeded, and one of the reasons they chose Java for it, is so that you can dump most .apk files developed for 32-bit Android 1.6 in 2009 on a Nexus 9 with 64-bit Android 5.0 and have it run without hiccups. No work for Google, aside from engineering new Android releases to be backwards compatible. No work for the app developer.

      Spreadsheets, file managers, music players, media players, text editors, and games that aren't pushing the bleeding edge - shouldn't we be writing all of those to target some runtime that maintains legacy compatibility?

      Comment


      • @Michael_S

        You must be very stupid to write about binary compatibility where no such thing exists for Windows. Old apps written before Vista/7 in mind use often the wrong storage paths and only run in an emulated way to fake admin access (or you have to run em as admin). Also all 16 bit apps you could use with XP (and newer 32 bit Windows) you can not run with any 64 bit Windows. New apps should use UAC if needed, no app for XP has that, Windows just detects install/setup as file name for obvious setup files. And: with the exception of some stupid Intel Atom systems which run a 32 bit Windows nowadays every other pc runs 64 bit Windows 8+ when sold with a MS OS, I don't expect that somebody will try to replace it with a 32 bit install - you can repartition the hd then as you can not run a 32 bit UEFI on normal desktops and Windows can only use GPT together with UEFI, for MBR they enforce you to use legacy mode. There is no such limit for Linux...

        Comment


        • Originally posted by Kano View Post
          @Michael_S

          You must be very stupid to write about binary compatibility where no such thing exists for Windows. Old apps written before Vista/7 in mind use often the wrong storage paths and only run in an emulated way to fake admin access (or you have to run em as admin). Also all 16 bit apps you could use with XP (and newer 32 bit Windows) you can not run with any 64 bit Windows. New apps should use UAC if needed, no app for XP has that, Windows just detects install/setup as file name for obvious setup files. And: with the exception of some stupid Intel Atom systems which run a 32 bit Windows nowadays every other pc runs 64 bit Windows 8+ when sold with a MS OS, I don't expect that somebody will try to replace it with a 32 bit install - you can repartition the hd then as you can not run a 32 bit UEFI on normal desktops and Windows can only use GPT together with UEFI, for MBR they enforce you to use legacy mode. There is no such limit for Linux...
          There's no perfect backwards compatibility. But I have run games I purchased in 2000 for Windows 98 on Windows 7 in 2012. The game vendors (3DO for Heroes of Might and Magic 3 and Blizzard for Starcraft 1) didn't have to do anything, and I just had to toggle a few 'compatibility mode' settings to get them to work.

          I don't game as much anymore and I don't miss it, so it's not an issue for me. But it's an issue for my kids, and if I want them to enjoy using Linux and not resent both their dad and also Linux, I need something that will let them play Minecraft in 2017 on Ubuntu/Fedora/Mint/Arch/(Kanotix?) as easily as they do now. As it turns out, I do have that - but only because Minecraft is written in Java.

          Comment


          • Kano, you are not thinking Michael_S's post from simple end user's viewpoint. Usual user simple does not care if his old Xp application runs by emulation or by black magic. He just sees that his old favorite XP application simply works in new Windows. He is not interested on details which make it work.

            Comment


            • Originally posted by Michael_S View Post
              But if you package your software in a JVM-compatible .jar file or whatever the equivalent is for .NET, there's nothing to maintain. I can use a fifteen year old .jar file unmodified right now.

              Now of course for video editing or cutting edge 3D games, the performance hit of a VM/interpreted language is too high and you must rely upon native code. And for security-related code like OpenSSL, OpenSSH, GPG, MOSH, and web browsers you never want to be running an older version because most of the updates are security-related fixes.

              But I think one of the biggest reasons Android succeeded, and one of the reasons they chose Java for it, is so that you can dump most .apk files developed for 32-bit Android 1.6 in 2009 on a Nexus 9 with 64-bit Android 5.0 and have it run without hiccups. No work for Google, aside from engineering new Android releases to be backwards compatible. No work for the app developer.

              Spreadsheets, file managers, music players, media players, text editors, and games that aren't pushing the bleeding edge - shouldn't we be writing all of those to target some runtime that maintains legacy compatibility?
              Well in principle, yes, there is a strong argument in that direction. However the same can be achieved by using statically linked binaries or a scripting language. The problem with this idea though is that if it's open source software and nobody is working on it, then that usually means that either nobody cares about it any more or it's shit and needs the Theo treatment if not to be simply thrown out in replaced. In effect the fact that OSS is interest driven negates that particular benefit and open code defeats the portability argument.

              Meanwhile as proprietary software is maintained on a product release cycle as opposed to by interest the ability to run it after support has intended actually is important because interest in software and it's maintenance are not tied together.

              That said... There's a lot of other things that play in favour of a JVM and .NET ecosystem, primary among these being that compile times are significantly faster, meaning turnaround time for both developers and package maintainers is much quicker, as well as the improved language interoperability and so on.

              Comment


              • Originally posted by Luke_Wolf View Post
                Meanwhile as proprietary software is maintained on a product release cycle as opposed to by interest the ability to run it after support has ended actually is important because interest in software and it's maintenance are not tied together.
                stupid edit limit

                Comment


                • Originally posted by Luke_Wolf View Post
                  Well in principle, yes, there is a strong argument in that direction. However the same can be achieved by using statically linked binaries or a scripting language. The problem with this idea though is that if it's open source software and nobody is working on it, then that usually means that either nobody cares about it any more or it's shit and needs the Theo treatment if not to be simply thrown out in replaced. In effect the fact that OSS is interest driven negates that particular benefit and open code defeats the portability argument.
                  That's fine for us the power users, it's not going to win over the people sending a hundred billion dollars a year into Microsoft's coffers.

                  I'm a nearly rabid Linux fan. But I'm also stubborn, and I know that when people try to force an idea on me it only makes me hate it. So I want to win people to Linux without being irritating or annoying. I've managed to convince a few family members, but every once in a while I have to help with some problem. They're all smart enough to search the web, so when they get stumped it's usually more than "How do I print only the first three pages?"

                  And even I hit headaches. I just got my sound back after a few hours without it. I finally figured out that something in the ~/.config/pulse/ got corrupted and I had to wipe the directory, logout, and log back in to get sound back. That's the first problem I've ever had with pulseaudio, but it sure was annoying.

                  I think for the average person, "You can just run any old thing you have from ten years ago" is incredibly attractive. I also think that if it makes the job easier for distribution maintainers then it gives them more time to work on other problems.

                  Comment


                  • Originally posted by Michael_S View Post
                    That's fine for us the power users, it's not going to win over the people sending a hundred billion dollars a year into Microsoft's coffers.

                    I'm a nearly rabid Linux fan. But I'm also stubborn, and I know that when people try to force an idea on me it only makes me hate it. So I want to win people to Linux without being irritating or annoying. I've managed to convince a few family members, but every once in a while I have to help with some problem. They're all smart enough to search the web, so when they get stumped it's usually more than "How do I print only the first three pages?"

                    And even I hit headaches. I just got my sound back after a few hours without it. I finally figured out that something in the ~/.config/pulse/ got corrupted and I had to wipe the directory, logout, and log back in to get sound back. That's the first problem I've ever had with pulseaudio, but it sure was annoying.

                    I think for the average person, "You can just run any old thing you have from ten years ago" is incredibly attractive. I also think that if it makes the job easier for distribution maintainers then it gives them more time to work on other problems.
                    If they're a normal user and it's an open source program in principle they should be using the package manager anyway. instead of kicking around misc copies of open source program X, Y, or Z, that they downloaded off of the web. Now it's a fair point that package repos don't have everything and you have to work around edge cases but for most users all of the packages that they're likely to use should be there. The situation would be vastly improved had linux taken the BSD model of development as developers would then be the maintainers for their packages in a Linux ports tree but that's never going to happen now.

                    Without drastically changing the way the packaging model works the benefits you ascribe really only work for closed source software. There are plenty of other benefits though as I said to going the JVM/.NET route besides that though. A purely JVM/.NET web browser for example wouldn't take like 6 hours to compile and the fact that it's already running in a VM I would imagine would only help in implementing it.

                    Comment


                    • @Michael_S

                      The only way to run 16 bit Windows games now on Win 64 bit is DOSBOX with integrated Windows 3.1. But for that I don't need Win 64 bit

                      Comment

                      Working...
                      X