Eulora (S.MG) - Taking a Different Sort of Stock



November 5th, 2019 by Diana Coman

The bill of work was set last Thursday in my own words:

...look at them in the light of the new situation: are those sane business choices that help S.MG thrive or are they dangerous ideal choices that will sink S.MG in the end, all the more painfully for the prolongued agony that existing resources can allow? I tell you that I don't quite see what *else* can I do but at the same time, I also don't quite see how can this can be done with any guarantees.

Given the above task and the very issue at hand, I chose to start the work from what I see as hard, *usefulness* requirements for S.MG's tech overall and otherwise server and client sides in particular1:

Server Side

  1. Reliable - the server code2 should do exactly what I expect it to do, not more nor less. Easy to state, harder to guarantee given the whole environment otherwise but this requirement won't go away just because it's not a walk in the park.
  2. Secure - while this is arguably included in "reliable" above, it's worth mentioning it on its own too because Eulora's currency, the ECu, is pegged to Bitcoin and transactions as well as fortunes of players in the game can be quite hefty. Some items can be worth a fortune just by themselves, at least as far as the players are willing to bid to get them.
  3. Stable - Eulora is an always-on game really, there shouldn't be "down" time, no matter how much and what players throw at the server essentially. Some regular and minimal maintenance time3 may be all right but the plan is to keep such things to a very minimum (and predictable!) amount of time.
  4. Deployable in commercial settings - from a purely technical point of view I think I could state this along the lines that the server should be architecture-independent perhaps but this is already a reduction of the actual requirement. Eulora's server code is not meant to be public and as a result, there is the technical as well as non-technical aspect to deployability: it should be deployable in a variety of environments (hardware and software) but it should also keep its secrets, as intended.

