Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Hardware

Arm's New Linux-Capable Cortex-R82 Processor Will Enable Drives That Both Store and Process Data (siliconangle.com) 98

"Arm has announced its first 64 bit, Linux-capable Cortex-R processor, designed for computational storage solutions," reports Electronics Weekly.

SiliconAngle calls it "a chip designed to enable a new generation of storage devices that will not only hold data but also help process it." Such devices are part of an emerging hardware category known as computational storage. The technology promises to provide a speed boost for latency-sensitive workloads such as machine learning and real-time analytics applications. Normally, the task of storing data and processing it is relegated to separate components inside a system. The disk or flash drive holds onto the information while a separate processor does the processing. Data has to travel from the storage drive to the processor and back every time an operation is carried out, which creates delays that can slow down performance.

The emerging computational storage devices Arm targets attempt to do away with these delays to speed up applications. Instead of sending information to a separate chip for processing, the storage drive processes it locally using its built-in controller. A controller is a tiny computing module inside flash and disk drives that normally performs only low-level tasks such as writing and reading data. Arm's new Cortex-R82 is designed to serve as the controller for computational storage devices. It's available as a chip design that hardware makers can license and customize based on their needs.

"The extra computing power allows the chip to run a full Linux distribution as well as applications, all directly inside a storage drive."
This discussion has been archived. No new comments can be posted.

Arm's New Linux-Capable Cortex-R82 Processor Will Enable Drives That Both Store and Process Data

