Announcement

Collapse
No announcement yet.

Schaller On Linux In 2018: Rust Rules, Apple Declines, Linux Graphics Compete

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

  • #41
    Originally posted by Delgarde View Post

    Well, the main one is that people actually take Flatpak seriously, to the point where the desktops and distros are working to integrate support for it.

    By contrast, systems like Guix have never really attracted widespread interest... and honestly, that's not much of a surprise when the ability to run it in Emacs is considered one of the most important features for them to talk about on their website. I'm sure that's useful to some people, but it's not exactly a selling point for the masses.
    Guix and Nix can be integrated in other Linux distributions and you can use them just as easily from the shell of your choice using nano as the text editor as you can from emacs. So that's not a reason to avoid them.

    - Nix came first, and the Guix team borrowed their ideas but changes their package specification format from the Nix domain-specific-language to Guile Scheme.
    - They allow multiple versions of the same package to be installed and used by different users at the same time. This includes system libraries and other dependencies. If two users use the same version of a library they do share the reference, it's not simply a case of installing a complete copy of everything except /etc/ and /boot/ under each user account.
    - The teams behind the two projects do a lot of work on reproducible builds, so most of the packages will get bit-for-bit compatibility if compiled on different computers. I think the Guix team does more work on this than Nix, but then I've followed Guix more closely.
    - Upgrades and rollbacks are fully atomic, so a power failure during the process won't leave the system in an inconsistent state. I'm sure it's not foolproof, filesystems are not ACID like a database. But I think the upgrades involve installing and configuring everything in an isolated way and then swapping a very tiny number of symlinks. So a power failure at any point but the symlink switch is harmless.
    - GuixSD, the Linux distribution that uses Guix as its only package manager, uses GNU shepherd for init. NixOS, the Linux distribution that uses Nix as its only package manager, uses systemd. The Guix team doesn't dislike systemd, they just hope to support GNU Hurd someday and systemd relies on some Linux kernel features that the Hurd team does not plan to implement.

    But Flatpak has several key differences:

    1. As far as I know, Nix and Guix don't include any application sandboxing. They can support it, but you have to write your Nix or Guix package with the sandbox included. Flatpak sandboxes by default, you can't bypass it.

    2. Guix is free-as-in-freedom software only. I don't know about Nix. So if you want proprietary drivers or Minecraft with Guix you need to write your own Guix packages. Or you can use Guix as a second package manager on your Debian/Ubuntu/Fedora/Arch/Void distribution and install the proprietary drivers or Minecraft with apt/apt/dnf/pacman/xbps respectively and install free software with Guix. I think Nix is more permissive. (Edit) Flatpak is, as far as I understand it, much easier to use with proprietary software. It works fine with free software, so easy interoperability with proprietary products is not a fundamentally bad thing. But I suspect it will be more successful because of the interoperability. (end Edit)

    I think all three of reproducible builds, atomic upgrades and rollbacks, and sandboxing will become more important as time goes on. I wouldn't be surprised if Nix, Guix, and Flatpak start to converge in terms of the three features.
    Last edited by Michael_S; 17 December 2017, 09:59 AM.

    Comment


    • #42
      MS Office 2016 running on Linux could be a bit of a game changer. It still has a few issues, but runs basically at native speed.

      Comment


      • #43
        Originally posted by przemoli View Post
        Rust was released in 2012 so we are only 5y into it's first decade.
        c++17 was released in 2017. rust is in development since 2006
        Originally posted by przemoli View Post
        As to what apps were rustified so far I would point out Firefox engine.
        no, you wouldn't. it is not rustified yet and even if it was:
        Originally posted by przemoli View Post
        Gecko is being replaced with Servo (or components researched under Servo umbrella). But that's to be expected. Rust was created as better tool for Firefox development after all
        we can agree that firefox does not count
        Originally posted by przemoli View Post
        What next 5y will bring? I'm not sure.
        we can stop right here
        Originally posted by przemoli View Post
        Still Rust looks to have gained good recognition.
        where?
        Originally posted by przemoli View Post
        There is trend towards more functional programming
        all major languages(rust is not one of them obviously) support functional programming
        Last edited by pal666; 17 December 2017, 04:52 PM.

        Comment


        • #44
          Originally posted by L_A_G View Post
          The reason why Rust was created in the first place was due to how slow progress had become in C/C++
          for that rust needs to be "better c++" which it is not. you can't improve on slow progress by moving in other direction

          Comment


          • #45
            Originally posted by tildearrow View Post
            H.265 is successful in the proprietary world
            to the extent that all content providers, all browser vendors and all hardware vendors are developing av1

            Comment


            • #46
              Originally posted by przemoli View Post
              Parallelism is hard. Web browser such as Firefox really need parallelism. Thus follow that any improvement to tools to manage parallelism is of great benefit to Firefox.
              browsers do not need fine-grained parallelism, so it is not really hard. just firefox was garbage slower than any other browser

              Comment


              • #47
                Originally posted by starshipeleven View Post
                Really, they do what is the best way to spend their resources, and improving only their linux part is (far) less important than a cross-platform change like Firefox Quantum.
                they could get even more resources for quantum by dumping linux support

                Comment


                • #48
                  Originally posted by Michael_S View Post
                  But the enormous advantage of Rust over C++ is that the borrow-checker validates reference ownership in the compiler and you have to use rarely used and not recommended escapes to get around it.
                  but the enormous advantage of c++ over rust is that c++ is more powerful language and you don't have to rewrite billions of lines of code. and, since we are talking about future, in future c++ will have better safety features than rust currently has

                  Comment


                  • #49
                    Originally posted by pal666 View Post
                    but the enormous advantage of c++ over rust is that c++ is more powerful language and you don't have to rewrite billions of lines of code. and, since we are talking about future, in future c++ will have better safety features than rust currently has
                    Right, and you'll get all of those without rewriting? That's bullshit. Every language revision comes with a price, that is, lots of rewriting according to the latest fashion.

                    Comment


                    • #50
                      Originally posted by TLE02 View Post
                      I think a lot of the people replying is reading it wrong. "Rust puts itself on a trajector to replace C/C++ for low-level programming." does not mean "will replace C/C++ in all existing low level code bases" nor does it mean "will become the default choice for a new low level code base", it means, that it puts itself on the trajectory to become the default for a new low level code base.

                      I really don't get all the rust hating. It seems large without argument. I agree that defaulting to "let's rewrite the world I rust" is silly. But the rationale behind rust seems solid. It simply is: C has been the de facto choice for low level programming for decades, in fact for the largest part of amputee since progamming, and it has served us well. But, during all that usage, weaknesses A, B and C have been identified that leads to bugs and security issues (particularly around parallel code, which is becoming more and more relevant all the time).
                      People really seem to think that C is somehow perfectly tailored to the domains it has conquered. The sad truth is, even structure packing and alignment is non-standard in C and both C99 and C11 brought very essential improvements to the core language. Still many projects haven't upgraded from ANSI C. Operating system kernels and drivers use non-standard C extensions, e.g. the #pragma pack.. C still has lots of work ahead - how about starting with the standardization of the extensions that millions of people already use every day? On top of that, without any major changes, C would greatly benefit just from a revised syntax. Function pointer and typedef syntax are among the worst parts of C, sadly, for no apparent reason. For instance, Pascal does not have such a braindead syntax for pointers. Equally powerful, but the other is sane, while the one isn't.

                      Comment

                      Working...
                      X