Client Side

  1. Reproducible build - given that currently there is only one client and moreover that this one client is going to be whatever I release, I'd much rather have a fixed and reproducible build that won't be fucked up by shitgnomes armed with all sorts of updates. This might be of course not *fully* possible as stated in practice and I don't intend to chase it *more than it's worth* but the direction is there and the more fixed (ie won't need to fiddle with it if you have a different computer than mine) the building process is the better.
  2. Secure and flexible communications with server - see the ECu and Bitcoin at server side above. As the game proceeds effectively through an ongoing communication between client and server, there has to be a way for players to decide on the exact compromise they are happy to live with in terms of security of their communications and associated cost (including costs of all sorts, for instance convenience as well as bandwidth).
  3. Full decoupling of client from server & game version - in particular, there should be basically no pushing of "updates" on the user/client; the client should simply be able to discover and request + download new game content of any sort, as it becomes available on the server (ie the client pulls the updates if/when it wants to).

There could be more added above to both client and server but I think those are the most relevant currently and for the task at hand.

Armed with the above, I started looking at everything Eulora related, on three main directions: hardware dependencies, software dependencies, design decisions.

  1. Hardware dependencies
  2. TRNG (Fuckgoats aka FG)

    The main hardware dependency currently is the FG(s) provided until now by S.NSA and used as source of entropy for all encryption matters on both client and server. I reviewed the item and its design documents that are quite clear and as far as I can tell currently complete. Ideally I would take the time to procure the needed parts and make a few FG myself to be entirely satisfied that S.MG can indeed proceed on the assumption that there is a working TRNG connected at all times. However, the ideal is one thing and practice quite another: so far I haven't actually built an FG and therefore the most I can say at this time is that this latest review of existing items and documents did not reveal any potential trouble that I can see. Moreover, the S.MG code does not make a lot of assumptions about the source of entropy being specifically an FG - this means that changing the source of entropy at a later time should not be problematic for S.MG: the reading of data is isolated and can be replaced without a major overhaul of everything. Based on this, I wouldn't recommend any specific change to the code or approach regarding TRNG at this time.

    Other than the FG, the initial perceived dependency on AMD architecture does not hold: both client and server have been successfully built and deployed on both AMD and Intel computers. While I haven't tried - nor do I have the hardware for such attempts - to further check it on other architectures, I don't think there really is a need at this time for exploring more exotic architectures.

  3. Software dependencies
  4. A significant fixed dependency is on gcc 4.9 (or earlier but so far tested on 4.x versions only) and python 2.x (tested on 2.6 and 2.7 but in principle < 3).

    Both client and server have been successfully built and deployed on the following distributions: CentOS 6 and 7, Ubuntu 14.04, Gentoo (several versions but I'm at a loss as to how to fully pinpoint one down since I'd need to list ALL versions of all packages by the looks of it, ugh). The server has also been compiled and ran on Dulap-Gentoo (aka as proto-cuntoo). It's worth noting that OS versions especially for server side are a potentially troublesome spot if S.MG has to rely on commercially available versions because the preferred versions are increasingly hard to find in the wild (CentOS 6 for instance seems to be set for vanishing from March next year) and new systems bring in a *lot* of changes that are a huge ball of unknown at best (and a complete disaster at worst). Dulap-Gentoo is a frozen snapshot and as such reproducible but essentially a dead-end since there's nothing supporting it.

    It's unclear to me what concrete options does S.MG actually even have regarding OS on server side especially, since there seem to be:

    • Dulap-Gentoo: frozen snapshot, reproducible but dead-end.
    • Cuntoo: frozen snapshot, reproducible but currently as dead-end as Dulap-Gentoo since nobody is/has been working on it for quite a while (and the amount of work required is considered high anyway); it also requires further significant effort to fully move all dependencies to static building and to Cuntoo itself
    • CentOS 6: dead-end as unsupported by anyone and otherwise set to most likely vanish commercially from March 2020.
    • Other distro: at best unknown, most likely incompatible with required versions of gcc & python at the very least.

    Other than OS, the most significant software dependencies are CrystalSpace, Cal3D and MySQL, together with the autoconf/make/jam/ftjam building systems that CS especially depends on4. Those force in turn quite a few other dependencies (CrystalSpace is the champion at how many dependencies it pulls in) but it's worth noting that most of those are on client side (ie ultimately something that is more flexible anyway and up to players rather than S.MG directly). The more troublesome aspect here is the potential clash between versions of everything required, especially in the context of different OS versions (and corresponding python+gcc) than the ones already checked above. One promising direction as far as I would say now is mainly due to using GNAT as it comes bundled with gcc and therefore one could perhaps ride on that even on a different system especially if everything is indeed moved to static linking (see below at design decisions). This is however not fully investigated (ie to which extent it's enough & how it plays along with everything else).

  5. Design decisions
  6. A significant decision was the move towards Ada and GNAT as language and building environment, essentially away from C/CPP and all the auto/make tools. This move is still in progress in that some components (CrystalSpace most notably) still require autoconf and jam/ftjam. I looked again at all of this but I can't see any specific issue or problem in the long term with Ada and GNAT. There is of course the sjlj aspect for which the previous investigation still holds as far as I see. There is also the aspect of GNAT not working on ARM architecture but as far as I can see this is not a significant problem as there is no reason why S.MG should support or be concerned with ARM. If anything, I'd say quite on the contrary, removing concerns about the ARM architecture and its lack of GNAT makes more sense to S.MG (I don't see why should Eulora care specifically about ARM). The ARM architecture was pushed to some extent because of the Rockchips but that is no direct concern for S.MG from my point of view.

    Overall, the move towards Ada and GNAT still seems to me both sane and essentially benefic to S.MG as compilation with GNAT5 is so far way more predictable in all the environments I tried (see above): even when autoconf & co failed because of various version clashes or packages not found, the main advantage with GNAT is that it comes as a standalone package and as such, so far, quite portable. If anything, I'd say that the main rub here is at most in the sense that this has to be moved further even more & faster: the only chance that I currently see for any sort of reliable building process is with GNAT & full set of dependencies at the very least, ideally statically linked as well; we are not there yet (though some steps are done towards that, in particular for Cal3D, server components and client-core) and moving CS to this is going to take quite some time and effort.

    From a structural point of view, there wasn't any direct input from S.NSA given that the originally planned consultation failed to materialise on time. As such, I didn't spend a lot of time re-evaluating the structure of the code base but at any rate, I don't see any specific problems with the current direction there. There is indeed a worryingly big amount of effort still required to get to the point of releasing the new client and thus moving on to next stage but this is unrelated to S.NSA as far as I can see. In terms of the code itself, the parts reviewed more closely are "sane MPI", the UDP lib, Serpent and FFA. As before, it's still the MPI part that I'm most uncomfortable with and that mainly because it's still a recovered artefact of dubious origin and with previously found holes and cockroaches. The UDP lib, Serpent and FFA did not reveal anything I didn't know about and I don't see any problem with them as they are currently on my Reference Shelf.

With respect to FFA Ch1-Ch19, I want to say that I'd rather put it already to use (even in parts if and where that fits) instead of waiting (as I've been waiting even while doing EuCrypt out of necessity) for the next steps and the eventual fruition of a FFA iron or similar. Essentially at this stage the part glowing red for me here is that I sunk some time and effort into FFA and so far S.MG did not directly benefit from it at all so the sane approach would perhaps be to move towards extracting already some benefit from it too. However, there is of course some cost attached now to taking this step of integrating & using bits and parts of FFA.

