> nullfs has extensions beyond this in the future. It will serve as a concept to support the creation of completely empty mount namespaces - which is work coming up in the next cycle."
So there might finally be "a mechanism for kernel threads to explicitly relinquish any access to the file system" that the old manual page for pivot_root promised: https://linux.die.net/man/2/pivot_root
There is a pretty significant difference between the way JS is used there and in electron apps.
This might be what you were getting to but I tend to agree with the idea of place all the interaction logic in a high kevel language and get the performance where it's needed.
Electron does not do that and neither does the people developing electron apps most of the time. I doubt many people throwing electron apps together chose to do that so they can put their CPU intensive code in C/C++/Rust/swift, they want to erite everything in JS.
What should happen is the bare minimum needs to be in JS and the rest in an efficient compiled language.
I mean even the browser does that, the DOM API hands off to lower level libraries for multimedia etc.
Does it manage to support floats? I am not sure if those can be safely used in the UEFI environment. (I recall GRUB’s build of Lua being integer-only, and Linux avoiding the use of floating-point arithmetic in kernel mode, but I don’t remember the reason.)
Technically true, in practice using 0 for the bottom element and 1 for the top is a pretty strong convention; justified, for example, by the connection to probability measures and isomorphism with the Boolean ring ℤ/2ℤ.
If you want to make an argument for something else being the representations of boolean variables than 0 for false and 1 for true, one could make the case for true being all bits set.
That would make it slightly easier to do things like memset()'ing a vector of boolean, or a struct containing a boolean like in this case. Backwards compatibility with pre-_Bool boolean expressions in C99 probably made that a non starter in any case.
A 1-bit integer can be interpreted as either a signed integer or as an unsigned integer, exactly like an integer number of any other size.
Converting a 1-bit integer to a byte-sized or word-sized integer, by using the same extension rules as for any other size (i.e. by using either sign extension or zero extension), yields as the converted value for "true" either "1" for the unsigned integer interpretation or the value with all ones (i.e. "-1") for the signed integer interpretation.
So you could have "unsigned bool" and "signed bool", exactly like you have "unsigned char" and "signed char", to choose between the 2 possible representations.
> What I would like to see is the ability to put a <pre-cache href="url"><![CDATA[...]]></pre-cache> that would allow the document to replace requests for url with the embedded data
As to why I prefer one thing that doesn’t exist over another thing that doesn’t exist depends on my priors. You might as well be asking my opinion and making fun of it before you know the answer.
What do you think the impact would be if Content-Location: would be if it suddenly gained the interpretation I suggest?
What do you think a script in the package can do to reference a part of the URL is constructed by code?
Source?
reply