>>62
Tcp/ip/mac/tubes is being used as an example here, same thing can happen with il/ax/neutrinos.
On principle nothing should ever buffer overflow
Overflow was an exaggeration by principle, it's filled stalling the connection then forced freed later killing the connection, making the reliability fail. The higher layer of reliability will keep sending packets it didn't know got sent properly or it could happen in reverse.
Thank fuck the monolith is capable of not crashing the system and allowing other buffers when these buffers get clogged.
Isn't hardware firmware notoriously bad. Really we should have decent hardware I suppose.
Everything written here, gpu firmware developers are underpaid depressed russians with free state sanctioned vondka. Disregard the differentiating passions and worlds of hardware developers firmware developers and software developers have now, defining what's good.
You could fix the ssd firmware or hdd firmware by following bunnie's example or using something like openssd. The hardware is still designed to fail like all consumer garbage, even for "enterprise", "military" and "research".
I'm not wise enough yet to respond to this either. Sorry to disappoint.
How about this more lnuix way then.
#drivers can be seen here like mounts with nonfilesystem logic in them, like procfs and sysfs are but have special unique identifiers. In this example think of the so called hybrid scheduler lnuix has adopted these identifiers that could be programmed like fuse is but in a mircokernel context, now modify the toolchain your using to create a new instance of #ϻ local to the process and register that language's objects and last reserve the standard form #ϻ0 then extend to #ϻ0pid for ipc without a broken 9p. Not sure what you would use other numbers here for but that's the format. Mounting #ϻ0pid would be unprivileged given it's the same user, processes on this system are considered to have full control over others running with the same user.
If it still doesn't make sense, programmer has special mount #ϻ local to the process which contains mutateable and nonmutateable objects from the program. This mount can always be mounted anywhere given the process has the privilege to that directory. If an external program wanted to interact with that programs objects as files it would mount #ϻ0pid given it has the privilege.
It looks like this given the toolchains can handle unicode raw like plan9's can.
Program a.
#include <stdio.h>
#include <unistd.h>
int x = 0;
int add(int y) return y+1;
int divide(int y) return y/2;
void main()
{
int y=add(4);
while (1)
{
printf("x\ny\n");
sleep(1);
}
}
Program b.
(use-modules (srfi srfi-13))
(use-modules (my misc))
(define pid (getjobpid 1))
(define namespace (getnamespace))
(define driver (drivermount ("temporary") (string-join `("#ϻ0" ,pid)) (string-join `("/tmp/" ,namespace "/"))))
(writestdin (string-join `(,driver "x")))
Running.
a&
0
5
echo 9 |b
9
5
mount "#ϻ0$jobpid" "/tmp/namespace/$random"
echo 11 > "/tmp/namespace/$random/main()/y"
9
11
echo 'divide(10)' > "/tmp/namespace/$random/main()/y"
9
5
umount "#ϻ0$jobpid"
echo 'add(7)' |b
8
5Representing objects in a pseudo scheme would of been too vague for this example but you would pass the objects' logic to the #driver from the scheme code and support miniature scheme images. If you wanted this c example to be capable of running new code paths you would support compiled object files as miniature c images.
This isn't an optimal solution, it almost completely disregards security and it's based on predictions for what will get adopted like how these systems have had no real reason for procfs or 9p yet there it is, incase that hasn't been implied.