Comments Filter:
  • About time (Score:5, Insightful)

    by thsths ( 31372 ) on Sunday September 06, 2020 @08:36AM (#60478832)

    This sounds quite interesting, and has many possible applications.

    Just imagine search: you could tell your hard drives to search for a pattern, instead of transfer all the data that does not match.

    Back in the days, we had Content Addressable Memory (CAM) for that, but it is rarely seen.

    • ZFS pushed down to that level. Or making WinFS now possible.

      https://en.wikipedia.org/wiki/... [wikipedia.org]

    • If you were to combine that with the drive throughput if the new nvme drives they are sticking in the PS5, I would suspect near instant results? When drive r/w starts competing with ram, will we even need ram?

      • by guruevi ( 827432 )

        You can already have TB's of RAM into systems, and some systems do have their entire workload in working memory.

        The reason we have SSD and HDD is cost per TB. So we will always have RAM as making very fast things is not very cheap and vice versa.

        I'm not sure what ARM is advertising here, as some drives already have these capabilities, with, of all things, ARM processors. They aren't generally available as they have to be custom-built for a specific workload and that only makes sense if you can buy hundreds

    • Disks would have to be aware of the filesystem to do that. I imagine these CPUs are pretty slow. They have a small power envelope. I would love to see a disk with a proper CPU to do compression/decompression, encryption, file searches, malware detection, etc.
      • If these chips are made for hard drives, it wouldn't be too hard to add a bit of more application-specific silicon on there. Self-encrypting hard drives are already commonplace with a tiny hardware crypto engine on the drive controller. Why not add compression to that?

        • by Bert64 ( 520050 )

          Compression makes a mess of capacity reporting...
          Drive has 10gb of space, you write 1gb of easily compressible text - how much space is free now?
          What if you try to write 12gb of easily compressible text? Does the drive allow it since once compressed it will take up a lot less space?
          What if you're trying to write 12gb of already compressed video? Does the drive allow it too since it doesn't know how compressible the data is until it receives it? What does the drive do once it's full?
          How does the filesystem h

    • This sounds interesting for commodity hardware, but I don't see much value in the enterprise space. When you're running true end to end nvme the latency is negligible, and typically the drives are operating as a group (raid or something similar) so there's not really much you can do in terms of local data processing regardless.
    • Just imagine inexpensive drives that serve up ads when you need to get to your data.
    • Just imagine search: you could tell your hard drives to search for a pattern, instead of transfer all the data that does not match.

      Commodore 1541, anyone? In any case, mobile agents are often a good idea.

      • The C1541 floppy drive could do this easily because its controller was just another 6502 (hardly ironic considering MOSTek designed it as an embedded controller rather than a general purpose CPU); a friend of mine wrote a demo in 1986 where computing tasks got offloaded to the C1541.

  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Sunday September 06, 2020 @08:40AM (#60478842) Homepage

    In the 1970s ICL sold disk systems that could search: CAFS [wikipedia.org].

    • by Anonymous Coward on Sunday September 06, 2020 @09:36AM (#60479006)

      Add to that the C= 1541 that had a 6502 on-drive. There were copy programs (nibblers) that could be installed on the drive where once you got them started you could disconnect the serial cable and they'd keep chugging along.

      So - License away... be be wary of any patents that ARM might tout.

  • by ClueHammer ( 6261830 ) on Sunday September 06, 2020 @08:46AM (#60478850)
    its a good idea, until it gets hacked... encryption based extortion software that lives on your hard drive, encrypting all your data without cpu intervention. No thanks.
    • by Anonymous Coward
      This is like putting a coprocessor in your intestine to handle the contractions, anal tone, etc. Someone hacks it and you shit yourself or start having massive anal leakage. I guarantee you this thing will have security holes all over it and I'll have ransomware using the processor on my actual hard drive to screw me over.
      • If it runs Linux and if we're allowed to update the firmware then it should at least be possible to update it.

        • If it runs Linux and if we're allowed to update the firmware then it should at least be possible to update it.

          Linux is licensed under the GPL, so if I buy a hard drive with Linux inside, the seller must give me access to the source code and the build procedure. The build procedure is not just compiling the source code but includes loading it into the hard drive.

          • Unfortunately, only a part of this is true.

            The do have to give you the code. The build tools are a bit more hazy.

            Now letting you load a new version, they don't have to do that. They can crypto sign the object code and have a boot loader that prevents modifications. There are actually a lot of reasons they will want to do this. This boot loader does not change the fact you actually did get their GPL code.

            • Re:four freedoms (Score:4, Informative)

              by John_Sauter ( 595980 ) <John_Sauter@systemeyescomputerstore.com> on Sunday September 06, 2020 @11:17AM (#60479312) Homepage

              Unfortunately, only a part of this is true.

              The do have to give you the code. The build tools are a bit more hazy.

              Now letting you load a new version, they don't have to do that. They can crypto sign the object code and have a boot loader that prevents modifications. There are actually a lot of reasons they will want to do this. This boot loader does not change the fact you actually did get their GPL code.

              From section 3 of the GPL version 2:

              The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

              The practice knows as "TIVOization" has been used to prevent the owner of a device from updating its sofrware, even though he has the source code. However, a strict reading of "...the scripts used to control compilation and installation of the executable" would not permit this. If the installation script did not include the code to mark the executable as valid for installation then it is not complete, and thus the distribution is in violation of copyright law, since it does not conform to the license terms under which the manufacturer is permitted to distribute the program.

              • Re:four freedoms (Score:4, Informative)

                by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Sunday September 06, 2020 @11:28AM (#60479358) Homepage Journal

                The practice knows as "TIVOization" has been used to prevent the owner of a device from updating its sofrware, even though he has the source code. However, a strict reading of "...the scripts used to control compilation and installation of the executable" would not permit this.

                No, it absolutely wouldn't. That's why there is a GPLv3 with an anti-Tivoization clause.

                • The practice knows as "TIVOization" has been used to prevent the owner of a device from updating its sofrware, even though he has the source code. However, a strict reading of "...the scripts used to control compilation and installation of the executable" would not permit this.

                  No, it absolutely wouldn't. That's why there is a GPLv3 with an anti-Tivoization clause.

                  You cite only authority for disagreeing with my assertion. Why does "...the scripts used to control compilation and installation of the executable" not forbid TIVOization?

                  • Why does "...the scripts used to control compilation and installation of the executable" not forbid TIVOization?

                    Just because you have the install script, it does not imply that the hardware is configured to be able to execute it. The source can be 100% open but the system still effectively closed. This loophole was one of the motivating factors for the GPLv3 license.

                    • Why does "...the scripts used to control compilation and installation of the executable" not forbid TIVOization?

                      Just because you have the install script, it does not imply that the hardware is configured to be able to execute it. The source can be 100% open but the system still effectively closed. This loophole was one of the motivating factors for the GPLv3 license.

                      If the hardware is not configured to execute the install script (and it cannot be configured correctly by the owner, for example by inserting a jumper or moving a switch) then the script or its documentation is incomplete, and the GPL is violated.

                    • If the hardware is not configured to execute the install script (and it cannot be configured correctly by the owner, for example by inserting a jumper or moving a switch) then the script or its documentation is incomplete, and the GPL is violated.
                      That does not make any sense. Otherwise "cross compiling" would always be a GPL violation.

                    • If the hardware is not configured to execute the install script (and it cannot be configured correctly by the owner, for example by inserting a jumper or moving a switch) then the script or its documentation is incomplete, and the GPL is violated. That does not make any sense. Otherwise "cross compiling" would always be a GPL violation.

                      I don't understand. The compilation instructions for some embedded software might very reasonably involve compiling the source for a different instruction set than the one my workstation uses. Once the compilation is complete, the installation script should allow me to load that result into the device. How is that a GPL violation?

                    • It's not a GPL violation because the GPLv2 doesn't say anything about install scripts, only build scripts. It also doesn't mention crypto keys needed to sign software.

                      Again, THIS is WHY we have a GPLv3. This is well-documented.

                      The Linux kernel continues to be licensed under GPLv2, which means that it can be used in Tivoized applications.

                      If you want to promote Free Software, with freedoms for Users, make sure to use the GPLv3 for software you release, and not just the GPLv2, for this reason.

                    • It's not a GPL violation because the GPLv2 doesn't say anything about install scripts, only build scripts. It also doesn't mention crypto keys needed to sign software.

                      Again, THIS is WHY we have a GPLv3. This is well-documented.

                      The Linux kernel continues to be licensed under GPLv2, which means that it can be used in Tivoized applications.

                      If you want to promote Free Software, with freedoms for Users, make sure to use the GPLv3 for software you release, and not just the GPLv2, for this reason.

                      But the GPLv2 does refer to install scripts, in section 3:

                      The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

                      If the install script needs a crypto key to function, and the key is not provided, then the install script is incomplete.

                      Nevertheless, I take your point that GPLv3 is a better license for those who want their code to not be TIVOized.

                    • Yeah, sorry, I miswrote. I meant to say it doesn't refer to install script assets.

                      It's clear to everyone that producing a binary that won't run on the hardware is contrary to the spirit of the GPL, but sadly that's not what matters most.

                    • Yeah, sorry, I miswrote. I meant to say it doesn't refer to install script assets.

                      It's clear to everyone that producing a binary that won't run on the hardware is contrary to the spirit of the GPL, but sadly that's not what matters most.

                      I contend that it is not only contraty to the spirit but alto to the letter. If I sell you a device with software in it that has been licensed to me under the GPL, if I don't provide the source code, the compilation procedure and a working install script, I am in violation of copyright law, since I am distributing someone else's work without conforming to the license which gives me permission to distribute it. It doesn't matter why the installation script doesn't work--the install script assets are just a

                  • First, though you can build a GPLv2 Linux with whatever changes you make, there is no requirement in v2 that requires the *proprietary* bootloader to boot arbitrary code.

                    • I accidentally clicked Submit too soon.
                      Aside from the fact that a proprietary bootloader may choose not to run your GPL kernel, it would be very poor practice indeed to hard-code your secret key into your install script. Best practice is that the key file should be a should be an argument to the script, not part of the script. Yeah you can argue about that, it's not perfect. A particular judge could decide that issue either way I any specific case.

                      On a more practical level for the kernel, Linus's view is

                    • First, though you can build a GPLv2 Linux with whatever changes you make, there is no requirement in v2 that requires the *proprietary* bootloader to boot arbitrary code.

                      If I purchase a device whose bootloader is designed not to load code which I have modified from the source, then there is no possible installation script, and thus it cannot contain code licensed under the GPL.

                      I accidentally clicked Submit too soon. Aside from the fact that a proprietary bootloader may choose not to run your GPL kernel, it would be very poor practice indeed to hard-code your secret key into your install script. Best practice is that the key file should be a should be an argument to the script, not part of the script. Yeah you can argue about that, it's not perfect. A particular judge could decide that issue either way I any specific case.

                      It doesn't matter if the secret key is in the script or is a parameter to the script which is revealed in the documentation. The important point is that the installation script must be able to install software on the device.

                      On a more practical level for the kernel, Linus's view is that the bargain he offers is "I give you *code*, you give me back any changes you make to the *code*". He figures there are cases in which there is a legitimate reason, a reasonable business model, for selling hardware with locked firmware. As far as he's concerned, rhe deal is code for code and what someone does wirh hardware is none of his business. He's okay with that, and since we're talking about his kernel, it matters that he isn't going to fight that fight.

                      Linus Torvalds is the creator and leader of Linux. That doesn't mean I can't

                    • >> make, there is no requirement in v2 that requires the *proprietary* bootloader to boot arbitrary code.

                      > If I purchase a device whose bootloader is designed not to load code which I have modified from the source, then there is no possible installation script

                      The license requires that you provide me with the script you use to install the software. It does not require that you write a script which will install whatever software I choose to write.

                      You might wish it did, but it doesn't.

                    • Case and point with Android phones.

                      The firmwares are digitally signed. The kernel code is open. You can recompile AOSP all day long. If the device manufacturer does not have a bootloader on the phone that allows you to load your AOSP build, you're forever stuck with *his* digitally signed binary.
                    • >> make, there is no requirement in v2 that requires the *proprietary* bootloader to boot arbitrary code.

                      > If I purchase a device whose bootloader is designed not to load code which I have modified from the source, then there is no possible installation script

                      The license requires that you provide me with the script you use to install the software. It does not require that you write a script which will install whatever software I choose to write.

                      You might wish it did, but it doesn't.

                      Aha, so that is the loophole that permits TIVOization. Thank you.

                    • Case and point with Android phones. The firmwares are digitally signed. The kernel code is open. You can recompile AOSP all day long. If the device manufacturer does not have a bootloader on the phone that allows you to load your AOSP build, you're forever stuck with *his* digitally signed binary.

                      However, if I make no changes to the AOSP sources I should get the same checksum as the device manufacturer's binary, and so should be able to load it. If the toolchain does not give the same checksum for the unmodified source (perhaps because the compilation date is included in the checksum) then I have no assurance that the provided source corresponds to the loaded binary.

                    • Not necessarily. There are furnace signing mechanisms that rely on signature files similar to ssh keys, that the license will never make them give you. Ergo the signature will not match.
                    • Not necessarily. There are furnace signing mechanisms that rely on signature files similar to ssh keys, that the license will never make them give you. Ergo the signature will not match.

                      I don't know what a furnace signing mechanism is, but I think you are saying that the process of creating the signature depends on a key, and the key is not made available to the owner of the device. Thus, I can compile the source with no changes, produce a file with the same hash as the manufacturer's original, but be unable to create the signature and thus unable to load that file into the device. I would regard that as a deficient install script, and thus a violation of the GPL.

                    • Yeah autocorrect strikes again. I meant a build signing mechanism. Again, no, the build script is not faulty if that build key has to be signed with a certificate validated by a restricted set of build systems. Think CAs for binaries.
                    • Yeah autocorrect strikes again. I meant a build signing mechanism. Again, no, the build script is not faulty if that build key has to be signed with a certificate validated by a restricted set of build systems. Think CAs for binaries.

                      How can the build script not be faulty if I cannot install its output without access to the signing process?

                      Let me try to say that without the double negative: For a build-and-install procedure to be valid, it must compile the source and install the result of the compilation in the device. If there is some additional piece I need, like a certificate that is not included, then the procedure is incomplete.

                    • The signing mechanisms are there to prevent hash collisions from allowing someone to pay malicious code out... So it's actually completely legitimate.
                    • > Aha, so that is the loophole that permits TIVOization.

                      You can call it a loophole and I certainly understand that point of view. I really do. Let me also point out another point of view:

                      You want to use my copyright on my *software* as a loophole to force people to create *hardware* that helps you violate Netflix's copyright. Or alternatively, prevent them from having Netflix content since Netflix won't send their content in clear, to be easily copied.

                      That's not part of the deal. I chose a license for

                    • That should be:

                      You wouldn't want me putting in the license "in order to use my text editor, you must use systemd"

                      Even my auto-correct doesn't like systemd. :)

                    • The signing mechanisms are there to prevent hash collisions from allowing someone to pay malicious code out... So it's actually completely legitimate.

                      While it has a legitimate purpose, it makes conforming to the GPL impossible. It is similar to sealing the device so that the internal software cannot be changed. Without an effective installation procedure, you cannot distribute a device that contains someone else's code that has been licensed to you under the GPL.

                    • I use GPLv2 for most of my.released work.
                      My license, the license I choose for my work, doesn't even have the word "hardware" in it anywhere.

                      I didn't say that in order to use my *software*, you have to build a certain kind of hardware. You can use my software on any hardware you want. You can use in an emulator. You can use it on a Neo900, you can use my software on a Librem 5, you can use build your own custom phone from a bare SOC. My copyright license I put on my software doesn't force you to use my c

                    • I guess the ideal for me would be if products were clearly labeled - this DVR is easy to hack, so Disney Plus isn't available. This other DVR is locked down, so Disney makes their content available in this DVR. Then users can choose whatever is important to them.

                      Not knowing what any particular developer thinks avout the issues, I don't know that hijacking their copyright to supported your position is fair and right.

                      I would go one stage further: a manufacturer who wishes to make an unmodifyable device should be limited to software from developers who don't mind their software being used in unmodifyable devices. Given the TIVO loophole (which I don't like, but that's just me) licensing his software under the GPL version 2 is one way a developer can indicate this. A developer who doesn't want his software distributed on unmodifyable devices can choose version 3 of the GPL. Of course, the manufacturer can always write

                    • I use GPLv2 for most of my.released work. My license, the license I choose for my work, doesn't even have the word "hardware" in it anywhere.

                      I didn't say that in order to use my *software*, you have to build a certain kind of hardware. You can use my software on any hardware you want. You can use in an emulator. You can use it on a Neo900, you can use my software on a Librem 5, you can use build your own custom phone from a bare SOC. My copyright license I put on my software doesn't force you to use my choice of hardware to run it.

                      Who the fuck are you to tell Sanjay Vanjani that he's not allowed to use my software on any hardware he wants to use it on?

                      Who are you to tell Sanjay that he has to build hardware for YOUR software? You can change my software however you want to, I chose a license that gives you that freedom. You can run your modified version on whatever hardware you like that's compatible with whatever changes you made.

                      I didn't choose a license that gives you the power to force other people to make hardware to your liking. You can get a Librem or whatever and run my software with whatever changes you want. Nowhere in my license does it say Sanjay Vanjani has to build hardware compatible with whatever changes you later decide to make to my software.

                      It's a software license. The word "hardware" never even appears in the license at all.

                      Personally, I choose to buy Motorola phones, because Motorola supports unlocking and rooting the phones they make. That's why I buy their hardware. My license on my software doesn't force them to do that.

                      In your analysis you are omitting an actor: the hardware manufacturer who distributes your software. He is allowed to use your software on whatever hardware he wants, but if he distributes that hardware, with your software inside it, he must do it in conformance with the terms under which he licensed your software from you. When I purchase the hardware from the manufacturer, I should have certain rights because of the terms of that license. If the manufacturer prevents me from exercising those rights, he

                    • > licensing his software under the GPL version 2 is one way a developer can indicate this. A developer who doesn't want his software distributed on unmodifyable devices can choose version 3 of the GPL.

                      Agreed. Unfortunately, GPLv3 has TWO major changes.
                      To get one, you also get the other, whether you like it or not.

                      Along with adding restrictions on which hardware users of the software are allowed to use, v3 also has a really sneaky, fucked up patent clause that. When read carefully, you realize that it

                    • > licensing his software under the GPL version 2 is one way a developer can indicate this. A developer who doesn't want his software distributed on unmodifyable devices can choose version 3 of the GPL.

                      Agreed. Unfortunately, GPLv3 has TWO major changes. To get one, you also get the other, whether you like it or not.

                      Along with adding restrictions on which hardware users of the software are allowed to use, v3 also has a really sneaky, fucked up patent clause that. When read carefully, you realize that it makes providing a CentOS mirror, or working on any existing GitHub project with the normal workflow, very dangerous for one's employer. You follow the normal workflow of forking a repo and sending pull requests, Oracle can weaponize that to take all of your employer's patents. During the draft stage, I suggested the wording should be fixed to apply to patents related to changes contributed by the company. To my way of thinking, it would be reasonable to say that if you want to make some change the software, you give up any patents *related to that change*. RMS didn't want that. He wanted it such that if a company is involved with GPLv3 code ALL of their patents are at risk. Patents totally unrelated to any open source work they do. Actually even patents they don't even own at the time you.provide a mirror, but are owned by a company that your employer acquires in the future. Because he hates patents and I think he would agree he's an "extremist".

                      Any particular developer may or may not agree with RMS that patents are all evil and horrible. If you agree, you'll have no problem using GPLv3 - if your employer also agrees.

                      For most of the last few years, I've worked in companies large enough that some division somewhere has a patent on something. Therefore I can't contribute to GPLv3 projects.

                      The only patents at risk are those which relate to the software being distributed. Such "software patents" were severely restricted by the Alice decision. For a company to take the position that its employees cannot contribute to software licensed under the GPL because it might own (now or in the future) patents that might be at risk, seems extreme. A better position, in my opinion, would be to not own such "software patents".

                      I do not believe that RMS feels that all patents are evil and horrible, only th

                    • > The only patents at risk are those which relate to the software being distributed.

                      Right, so if you provide a Debian mirror and Oracle wants to kill your patent rather than license it, they just make a commit to any GPLv3 software package in the Debian repo that violates your patent. Voila, you're distributing code that violates your patent, so you've lost your patent. Oracle can do whatever they want with your invention.

                      In my view, that should apply to code you *contribute*, to changes you *make*, no

                    • Let me provide two concrete examples of useful new inventions that I could, perhaps, have patented.

                      The first is of the following form:
                      When someone is trying to log into John's bank account, a great way to make sure it really is John rather than a crook is to ....

                      There is no law of nature that specifies the best ways to do that. If you think there is, I'd be various curious to know which law of physics or of mathematics you think tells us how that must be done.

                      Similarly, the second invention. I hate captch

                    • > The only patents at risk are those which relate to the software being distributed.

                      Right, so if you provide a Debian mirror and Oracle wants to kill your patent rather than license it, they just make a commit to any GPLv3 software package in the Debian repo that violates your patent. Voila, you're distributing code that violates your patent, so you've lost your patent. Oracle can do whatever they want with your invention.

                      In my view, that should apply to code you *contribute*, to changes you *make*, not to anything anyone does which ends up in the distro.

                      If a contribution to a Debian mirror can practice my patent, then it must be a "software patent" which describes code that can be run on a standard computer. Such a patent is probably invalid under Alice, and even if it isn't, it should be. I would cry no tears if Oracle used this technique to make my patent worthless rather than spend years in a court case.

                      Re math, the language of the act is that you can't patent "the laws of nature, including the laws of physics and of mathematics". You can't patent gravity, you can patent a new type of elevator. You can't patent the physical / mathematical law that force on one end of a lever equals force on the other end multiplied by the ratio of their distance from the fulcrum. That is a law of physics and therefore not patentable. You absolutely CAN patent new inventions that use levers and gears! You can't patent "the laws of nature", you absolutely CAN patent useful new things you come up with that make use of the laws of nature!

                      In the examples you give, the things you can patent are inventions, which are physical things.

                      You can't patent the commutative law of addition. You CAN patent a useful new method to detect and block malware that compares the frequency of different machine instructions as well as the ratio of unreachable code (which is there to make it harder for me to reverse engineer what the malware is doing).

                      Here I disagree with you. I do not believe you can pate

                    • Let me provide two concrete examples of useful new inventions that I could, perhaps, have patented.

                      The first is of the following form: When someone is trying to log into John's bank account, a great way to make sure it really is John rather than a crook is to ....

                      There is no law of nature that specifies the best ways to do that. If you think there is, I'd be various curious to know which law of physics or of mathematics you think tells us how that must be done.

                      Similarly, the second invention. I hate captchas. Especially the distorted text ones. Back before Google came out with "click on all the pictures of busses", it was just squiggly text everywhere and it sucked. I thought it would be useful to have a better way, and one night I came up with something that humans do incredibly well, much better than computers do. That led toan invention of the form:

                      A great way for a web site to distinguish between humans vs brute force scripts and spammers is to show a ...

                      Again,what law of physics, biology, or mathematics answers that need? There is no law of nature that says how you must accomplish that task. My solution USED somw cool things about biology and apply some math to make a really cool new system for distinguishing. The system for distinguishing isn't a law of nature. Like a new type of elevator or airplane, it uses the laws of nature.

                      The things you have described are ideas, not inventions. They are good ideas, but they are not patentable. If you write down an idea you can copyright the writing, but that is not the same as a patent. Ideas are not protected by patent law, only inventions.

                      Thomas Jefferson:

                      “He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me.”

                    • > And yet the law, which you quoted, says that mathematics is not patentable.

                      No, not i doesn't. It says the LAWS of nature, including the laws of physics and of mathematics, can't be patented. You might well wish it said that, but it doesn't.

                      Again, you can't patent gravity, you can patent an elevator.
                      Gravity is a law of physics. An elevator is a way to use physics.

                      The commutative property of addition is a law of mathematics, and therefore not patentable. A system for distinguishing people at a distan

                    • > And yet the law, which you quoted, says that mathematics is not patentable.

                      No, not i doesn't. It says the LAWS of nature, including the laws of physics and of mathematics, can't be patented. You might well wish it said that, but it doesn't.

                      Again, you can't patent gravity, you can patent an elevator. Gravity is a law of physics. An elevator is a way to use physics.

                      The commutative property of addition is a law of mathematics, and therefore not patentable. A system for distinguishing people at a distance isn't a law of physics or mathematics.

                      Generally, you can tell the difference because "new and useful inventions" are a) new and b) useful - they are designed to solve a particular human desire. Laws of nature a) aren't new and b) are simply true, they don't have a goal.

                      The actual text of the law (35 U.S.C. section 101) is:

                      Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvements thereof, may obtain a patent, subject to the conditions and requirements of this title.

                      Bitlaw has a good description of what this means, at Patent Requirements [bitlaw.com]. In addition, case law has held that abstract ideas, laws of nature and natural phenomenon are not patentable. To quote the bitlaw web page referred to above, "The Supreme Court in Alice Corp. v. CLS Bank International analyzed these three exceptions in some detail. The "abstract idea" exception to patentable subject matter is particularly important for patents relating to softwar

              • encryption keys hardly fall under copyright law.

                • encryption keys hardly fall under copyright law.

                  Whether or not an encryption key is copyrightable, it must be revealed to the device owner if it is needed to load modified software into the device.

                  • Yes,
                    and there is no law forcing one to reveal them ... that was the point.

                    • Yes, and there is no law forcing one to reveal them ... that was the point.

                      But there is: copyright law.

                      Let's say you write a computer program. That program is automatically copyrighted, with you as the author. You then license that program under the GPL. I include your program in a device that I manufacture and sell. To comply with your license, I must give the purchaser of the device the source code of your program and the scripts needed to compile and install it in the device. If the install script cannot install the software in the device, I am in violation of the license,

                    • I'm not aware that the GPL has such clauses - but not my business. I do not use the GPL.

                    • I'm not aware that the GPL has such clauses - but not my business. I do not use the GPL.

                      Do you write computer programs and make them available for other people to use? If you do, would you like there to be any restrictions on how people can use your software? For example, would you like to be credited as the author? Would you be comfortable if someone used your software to make a lot of money, and didn't offer to share any of it with you? Would it be OK with you if someone improved your software but didn't share those improvements the way you shared the original?

                      Your answers to those quest

                    • Those question I answered 30 years ago.
                      GPL is nothing for me.

                      If you are right, it prevents me to write code for a hardware device and make it tamper proof, because as you say, I have to provide encryption keys. Seriously? That makes no sense at all.

                      If I have to provide encryption keys: everyone, not only the owner, can tamper with the device ...

                      If I write OS (which I rarely do, did not find anyone yet to pay me for it) it will be MiT or BSD licensed, or more likely Apache.

                    • Those question I answered 30 years ago. GPL is nothing for me.

                      If you are right, it prevents me to write code for a hardware device and make it tamper proof, because as you say, I have to provide encryption keys. Seriously? That makes no sense at all.

                      If I have to provide encryption keys: everyone, not only the owner, can tamper with the device ...

                      If I write OS (which I rarely do, did not find anyone yet to pay me for it) it will be MiT or BSD licensed, or more likely Apache.

                      Of course, you are right: if you are writing code for a hardware device that is supposed to be tamper proof, you would not license it under the GPL. My guess is you would not make it publicly available at all, but negociate individual terms with whoever wants to use it.

                      It isn't difficult to write an operating system kernel, if it only has to run on a single instruction set architecture, and there is only a single processor. I've done it twice: Sanders Associates (now a part of BAE Systems) paid me to writ

            • by guruevi ( 827432 )

              The problem is that nobody is interested in enforcing these clauses. Torvalds isn't, the FSF isn't, no kernel programmer actually cares about your rights so you cannot enforce them.

              • The problem is that nobody is interested in enforcing these clauses. Torvalds isn't, the FSF isn't, no kernel programmer actually cares about your rights so you cannot enforce them.

                There are a lot of kernel programmers; I am surprised that you know what all of them care about. Also, the FSF tries to get violators to conform to the GPL rather than sueing them, but that doesn't mean they don't care.

      • by urusan ( 1755332 )

        This is like putting a coprocessor in your intestine to handle the contractions, anal tone, etc. Someone hacks it and you shit yourself or start having massive anal leakage. I guarantee you this thing will have security holes all over it and I'll have ransomware using the processor on my actual hard drive to screw me over.

        You know, the more we figure out about how the gut works, the more likely it seems that there is some kind of co-processing going on in the gut: https://en.wikipedia.org/wiki/... [wikipedia.org]

        Fortunately, the brain and gut are both protected by an air gap, which makes hacking substantially more difficult, though not impossible.

        • The gut already has a security system: In the event it detects toxins, it will attempt to expel the potentially contaminated contents. Forcibly, from both ends.

      • Anal tone? Is that the sequel to Dialtone?
    • There is no need for it to be possible to customise the software running on the hard drive. With a typical GNU/Linux OS, you can install new programs. With Linux running on an HDD, you wouldn't be able to download arbitrary software to it.

  • by ruckc ( 111190 ) <.ruckc. .at. .yahoo.com.> on Sunday September 06, 2020 @08:48AM (#60478858) Homepage

    Oracle in their Exadata systems, have been pushing oracle database query logic down to the storage so it can filter out the blocks returned to reduce load on the database itself.

    Granted I hate giving Oracle any props for anything, much less being first in something, but this time they were there first.

    • With ARM? Isnt ARMs biggest advantage is its minuscule power consumption? Im guessing this chip will sit on the drive itself? Or right behind the M.2 socket? Imagine your M.2 NVMe drive plugged into a usb 3.1(or faster) adapter equipped with this chip. Makes me wonder if it would give any advantages to video editing. Copying data to/from the internal drive so your video editing software can render your assembled edits in realtime can be annoying. If you could dedicate external NVMe storage to that task wit

    • by HiThere ( 15173 )

      This is an implementation of something that has been talked about as a possible improvement since at least the 1970's and probably earlier. The question has always been "Is it technologically practica?" rather than "Is it a good idea in principle?". Just about everyone has agreed that it's a good idea, if we can just smooth out a few rough spots.

      So the question becomes "Have the road blocks been cleared?". And the answer to that question isn't certain. OTOH, a CPU is pretty flexible, and as a chip it's

      • by guruevi ( 827432 )

        This has been possible and has been done for decades, with ARM processors, with XScale processors.

        The problem is that the embedded device has to be tuned for the workload and by the time you develop it and use it any performance benefit will be erased by a 'regular' processor which will have performance caught up by then. At this point, most simply do it on the regular Intel processors, it is very hard to find a need, especially nowadays with NVMe as you're basically connecting your disk directly to your pr

  • ... on storage, doesn't it become... a processor? With storage?

    It's a matter of perspective, really.

    30 years later (having not yet finished writing the program even once) I'm still considering the question:

    In Monopoly, does the player own the properties (i.e. player.properties.list = [propertyA, propertyB, ...]), or are the properties owned by the player (i.e. property.owner = player1)?

    Who knew computers could be about philosophy so much??

    • I would say property.owner = player1 , since that makes checking who iwn a oropery easyer and tgst check is done every time a player moves, whereas the only time the player needs a list of owned properties is when the pkayer needs to sell or mortgage something ( which dies not occur quite as often)
    • Why not both? It really depends on how you are going to use the information in the programs. The concept of a property group may allow one to easily check to see if a player is allowed to buy hotels on properties instead of iterating through all of their properties and seeing if they have the set of properties that make up the group that they are on.The property group would know the properties that belong to it and the properties would know who own them. If all of them are owned by the same player then hote

      • Oh don't get me started on monopolies...!!! ;-p

        But your second sentence is essentially saying what I'm saying: It's a matter of perspective. For that matter, all of computing is like that, if you think about it: 00001001 is just a bunch of ones and zeros - it's not ASC('A'). Unless it is.

        Which pretty much brings me back around to my original point: Isn't a storage device with a processor a computer? Because a processor with storage is....

        • Oh don't get me started on monopolies...!!! ;-p

          But your second sentence is essentially saying what I'm saying: It's a matter of perspective. For that matter, all of computing is like that, if you think about it: 00001001 is just a bunch of ones and zeros - it's not ASC('A'). Unless it is.

          Which pretty much brings me back around to my original point: Isn't a storage device with a processor a computer? Because a processor with storage is....

          (Yeah yeah, 01000001. Damn autocorrect....)

  • by user32.ExitWindowsEx ( 250475 ) on Sunday September 06, 2020 @10:05AM (#60479106)

    So they hired this guy?

    https://spritesmods.com/?art=h... [spritesmods.com]

  • Great. That is about the last thing anybody needs.

  • letting my storage media "process" my data. How about NO, PISS OFF?
  • So this means it has an MMU and at least 32bit of ALU precision?

  • channel I/O and has been available on mainframes as dedicated programmable processors since the late 1950s?

    • by lenski ( 96498 )

      My sentiments exactly, you beat me to it.

      Back in the day, we figured the aggregate "computing power" of the various channels and controllers exceeded the power of the CPU for well-equipped systems. Mainframes were famous for I/O throughput, as well as being famous for having surprising market presence with such ordinary CPUs.

  • 2 nics will make for good ceph drives!

  • by ebrandsberg ( 75344 ) on Sunday September 06, 2020 @11:48AM (#60479414)

    Consider that in many large-scale environments, the disks are in a raid configuration. A file on say ZFS could be spread across multiple disks, and compressed at the same time. At the disk level, there can be very little awareness of what the data is, as there isn't enough context to understand it. As soon as you start using more than one disk for a filesystem, much of this context is gone. For the niche applications that are designed to use it, it will be great, for for the bulk of users, it is moving in the wrong direction.

    • True, but compression could happen on the drive. A mirror set would potentially be even faster to read because the drives could each be picking blocks to read, but one could start at the beginning, the other at the end. You'd assemble the data you wanted faster and can start decompression, decryption or whatever while you wait for the drives to read the remaining blocks to verify the read integrity. For the redundant reads, I guess the drive could just return checksums to save moving so many bytes around wh

  • This has been done for ages, on a larger scale.

    Instead of having one room of supersomputer racks and one room of storage racks, every rack gets to be its own complete box, and you cluster all of them with a good interconnect.

    This is just the tiny, integrated version of that.

    It's nice. But the problem is its specificity. It's not very flexible, and the interconnect can still be a bottleneck. I am unsure how it will be useful in anything but large-scale computing environments for a specific fixed job.

    • If the interconnect is the bottleneck, that's the business case. If the application can communicate with code running on the drive that does anything that's I/O heavy but not CPU-intensive, that reduces traffic and frees it up for transferring whatever has to be processed by the host CPU, GPU, etc

  • This sounds a lot like the I/O channels from '70s mainframes only affordable by mere mortals. Why not, the "toy computers" that replaced mainframes now have actual multi-tasking multi-user OSes with actual security, virtual machines, batch schedulers, etc. Why not I/O channels?

  • I am currently doing some work on data representation formats and serialisation. As far as I know, the biggest compute time cost with reading and writing structured data from/to permanent storage is always raw media read/write speed. This is orders of magnitude slower than data processing such as parsing or composing strings in the CPU. So I am not sure what putting general computing power in storage media buys us.

    I get the idea that systems such as RAID could benefit from storage-local compute power. Maybe

  • Can you imagine a beowulf cluster of these ?

Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau

Working...