Announcement

Collapse
No announcement yet.

Linux 4.14 Dropping In-Tree Firmware

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

  • #11
    Originally posted by starshipeleven View Post
    130k lines each being 40 digits in hexadecimal. (maybe not each, but like 99% are)

    That's around 10'400'000 bytes, or 10 megabytes of blobs.
    i'm not sure how you get that result from 5.2m digits

    Comment


    • #12
      Originally posted by uid313 View Post
      This is great!
      yes, but your post is stupid
      Originally posted by uid313 View Post
      It makes it easier to separate binary blobs from the kernel. Keep proprietary binary blobs away. They are a security concern as there is no transparency and nobody knows what they do or can do.
      it does not make it easier to separate, they were already separated in firmware directory. and this is only source, binary kernel will have firmware installed anyway, just from other git repo

      Comment


      • #13
        Originally posted by Filiprino View Post
        FSF will not be pleased by this
        i am crying

        Comment


        • #14
          Originally posted by uid313 View Post
          It makes it easier to separate binary blobs from the kernel. Keep proprietary binary blobs away. They are a security concern as there is no transparency and nobody knows what they do or can do.
          Remember that pretty much everything has proprietary microcode running on it, just built into ROM rather than running from RAM.

          Being transparent requires more than just "not being able to see it"
          Last edited by bridgman; 09-16-2017, 01:45 PM.

          Comment


          • #15
            Originally posted by Filiprino View Post
            FSF will not be pleased by this, because the sorce code still needs the BLOBs.

            Lucikly for them, they can continue to use the fantastic, well-supported by lots of hardware kernel Hurd.

            Comment


            • #16
              Originally posted by bridgman View Post

              Remember that pretty much everything has proprietary microcode running on it, just built into ROM rather than running from RAM.

              Being transparent requires more than just "not being able to see it"
              True. The FSF drew the line at "if it can be updated, it should be open-source".

              I draw the line at "If it's closed-source or can't be updated, it should be quarantined by an MMU or router controlled entirely by open-source software." I'm really not sure what I'm going to do when the supply of pre-PSP x86 CPUs dries up and microcode represents an annoying exception to my policy even as-is.

              Comment


              • #17
                Originally posted by ssokolow View Post

                True. The FSF drew the line at "if it can be updated, it should be open-source".

                I draw the line at "If it's closed-source or can't be updated, it should be quarantined by an MMU or router controlled entirely by open-source software." I'm really not sure what I'm going to do when the supply of pre-PSP x86 CPUs dries up and microcode represents an annoying exception to my policy even as-is.
                Go for Power CPU based systems. They aren't open source by default, but see:

                https://www.raptorcs.com/TALOSII/prerelease.php

                Comment


                • #18
                  Oh, nice. It was annoying to see the linux-firmware files getting overwritten by the kernel ones every time when doing an install.

                  Comment


                  • #19
                    Originally posted by Zan Lynx View Post
                    Go for Power CPU based systems. They aren't open source by default, but see:

                    https://www.raptorcs.com/TALOSII/prerelease.php
                    Power board firmware is opensource, at least upstream (maybe not the CPU microcode itself, but everything else is) and it's ath the Open-power foundation github https://github.com/open-power

                    Downstream board firmwares may very well be closed-source, of course, as it's all Apache licensed.

                    TALOSII should be fully open, but it's a bit pricey.

                    Comment


                    • #20
                      Originally posted by Zan Lynx View Post

                      Go for Power CPU based systems. They aren't open source by default, but see:

                      https://www.raptorcs.com/TALOSII/prerelease.php
                      I'm aware of those and I said "x86-based" because I also play games. The point is that I'm probably going to have to maintain two separate systems to satisfy myself. One expensive non-x86 one for day-to-day use and one router-quarantined x86 machine next to it for gaming.

                      (If that winds up happening, I'll probably go for an Intel CPU for my gaming machine since I like to emulate for some of my games rather than relying on aging console hardware and, last I checked, Intel still had better single-thread performance.)

                      *sigh* It'll be hard enough just saving up for the non-x86 hardware.

                      Comment

                      Working...
                      X