@koakuma 1:1 is most sensible when one cannot predict all the uses of the monitor.
Otherwise you need to know & plan ahead what you plan to do for ideal results, with some uses suffering greatly as a tradeoff.
@koakuma 1:1 is most sensible when one cannot predict all the uses of the monitor.
Otherwise you need to know & plan ahead what you plan to do for ideal results, with some uses suffering greatly as a tradeoff.
@lauren @SocialistStan@kolektiva.social @Shachihoko @HistoPol @eff @team Are people really stupid enough to still buy that line?
They're stereotypes (https://en.wikipedia.org/wiki/Four_Horsemen_of_the_Infocalypse) for a reason.
@wakame JVM has some major design problems that compromise its applicability for various uses, both embedded and not.
It has a *lot* of very questionable and Java-centric choices.
BEAM is *very* domain-specific and doesn't really care for much outside of its domain.
CLISP's VM is CLISP-only.
Guile's VM is... actually not bad on desktops and supports a bunch of languages. Similarly for Racket/Chez's.
@wakame The funny part is that for the most part, #WASM's applications in the browser are among the least interesting aspects of it.
The general VM uses are a lot more interesting.
Especially the embedded VM variants. #Arduino in #Guile (or #CommonLisp since #ECL has been doing work on WASM support)? More likely than you'd think.
@harold Still greatly amused that miasma theory got that much right.
Though it does make sense that such behavior was observed.
@newt @mjg59 @a1ba OpenGenera had no issue supporting guest languages (https://en.wikipedia.org/wiki/Genera_(operating_system)#Programming_languages), so you're not technically stuck with a single language.
You can make a lot of guarantees insofar as hardware side-channels aren't involved.
Especially when you don't rely on static guarantees and permit for dynamic checking (a whole lot of the theoretical problems for static solutions can be handled this way, although in many cases imperfect heuristics are still required).
@newt @mjg59 @a1ba Incidentally this is part of why Ada SPARK has support for such checks too.
@Pawlicker @mjg59 @newt @a1ba Not sure which incident that is, but it sure looks it was never tested and/or unsafe shortcuts were taken.
Or was that the test device (why not use a simulator? That looked expensive)?
@lanodan @cwebber I see, though I do not see why purposely hobbling your system for the benefit of 3rd-party components written for inferior systems is desirable when you can transparently support them with better external interfaces anyway.
You can implement microkernel RPCs with well-defined structures (instead of very general message-passing), but you don't absolutely have to.
@lanodan @cwebber I'm not quite sure what you mean by this.
Even better than "approaching structured approaches through filesystem-like interaction" (paraphrasing) is simply "using structured approaches and actual structures/objects".
The microkernel depends on address-space separation (via processes typically), so insofar as you don't introduce such separation (which isn't needed if you need references to access anything) you don't have one.
@lanodan @cwebber I'd prefer to wrap those interfaces to rely on something more sane, even if they internally think they're working with something else.
If they're all expecting that less sane interface and it's stable-enough, the wrapping can probably be turned into a few macros with minimal maintenance burden.
@lanodan @cwebber The #CommonLisp #ConditionSystem is more than powerful enough to handle the task just fine.
I do not consider the unstructured text/binary stream approach of Plan9's "everything is a file even more" desirable.
It makes #interoperability a nightmare and any reliable structured use then requires ad-hoc structuring through additional serialization.
@lanodan @cwebber Did you know that #OpenGenera had a #C and an #Ada compiler (among others)?
You don't need to rewrite the drivers, you can just implement a shim (with error handling) so they can run on top of the system in their little isolated bubble like the #rumpkernel idea was about.
You do need those bits in some specific areas, but you can tightly constrain access to them to very specific modules & threads.
Erlang's message-passing approach isn't required for condition handling.
@cwebber Most recently arguing about #microkernels where #Lisp has previously demonstrated the argument about modularity & memory safety to be true (https://catern.com/microkernels.html).
@timixretroplays Is Win9X relying on a bug that got fixed, or is the emulator buggy on Ryzen systems?
@lanodan @winter Yeah, filtering module chains are nicely flexible.
How separated from the implementation are they in practice? Email seems to mostly use pipes/subprocesses for such things.
@lanodan @a1ba If you look at early designs, you actually straight-up can.
@novenary https://danbooru.donmai.us/posts/5485967?q=grs-
Kinda wish this became a named meme tag so I could see more of it.
@kkarhan @Natanox @ada Some caveats at the fuel part that some policies are *very much* being used to tilt things their way (isn't regulatory capture & mass infrastructure destruction follow by motivated car-dependent development great⸮).
The rest about healthy ecosystem & open standards is right though.
Programmer and Free Software proponent.Extra Pins:Software and Assumed Privilege, common problems: https://mastodon.top/@lispi314/111253066257920146Writing Privacy-preserving software & services 101: https://mastodon.top/@lispi314/110849018589421824#Kopimism #FreeSoftware #CommonLisp
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.