Mainly for the sake of not leaving stuff out, I feel compelled to add to this list the decision to use V for code released by S.MG so far (e.g. Eucrypt). Here as with FFA, my only concern is more to do with the stalling that seems to have happened for quite a while but that stalling is arguably part of a broader issue. At any rate, if there is something dangerous that I can see here is perhaps just the cumulative effect of all those useful parts that are stalled at one point or another: by the looks of it, S.MG ends up having to push or otherwise support the development of all of them and this is a matter I'd rather discuss in more detail at this stage.


  1. There is of course the other starting point as well, namely the tech, going at it from code up as it were. It's possible and one can even go at it with an initial list of items that used input from Stanislav/S.NSA - though characteristically, it's easier to figure those out from my own Reference Shelf and notes than from anywhere else, his blog included. Nevertheless and especially in this case, I needed to... arm myself, there's no better word for it. Hence first listing the main practical requirements and only then looking at everything and aiming to discern value or lack of it with those hard requirements always in mind. 

  2. Like ALL the code and all the machines, ffs already! 

  3. There used to be such regular maintenance on Wednesday evenings, usually less than 10 minutes of down time. 

  4. Especially on client side there are a LOT of dependencies but 1. those have nothing to do with S.NSA 2. they are ultimately players' concern although currently they have to count for S.MG too given the desired client release. 

  5. Both Adacore's version and Ave1's. 

Comments feed: RSS 2.0

