I have to say there are some extremely talented, creative and productive "software artists" or ICs coming out of France. Not sure if that's a French thing (the Ecoles or whatever) or something else, but it's noticable.
JSLinux
41–50 of 121 posts
Re: JSLinux
#42Fabrice is amazing. The amount of stuff this guy has built is utterly incredible. If I built any one of the things he's built (ffmpeg, qemu, tinyc) I would never stop bragging about it. Instead, he just keeps hacking on other cool stuff.
Yeah why don't we learn what he wants and just give it to him, in return he'll properly rewrite all the broken shit we have. Phones, operating systems, desktop environments, countries, appstores, etc.
I can imagine he wouldn't be interested in any of that. The joy of hacking only emerges when there are no external demands. That's why work sucks and you need to pay people to work for your demands.
Re: JSLinux
#43There aren't many VMs that can run in browser
https://jamesfriend.com.au/pce-js/ (https://github.com/jsdf/pce)
https://www.pcjs.org/ (lots of hardware and OSes) (https://github.com/jeffpar/pcjs)
Mac OS
https://infinitemac.org/ (https://blog.persistent.info/2023/03/infinitemac-dot-org.htm...)
https://jamesfriend.com.au/projects/basiliskii/BasiliskII-wo...
Re: JSLinux
#44Fabrice is amazing. The amount of stuff this guy has built is utterly incredible. If I built any one of the things he's built (ffmpeg, qemu, tinyc) I would never stop bragging about it. Instead, he just keeps hacking on other cool stuff.
Yeah why don't we learn what he wants and just give it to him, in return he'll properly rewrite all the broken shit we have. Phones, operating systems, desktop environments, countries, appstores, etc.
Wait, countries?
Re: JSLinux
#45Earlier quoted context omitted.
On the TinyEMU page? https://bellard.org/tinyemu/
Where can I find the source code and instructions about how to make the Linux distro which runs here?
JSLinux runs any disk image reachable over the network. You can find the Alpine sources over at https://github.com/alpinelinux. The Fedora sources are over at https://src.fedoraproject.org/. I don't think the script to package the pre-built images is documented somewhere, but it's all standard Linux you can install yourself in a virtual machine if you want.
The Windows 2000 sources are probably leaked somewhere on Github, or you could apply for a job with Microsoft maybe. I managed to get ReactOS to boot in JSLinux once by installing it into a standard QEMU image and splitting the image into chunks as required by the emulator code. You need quite a fast CPU to run a full, modern OS at acceptable speeds, though.
Re: JSLinux
#46Considering the extremes of prolific developers gives interesting contrast to dogmas such as "functions/files should never be above x lines", where `quickjs.c` is 50k lines and has functions that are hundreds of lines long: https://github.com/bellard/quickjs/blob/master/quickjs.c (Obviously different approaches suits different circumstances.)
The answer is simple: Bellard can recall all 50K lines of context, while most can't. I too happen to have a larger working memory and only later realized that my threshold for files and functions is way higher than most others. The dogma is only required when the file is to be read and written by multiple people.
https://bellard.org/qemacs/
Has written his own editor, presumably to support preferred working style, using emacs idiom for UI.
Re: JSLinux
#47for now I get a kernel panic due to NoScript. But does this support recursion? I'd like to run JSLinux in my browser and then point its Browser to https://www.bellard.org/jslinux/ which then starts another JSLinux which opens the browser on JSLinux which ... JSLinux isn't another Linux but a landmark of postmodern philosophy, and OP most def forgot to credit Baudrillard. crazy cool.
If you host your own OS image that auto-starts a browser that runs JSLinux and a config file like https://www.bellard.org/jslinux/alpine-x86.cfg, you can create such a link yourself. CORS may be your biggest enemy, there's no reason JSLinux can't do what you're proposing (albeit extremely slowly).
Re: JSLinux
#48Earlier quoted context omitted.
Tbh I've lived already through at least three different dogmas contradicting each other. Those are sometimes behaving like a fashion
I would say that dogmas are normally born out of necessity before they become dogmatic, so it is beneficial to analyze and extract core values out of dogmas instead of entirely ignoring them. In this particular case we can conclude that the threshold should be determined per team , because some team may have a member whose working memory is exceptionally smaller than the average. (Ultimately this shouldn't surprise a…
I never ignored them and usually followed them. They always have reason but sometimes there appears another reason that longs for a solution contradicting the previous dogma.
E.g. monolith -> modular monolith -> microservices
Re: JSLinux
#49- What about a WASM flavor of this, Fabrice? ;)
Re: JSLinux
#50Considering the extremes of prolific developers gives interesting contrast to dogmas such as "functions/files should never be above x lines", where `quickjs.c` is 50k lines and has functions that are hundreds of lines long: https://github.com/bellard/quickjs/blob/master/quickjs.c (Obviously different approaches suits different circumstances.)
The answer is simple: Bellard can recall all 50K lines of context, while most can't. I too happen to have a larger working memory and only later realized that my threshold for files and functions is way higher than most others. The dogma is only required when the file is to be read and written by multiple people.
I have written long methods and will do so again and I wouldn't say it's because I have larger working memory or some other supposedly superior attribute. Some methods are just a long series of steps that you can just write one after another. Reading it from top to bottom is exactly as difficult/confusing/whatever as reading them as separate methods would be (assuming you put short comments in the same places where you would otherwise break it up). I think people just don't want inexperienced programmers to do that because they'll end up with tons of mutable state spanning the whole thing, and it's easier to tell them to break it up into methods than to explain what you mean by mutable state and limited scope.