Announcement

Collapse
No announcement yet.

Free Software Foundation Certifies Talos II With Respecting Your Freedom

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

  • #11
    Good for the Raptor team! Next time I buy a new Linux system I'm going to seriously look at the Blackbird as an option (as that's the only one I could reasonably afford).

    Comment


    • #12
      Originally posted by thunderbird32 View Post
      Good for the Raptor team! Next time I buy a new Linux system I'm going to seriously look at the Blackbird as an option (as that's the only one I could reasonably afford).
      Thunderbird32 buys a Blackbird 64bit system

      Comment


      • #13
        Originally posted by Djhg2000 View Post
        Sadly I have to agree; the FSF certification is meaningless now that RMS doesn't have any say in the matter..
        Honest question to you and anyone else here with similar sentiments: Can you recommend an alternate certification you believe has more weight in this space?

        For what it's worth, Raptor has always had a slightly higher standard in terms of owner control (e.g. we don't accept binary signed microcode or agree with / use the coprocessor exception). We were working RYF both while and after RMS was still at the FSF, and saw no difference in standards for RYF -- if anything, my gut feeling (based again on interactions with the FSF over this process) would be that RYF may be tightening up a bit in terms of standards.

        My recommendation to anyone that has an opinion on controversial aspects of RYF, such as the coprocessor exception, would be to reach out to the FSF and make those concerns known. We certainly have.

        Bear in mind, though, that we have only seen availability of modern, general purpose computing hardware that doesn't require the microcode or coprocessor exceptions for maybe 3 years or so. For much of that time, it was basically locked into high end servers only, and the software wasn't quite ready (or on the RISC-V side, the only hardware not needing those exceptions at that time would have been the FPGA cores). This is brand new territory for everyone involved, so be gentle -- it's hard to undo existing compromises and take that bold step into the very, very uncertain unknown.
        Last edited by madscientist159; 08 November 2019, 04:29 PM. Reason: Add missing half of sentence

        Comment


        • #14
          Originally posted by Qaridarium
          yes people FSF is now anti-FLOSS organization but stil raptors IBM power solutions are not part of this problem and a true valid product.
          but there is still one point to fix for raptor engineering and the IBM power ecosystem: there is a need for a Open-source GPU.
          Raptor can't design silicon and still make a profit, it's too big cost for a very small company.

          No amount of posting stupid bullshit on your part is going to change that, so please go annoy someone else.

          Comment


          • #15
            Originally posted by Qaridarium
            but they already do it anyway even without my bullshit posting...
            Raptor does not design custom silicon. They have selected components with good opensource support and designed a BOARD. It is NOT the same thing as designing a CPU or a GPU.

            also why do you think it is raptor engineering alone?
            IBM (which has the right size to even try) is not interested. They want to keep their customers on their platform so they will add functionality to their CPU, not to external cards.
            Adding a GPU in a Power CPU is inefficient for compute workloads so they will never do it.

            Intel is interested because they are losing high-end-CPU customers to GPU computing (NVIDIA) so they need to have some kind of GPU to compete.

            RedHat is too small to even think about making custom hardware. They also ship proprietary stuff and are blob-friendly in their RHEL (which is the actual product) so I would not count on them either.

            some people CAN NOT accept any closed-source firmware this means AMD will not get any sell to these kind of customers.
            Not enough to pay to design custom high-performance silicon from scratch, or even to mass-produce shitty "software GPU on a RiscV CPU" designs that can't even deal with fullHD displays

            Comment


            • #16
              > some people CAN NOT accept any closed-source firmware > this means AMD will not get any sell to these kind of customers. So what non-closed-source-firmware-GPU do these people buy? Designing a GPU is nontrivial, but assume some org has enough resources to design one. Next hurdle: the cost of making a mask so that you can make chips. I was assisting a FLOSS GPU project several years ago, and even then the cost to make a mask for a node a few generations old was USD 2 million. If you get something wrong you have to make a 2nd mask for another $2M. If you want a current node, it supposedly costs 1 billion dollars to tape out a 7nm chip.

              Comment


              • #17
                Originally posted by madscientist159 View Post

                Honest question to you and anyone else here with similar sentiments: Can you recommend an alternate certification you believe has more weight in this space?

                For what it's worth, Raptor has always had a slightly higher standard in terms of owner control (e.g. we don't accept binary signed microcode or agree with / use the coprocessor exception). We were working RYF both while and after RMS was still at the FSF, and saw no difference in standards for RYF -- if anything, my gut feeling (based again on interactions with the FSF over this process) would be that RYF may be tightening up a bit in terms of standards.

                My recommendation to anyone that has an opinion on controversial aspects of RYF, such as the coprocessor exception, would be to reach out to the FSF and make those concerns known. We certainly have.

                Bear in mind, though, that we have only seen availability of modern, general purpose computing hardware that doesn't require the microcode or coprocessor exceptions for maybe 3 years or so. For much of that time, it was basically locked into high end servers only, and the software wasn't quite ready (or on the RISC-V side, the only hardware not needing those exceptions at that time would have been the FPGA cores). This is brand new territory for everyone involved, so be gentle -- it's hard to undo existing compromises and take that bold step into the very, very uncertain unknown.
                Sorry for the late reply, I found this while cleaning out my notifications.

                Unfortunately I'm not aware of any other certification with the same goals. The current situation is difficult from both of our perspectives; I can't trust the FSF anymore (in my eyes they have basically gone rouge) and nobody else of sufficient trust has an equivalent certification.

                I actually trust you guys more than your competitors (and the FSF, but that's a low bar now) because I can browse your wiki and find not only links to the source code but a step-by-step guide on how to compile and install it. If I could afford one of your machines (a tough target on a student budget) I'd buy it in a heartbeat because I'm sick of all the proprietary stuff on x86. So I hope to the potential customers evaluating your systems the availability of source code and build instructions should be more important than a formal certification.

                At the same time the question of certification will inevitably come up at some point in a business environment and I have no answer to that.

                Comment

                Working...
                X