3 Responses to “Eulora (S.MG) - Taking a Different Sort of Stock”

  1. Re: your Serpent component -- in fact was from a public domain graveyard, and your analysis of it pre-dates mine.

  2. Diana Coman says:

    Indeed, thank you. As you might have noticed, the scope is a bit wider here at any rate.

  3. Diana Coman says:

    For my own future reference, the relevant S.MG board discussion:

    diana_coman: as per http://ossasepia.com/2019/11/05/eulora-smg-taking-a-different-sort-of-stock/ I think there are a few points:
    diana_coman: 1. OS issue/choice for S.MG
    diana_coman: 2. FFA use/integration
    diana_coman: 3. cumulative effect of various bits and pieces stuck/stalling
    diana_coman: 4. server(s)
    diana_coman: 5. concrete next steps
    diana_coman: at 4 I mean esp given the fact that the server code is sensitive
    diana_coman: this would be my list, let me know if I should detail any point in there.
    mircea_popescu: i think it works.
    mircea_popescu: are you basically spent in that you've said your piece there and you'djust be stuck reiterating ?
    diana_coman: mircea_popescu: I can add detail if/where needed but atm I don't have something I see to add there.
    mircea_popescu: aite.
    mircea_popescu: so on the 2, to start with that
    mircea_popescu: on one hand, i think it really should not be our preoccupation as s.mg. it's not actually important enough.
    diana_coman: ok.
    mircea_popescu: more broadly what i'm thinking to do is let bvt continue his work on kernelization, because a) the current kernel randomness code is pure shit and b) using a serial interface as the standard is perfectly fine
    mircea_popescu: then as need be use either the historical fg, an upgraded item, or basically speaking ~anything else.
    diana_coman: I very much like bvt's work for sure.
    mircea_popescu: once the kernel has a tty hole in the right place, and the right place is under republican control, i'd say the goal has been done well.
    mircea_popescu: unlike before, where it was done unusably.
    mircea_popescu: this leads us into 1 :
    diana_coman is listening
    mircea_popescu: the choice before me here is strictly to either a) tell bvt to desist, as the kernel is too cool to be touched by our derpy hands ; or else b) have some kinda process to use custom, bespoke, patched kernels.
    mircea_popescu: this is a fact, and i ain't choosing a while calling this republic.
    mircea_popescu: so in this sense s.mg will hafta piggyback.
    diana_coman: not like s.mg hasn't provided service to the republic so far otherwise.
    mircea_popescu: now practically, seems cuntoo is (by far, actually) the least mangy dog in that horse stable, so i guess we're in the business of making it a horse.
    mircea_popescu: can you actually boot the server on cuntoo as things stand ?
    diana_coman: I'm rather relieved to hear that because indeed, cuntoo is the best candidate I see so far
    diana_coman: mircea_popescu: not until I get rid of cs or move it to gnat and build it statically
    mircea_popescu: can you boot the server as things stand at all ?
    diana_coman: mircea_popescu: what do you mean exactly by "boot the server"? (and which one: production or dev?)
    mircea_popescu: well, either, both. you know, run them, what exactly could be involved here ? does your car work or is it just drawn
    diana_coman: mircea_popescu: atm as they are none will boot because none are fully statically linked.
    mircea_popescu: so even if we had hardware you couldn't bring one up ? what was the "testing" in re http://logs.ossasepia.com/log/trilema/2019-10-14#1945429 ?!
    ossabot: Logged on 2019-10-14 14:18:25 diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-13#1945106 - got around to it and can confirm I got it working on Intel too (with minimal changes of kernel config ie selecting Intel rather than AMD flags)
    diana_coman: so if we go that route, this would be the first thing to sort out
    diana_coman: mircea_popescu: that is AMD with dulap-gentoo aka proto-cuntoo aka NOT fully statically linked
    diana_coman: are you confusing amd with cuntoo or what am I confusing here?
    mircea_popescu: ah, and it does boot on ~that~
    diana_coman: mircea_popescu: indeed it does.
    mircea_popescu: i asked if you can boot on cuntoo, you said no. i asked if you can boot at all, you said also no. i verified why no when you said yes prior, turns out you can boot at all, gotta use proto-cuntoo
    diana_coman: mircea_popescu: ah, I missed the "at all" nuance in your second question http://logs.ossasepia.com/log/trilema/2019-11-06#1949741 ie I was still in cuntoo-env
    ossabot: Logged on 2019-11-06 11:31:53 mircea_popescu: can you boot the server as things stand at all ?
    mircea_popescu: aite.
    diana_coman: sorry.
    diana_coman: to fully clarify: I can boot both/either servers on dulap-gentoo on either amd or intel hardware
    mircea_popescu: and you verified you can actually deploy this proto cuntoo on various hw, so we're good here : as to 1, smg will use proto-cutnoo until can switch to cuntoo ; and meanwhile ima see what trinque has to say re cuntoo and try to get bvt to patch against it and so on
    diana_coman: yes; so we keep then to frozen proto-cuntoo with an idea to hopefully be able to move on to cuntoo when that is ready + we have everything statically linking.
    mircea_popescu: you see a better choice ?
    diana_coman: mircea_popescu: my main question here would be whether it's worth this intermediate proto-cuntoo step
    mircea_popescu: worth what ?
    diana_coman: maintaining the frozen dulap-gentoo recipe + all and deploying that + still having afterwards to make the switch to cuntoo when it's ready
    diana_coman: on the plus side, we have something that works so there's no beating that
    mircea_popescu: well... yes, but can you move cs over ?
    diana_coman: mircea_popescu: are we fine with cs as-is on client side? there are 2 aspects there: 1. dynamically linked 2. the dependency on jam/ftjam and all that
    diana_coman: if we need to move it anyway, we need to move it and so ...
    diana_coman: if we might squeeze without, it's a whole lot of effort&time not poured in there
    mircea_popescu: let's not mix the client into this just for a moment
    mircea_popescu: as far as just the server is concerned, does it even use cs for anything ?
    diana_coman: to answer your q as stated: I can move it but it will take a lot of effort and time (atm I don't have a clear estimate for it but I doubt it's less than a month given all deps)
    diana_coman: mircea_popescu: production server "uses" cs because it's intertwined with it (uses data types and the like)
    diana_coman: dev server I was gradually extracting CS out of it but I'm not done
    mircea_popescu: but it's not a proper dependency, just data types nonsense, classes etc, like with the sad "int" nonsense of yore ?
    diana_coman: and otherwise there is no point to using cs on server as far as I can see; wtf does the server need a graphics engine
    diana_coman: mircea_popescu: I would say it's a most improper dependency really
    mircea_popescu: so i suppose this is the first actionable we unveil here : ima want an estimate on a) how long to divorce dev server from cs ; and b) how long to move client cs on cuntoo.
    diana_coman: there would be perhaps some bits like movement calculation but there is no possible reason I can see for that to pull in the whole cs or something ffs; ie it can be done separately, why wouldn't it.
    diana_coman writing those 2 down
    mircea_popescu: but generally, http://logs.ossasepia.com/log/trilema/2019-11-06#1949763 does not to my eye come to much. certainly better than whatever multi-week adventures.
    ossabot: Logged on 2019-11-06 11:41:51 diana_coman: maintaining the frozen dulap-gentoo recipe + all and deploying that + still having afterwards to make the switch to cuntoo when it's ready
    diana_coman: mircea_popescu: there is that, indeed.
    diana_coman: cs is the same btw, there is no client-cs and server-cs
    mircea_popescu: steam TO THIS DAY has recurrent bugs consisting of completely broken installs produced by failing to upgrade its own fucking lbiraries.
    mircea_popescu: they just... ignore it.
    mircea_popescu: gotta consider the environment such as it is.
    mircea_popescu: people don't like it, people come here ask how to help [trilema.com/2018/the-republic-without-mp/][like good doobies], thing's fixed in no time. otherwise people are more then welcome to go fuck their ugly mothers / cluck on facebook until they fall over.
    mircea_popescu: diana_coman, it's the same pile of junk ; but it's very different in terms of utility / justification for impac tin my mind is all.
    diana_coman: mircea_popescu: ah, I see; I suppose the thing is that cuntoo is currently a server-side system really (no X)
    mircea_popescu: i'm not even necessarily sure that i want to push it into the gfx stack.
    diana_coman: so in this sense there's currently little reason to sink time into porting cs
    mircea_popescu: god knows my being an engineer slated for that went instead to be stupid.
    diana_coman: all right; I'm all for *not* taking on yet another pile of wtf
    diana_coman: plenty of those already
    mircea_popescu: i'm also not at all sure i want to dictate os or userland/tooling for people running clients.
    diana_coman: if only people would start running their own clients!
    diana_coman: nobody would dictate them anything for sure.
    mircea_popescu: or if only people would start running in general, as opposed to the current decerebrated snailcircle. w/e.
    mircea_popescu: let's not get ourselves depressed.
    diana_coman: yes; /me read through s.nsa historical reports so got enough of that for today.
    diana_coman: anyways, so proto-cuntoo for server side and there's no futzing needed there
    mircea_popescu: so, basically, the way this is going is, server on protocuntoo for now and cuntoo in the future ; and ~demo~ client on proto-cuntoo and let the community make whatever it wants.
    diana_coman: I will however look into how long it would take to ditch cs on dev server
    diana_coman: but no real need to spend time on looking at moving cs, is there?
    diana_coman: at least not currently.
    mircea_popescu: i would still like an estimate.
    diana_coman: then on the list it goes, all right.
    mircea_popescu: the decision whether cuntoo is to be headless or x-headed has not yet been made.
    diana_coman: mircea_popescu: would the demo client be text-only then or what?
    mircea_popescu: no ?
    diana_coman: proto-cuntoo is text only and frozen
    diana_coman: how would that work?
    mircea_popescu: wait, neither cuntoo has x ?
    diana_coman: neither.
    mircea_popescu: let me restate
    mircea_popescu: so, basically, the way this is going is, server on protocuntoo for now and cuntoo in the future ; and ~demo~ client on ubuntu/whateverthefuck, dynamic hell and let the community make whatever it wants.
    mircea_popescu: better ?
    diana_coman: better.
    mircea_popescu: aite so then moving on from 1
    diana_coman: gladly
    mircea_popescu: didja have anything to say re 3 ?
    diana_coman: mircea_popescu: it might be useful to go through the list of things perhaps
    mircea_popescu: aite
    diana_coman: other than the os since that is at least decided for now, there would be:
    diana_coman: the bootstraping rsa keys
    mircea_popescu: what's the problem there ?
    diana_coman: the moving files in V
    mircea_popescu: wait wait.
    diana_coman: waiting
    mircea_popescu: what's the problem with the rsa bootstrap ?
    diana_coman: mircea_popescu: we have eucrypt that generates the rsa keys and serpent and all that client and server need; we however do not have (and it was supposedly in discussion/waiting/etc) a clear way to store them securely; let me dig log ref
    mircea_popescu: ah yes.
    mircea_popescu: don't bother, i remember.
    diana_coman: the draft is all there is as far as I know
    ossabot: Logged on 2019-01-13 09:29:50 mircea_popescu: ad interim the draft is, that the client stores all the keys (rsa, serpent, whatever) one per line, the rsa ones in republican format, the rest unspecified as of yet, in a file called keys.tmsr encrypted by the rsa key of the client.
    mircea_popescu: the way this is going is that serious player will have dedicated box for eurlora anyways. there's little diff between disk and ram for as long as one uses dedicated box.
    mircea_popescu: thus therefore, keys.txt
    mircea_popescu: any player not happy with this, can provide patches.
    mircea_popescu: whatever, key.tmsr
    diana_coman: so stored in plain text and that's that, correct?
    mircea_popescu: why can't it just use the client key ?
    mircea_popescu: NOT that it makes a difference, the client key will still be there.
    diana_coman: it can but the client key itself ?
    diana_coman: aha, that.
    diana_coman: ie why use the client key if anyway there too, not much to it
    mircea_popescu: this bitch.
    mircea_popescu: look, practically : either we ask the user to remember a password, or else we ask the user to secure a token/
    mircea_popescu: there's not a magic third way.
    diana_coman: tbh (and possibly outside S.MG's direct scope) I don't get exactly why don't we have already a command line replacement to gpg, ugh
    mircea_popescu: because great scientists are discovering great science
    mircea_popescu: with their ass.
    diana_coman: sigh
    mircea_popescu: YEARS they've been at it, and they have earned all this respect with their useful anal work.
    mircea_popescu: back to it, what'd a command line gpg do here ?
    diana_coman: my thought was that if *that* was done, the above bootstrapping thing would have ended up getting more attention and thus possibly moving on as well; but this is why I said possibly outside S.MG scope
    mircea_popescu: myeah.
    mircea_popescu: nope, bitcoin has plaintext wallet for years, something i criticized very harshly.
    diana_coman: there is that sadness too
    mircea_popescu: we'll redo that stupidity, because the cuntheads had other shit to do.
    diana_coman: all right; so at any rate, not an issue for S.MG, it will proceed with how things stand and that's that.
    mircea_popescu: i'm too lazy to search right now for the article where some power ranger shiothead was "offering to reimplement mpex"
    mircea_popescu: where is it, anyway. do you recall it ?
    diana_coman: not atm though it does ring a bell.
    mircea_popescu: hanbot, see if you can find it, iirc was back in mpoe-pr days
    mircea_popescu: diana_coman, people use all sorta lulz, "encrypted drives" whatever nonsense. it's a ridiculous state of affairs, but it's what we god, what can we do.
    BingoBoingo: http://trilema.com/2012/the-bitcoin-drama-timeline/ First item
    diana_coman: tbh this particular bit with the keys was/is the *main* itchy thing because it feels ridiculous really; I'm doing "encryption" there every which way and then the keys are plain text; but wtf.
    mircea_popescu: next item, moving files in v ?! WHAT THE FUCK phf fixed this as the only thing he did in like 3 years.
    mircea_popescu: BingoBoingo, no, not that.
    BingoBoingo: http://trilema.com/2013/why-i-nixed-p2p-colored-coins-and-all-that-jazz/
    diana_coman: mircea_popescu: not as far as I know; it was always *not done* but always popping up in people's memory as "working"; except every time I wanted to *move* a file rather than have it del/add, it turned out that ...no.
    diana_coman: now if someone has the proof I'm being an idiot on this, please step forwards and hit me with it, I'll be very glad.
    mircea_popescu: BingoBoingo, nah, 2015ish item, dork in question was very specifically asciilifeforming all over himself, "oh, will take mp out"
    BingoBoingo: AH
    mircea_popescu: diana_coman, i am greviously unprepared for this.
    diana_coman: granted, this is relatively small snag for S.MG, not like eulora can't go on without it but it's annoying esp because of this "seems to have been done"
    mircea_popescu: we will have to prorogue this issue for some log reading, because wtf.
    diana_coman: ref: http://logs.ossasepia.com/log/trilema/2019-07-21#1924105
    ossabot: Logged on 2019-07-21 08:57:32 diana_coman: hm, current vtools still don't handle move of files or what am I missing here? I made a simple test with moving one file to a different location and as far as I can see, it's still delete + create, no move
    mircea_popescu: yet i recall clearly speccing a "move"
    mircea_popescu: worked admirably well too.
    mircea_popescu: maybe i'm deluded ? will hafta review.
    mircea_popescu: for that matter, is there even an actually working vtron ?
    mircea_popescu: or the usual byproduct of the undisturbed existence of "engineer" cunts, ie, a pile of cvasi-working shitballs ?
    diana_coman: at any rate, my current understanding for S.MG is that it will proceed with what there is and as such the bulk of work stems mainly from the graphics & ironing out the smg comms + new client (plenty there to do but at least I know what I'm looking at)
    diana_coman: mircea_popescu: depends on what you mean by "vtron" ; there is http://ossasepia.com/2018/11/13/v-with-vtools-keccak-hashes-and-its-own-tree/
    diana_coman: that seems to be referenced/found by people and hence used
    mircea_popescu: aite.
    mircea_popescu: basically old mod6 v.pl with new phf vtools guts ?
    diana_coman: mircea_popescu: quite.
    diana_coman: packaged and v-treed.
    mircea_popescu: aite. we shall talk again about move later this week then.
    mircea_popescu: next ?
    diana_coman: those two were most snagging from not-directly-eulora; the rest is mainly the complexity with the graphics & cs
    diana_coman: I still had to dive into CS's "shaders" and so at least I know better what those are and how they come into play but that can be written up as it is and taken from there
    mircea_popescu: wait i said next too soon.
    mircea_popescu: there's also eg http://thetarpit.org/2019/vpl-v-patch-syncing-bug-fix isall this synced ?
    diana_coman: mircea_popescu: this is added on my tree, I didn't yet get to sign it
    mircea_popescu: aite.
    diana_coman: I don't use that init command but at any rate, it's fine as far as I looked at it first pass
    mircea_popescu: now as to 4 : i'd obviously like the server back up as soon as possibru.
    diana_coman takes a note to mirror spyked's sigs too
    mircea_popescu: getting a coupla boxes somewhere in the sense of amateurship so dear to the previously tolerated morons is the least of our troubles.
    mircea_popescu: is the stuff in a shape you want running publicly as we stand ?
    diana_coman: mircea_popescu: the production server has been running before and it can run again as it is; the issue there is really the one concerning access to the code if we just put it ~anywhere.
    mircea_popescu: right.
    mircea_popescu: but in principle, there's no good dev-side reason to delay.
    diana_coman: (the dev server can run but won't do anything for current client)
    diana_coman: strictly tech/dev, no
    mircea_popescu: it's not, in other worse, a case of "wait just this short interval, will do new release" etc
    diana_coman: ah, no; sadly not at all.
    mircea_popescu: aite, well, not like there's any games one can play (i fucking looked, i'm back to playing antique 2000 era stuff, steam's dead, kongregate's dead, everything's fucking dead. half the links on mmorpg.com lead to dead / domain for sale / nonsense items, the other half to steam crap, it's just... gaming's fucking dead, everyone just clucks on derpy facebook fake traffic numbers generators, as fucking if 5k reloads/second
    mircea_popescu: in some dumbphone game equate to trilema article reads)
    mircea_popescu: so im guessing we'll be bringing that up these days.
    mircea_popescu: any preferences re spec ?
    diana_coman: I'll dig them up and get them to you.
    mircea_popescu: aite.
    mircea_popescu: so that's pretty much it, then. anything left out ?
    diana_coman: mircea_popescu: just to make sure re order of my next steps here:
    diana_coman: first I'll do now the estimates re ditching cs from server (dev)
    diana_coman: then re moving cs to static build & gnat
    diana_coman: and after that I go back to client graphics & comms (+server side ofc, but that is waiting on comms protocol atm)
    diana_coman: ofc in between there will be setting the server up whenever we have where
    mircea_popescu: aite. there'll be a brief excursion in there to get the prod server back up, but yes.
    diana_coman: aha.
    mircea_popescu: aite then.
    diana_coman: all right, thank you.

Leave a Reply