mod6: there are only six, seems like they're gonna go quickly.
lobbes: I'm probably too poor, but if it is in my range I'll most likely try and grab one for trb-ing
lobbes: my current trb box I'm planning to run at home is a mystery box someone gave me; troubleshooting all the hardware issues I keep uncovering are delaying things. Would be nice to have two eventually anyhow
esthlos: hanbot et al: my mp-wp seems borked: when trying to make a new post, the "tab" to switch to raw HTML is greyed out and does nothing, and HTML tags are ignored. Also, the visual editing features aren't showing at all. Any ideas?
esthlos: I should add: there's no toolbar to edit text, and nothing is being written to the log
a111: Logged on 2018-04-16 15:20 mircea_popescu: the best example i can think of is the code on the old handheld calculators. THAT is a general purpose os : it makes no assumption about the downstream, merely fully, cleanly and directly exposes the hardware.
mimisbrunnr: Logged on 2018-04-16 15:12 mircea_popescu: i suppose at work might be a confusion between what-some-idiots-might-be-thinking-retroconstructed-on-the-flimsy-basis-of-how-they-behave, where "general purpose os" means "the sprinkle of magic turning the computer from a computer to anything i want it to be, which is to say a tool that magicvally works for any purpose i might come up with, especially the nonsensical and self-contradictory ones".
spyked: http://btcbase.org/log/2018-04-16#1799861 <-- I dun fully grasp this, so bear with me for a moment. suppose the following (imho no-nonsense) thought experiment: say we have an os, NOP-OS, that works as follows: after initialization, the os loads a (user-provided) program P; the NOP-OS interface exposes to P exactly one system call, "no-op", which does nothing and returns. is then NOP-OS a general-purpose OS? say we add another system
a111: Logged on 2018-04-16 15:22 mircea_popescu: whereas the proper definition of "general purpose" is the one mentioned, "which makes no assumptions about the userland".
spyked: call, "exit(code)", which allows P to return control to NOP-OS, so that the user can load another program P'. same question here.
ascii_lander: mircea_popescu: it's in my copy of augustine, lol
ascii_lander: iirc 'make me chaste and continent but not yet'
mircea_popescu: http://btcbase.org/log/2018-04-17#1800909 << wasn't, no. and yes, the ti-89, sure. or my ancient citizen solar powered item which i haven't seen for 15 years at the least but which was revolutionary for its time and literally worked by degrees -- if you obstructed two of its cell it could still slightly power the screen so it did.
a111: Logged on 2018-04-17 08:57 spyked: hm, a111 dead?
mircea_popescu: ascii_lander, to a large degree who said what in early church history is a cockularity poontest.
a111: Logged on 2018-04-17 09:05 spyked: http://btcbase.org/log/2018-04-16#1799861 <-- I dun fully grasp this, so bear with me for a moment. suppose the following (imho no-nonsense) thought experiment: say we have an os, NOP-OS, that works as follows: after initialization, the os loads a (user-provided) program P; the NOP-OS interface exposes to P exactly one system call, "no-op", which does nothing and returns. is then NOP-OS a general-purpose OS? say we
mircea_popescu: if however that os runs on a no-op single instruction cpu, then it is absolutely general purpose.
mircea_popescu: if you modified it so it checked whether the machine temperature is within three degrees of freezing and did not expose the no-op in THAT case, then thereby it would be a general purpose os no longer
mircea_popescu: but instead, it would be a particular-purpose os, "for those cases when the user wants the machine to not be 3 degrees from freezing".
mircea_popescu: http://btcbase.org/log/2018-04-17#1800914 <<< how it manages user interfacing is not even a consideration here. whether it returns control via pushing that specific-sounding button on the back left like the old tim-s ; or whether it has a software call implemented is irrelevant. not from a gui/ux perspoective, of course, but this is the fucking point of systems design as a discipline : that it does NOT consider other discipl
a111: Logged on 2018-04-17 09:05 spyked: call, "exit(code)", which allows P to return control to NOP-OS, so that the user can load another program P'. same question here.
mircea_popescu: ines, and through this separation allows complex, YET STILL SENSIBLE apparata be aggregated.
mircea_popescu: exactly how medicine does not consider whether you were fashionably dressed at the moment of symptoms, to establish whether your sartorial ineptitude maybe upset Sartrus, the god of suits.
mircea_popescu: god knows i have enough trouble as it is remembering what i ate yesterday, if i also had to remember what i was wearing while doing it we could just call it quits.
mircea_popescu: which is exactly what's happening with pre-republican computers.
mircea_popescu: (fun facts for the recently born : 1. most old zx-80 clone programs were games, whether you count by titles, or by total cpu time, or any other way ; 2. they did not return (mostly because to make a good one you had to fuck the kernel space, that zx80 shit was tight), you pressed the reset button to load the next item on the tape.
mircea_popescu: the jury is still out, as far as i'm concerned, on whether the os that loses control of a machine is still an os, meaning it's not altogether clear to me the basic-whatever combo they had at the time actually constitutes an os. but the problem FUCKING ISNT the naive perception at the time, "oh, it didn't hjave icons to click like windows 3.1". windows 3.1 was not an os ; nor was any other windows product an os. microsoft ship
mircea_popescu: ped a "userland package" at all points in its existence, there's no substantial difference between "the office suite" and "windows + the office suite".
trinque: going to reboot the deedbot box; getting about 10kbps out of the thing currently.
trinque: kind of a wonder it's working at all under these conditions
ascii_lander: trinque: out of curiosity -- this is in a heathen dc ? usa ?
spyked: so, taking anotehr shot at this definition: a general-purpose os is an os that cleanly exposes hardware to user programs, without making assumptions about the latter. it's still not immediately clear to me what "cleanly" means, but this'll have to do.
spyked: anyway, this thread put together should make for a decent follow-up piece, i'ma get to it tomorrow.
spyked: http://btcbase.org/log/2018-04-17#1800949 <-- could also be a turing-capable cpu that exposes the instructions natively after the program is loaded. the important part was re what the os itself exposes (or not, in this case) and how this relates to "makes no assumptions about P"
a111: Logged on 2018-04-17 15:05 mircea_popescu: if however that os runs on a no-op single instruction cpu, then it is absolutely general purpose.
mircea_popescu: spyked, cleanly ie, simplest bijective. 1. all items in A are represented in B ; 2. all items in B have an underlying in A ; 3. there is no simpler relation in any case.
mircea_popescu: spyked, perhaps another useful heuristic is the authority problem. if the specification of a user program CAN include a MUST statement, quo warranto ? if "the os", then it is not general purpose.
mircea_popescu: and perhaps worthy of noting here, that the "trend" "emerging" from usg's own "computer security" roadside act cum flea circus, is towards special-purpose os. because that's what they mean by "security".
mircea_popescu: whereas the one user one box tmsr approach sticks with the general purpose os philosophy, and expects spurious color-of-bits considerations to be implemented in the realm in which they belong -- if you want to own the bits own the box, there shall be no legislating here.
spyked: mircea_popescu, I don't see a fundamental problem with special-purpose os (which is why I mentioned "bitcoin node os" as one, though it *could* in principle be implemented as a particular instance of a general-purpose os). embedded hardware (e.g. requiring timing constriants) is full of them.
mircea_popescu: it all comes down to WHAT is the special purpose. mind that the direction the bitcoin node os is taking is towards ~special purpose hardware~. this is very fucking different, whether you have special purpose hardware run by general purpose osen, or whether you have ibm at clone consumershit emulated into republican sanity by usg's flaour of special purpose os.
mircea_popescu: because in the former case, the VARIOUS gposen would still be in fact different from each other.
mircea_popescu: the confounding factor here is pantsuitist outlook, whereby some retard (the user) regards self as meausre of all things and imagines all vectors start from him, and therefore in his boneheaded approach to the world, "general purpose os" means something about him. it fucking doesn't, a general purpose os isn't one joe schcmucktoe can put on a stick and carry around and "it'll work on all computers he encounters".
mircea_popescu: ye olde sld-7001 (check me out, meanwhile i found it!)'s os is GP, notwithstanding it won't run your "intelligent" lawnmower.
spyked: aha, found nothing on hardware and software specs. mircea_popescu, if it's any similar to the calculators I had as a kid, it might not even have any software (all calculator logic implemented using gates)
mircea_popescu: diana_coman, this is too fluid to fix in a comment, and i'd rather have it here than in #eulora. so : let's call eucrypt.serpent X and eucrypt.RSA-OAEP R. now, 1. client wants to log in, R(hello) -> S[erver].
mircea_popescu: at this juncture, server knows "someone" claiming to be A initiated a connection. it should therefore send X(answer) back, where X uses a key that S knows A should have, on the basis of previous comms.
mircea_popescu: if A fails to respond, S will close the connection, practically meaning that A can't claim to be A unless he keeps some X keys about. which is something A-implementers must be aware of.
mircea_popescu: now, if B wants to update his X.keys with the server, he sends them X'd with one of the existing S keys. meaning, again, that if B manages to lose all S's X keys, it lost the account.
mircea_popescu: so implementations MUST keep at least a local and a server X key at all times ; doing otherwise is === deleting the account.
mircea_popescu: this is then the eulora future login handshake : C : hello ; S : new account, here are your keys ; C : here's some keys of mine. they can now continue indefinitely, just as long as nobody loses all the keys.
mircea_popescu: actually, let's make this clearer, it's ambiguous as it stands. C : hello ; S : new account, here are some X keys you can use to decrypt and some X keys you're required to use to encrypt ; C : here's my R key [and here are some X keys i'd prefer to use].
mircea_popescu: which then runs into the obvious problem that i had been chasing all this time : client's R key has to come earlier in the flux. how about the rule that all hello items sent to the server are either a) encrypted to a pre-existing X key or else b) contain a R key ? ie, our helo is not correct as specced.
mircea_popescu: if instead we made it rely on R, there'd be great benefits. consider this alternate model : C : R(hi, this is C.R.key) S : R(here's some X keys for me and for you) C:(actually i'd rather you use these X keys for me).
mircea_popescu: like this, server must not lose its R privkey and clients must not lose their R privkey , but pubkeys of all these can be safely lost, and X keys don't matter at all. seems altogether safer and less friable.
mircea_popescu: now subsidiary for all this : server should generate a batch of X keys and send them to the client every time its store of either S or C X keys drops under a certain value. it's therefore the client responsibility to make sure there's enough keys in store if it doesn't want to pay for key generation. now, what should this threshold be ? 3 ?
mircea_popescu: also important, third question : should the client be permitted to generate X keys for the server ?
ascii_lander reporting live from... inside the cage. fixed the raid oops on smg box; nao partitioning it & copying dulap's gentoo
mircea_popescu: now here's a question on which i'd very much like to hear a lordship oppinion. so, the model currently contemplated for eulora includes a bit whereby the server has to be told by the client a magic string, and will report this back to the client on demand, "here's what you told me you are". the idea is that the client can then sha his binary, and see if the strings match.
mircea_popescu: the reason for this is that games are eminently a domain where people share binaries, a matter of fact established both from general and minigame's own experience. obviously in the sane world of source sharing, v is the correct solution. but if people are going to share binaries, this seems like the only available approach.
mircea_popescu: (one could object, "it's pointless to attempt this, hacked client can just replace magic string", which is true, but nevertheless client can still binary audit his item and see / login with a special, known-good string-test-only client and see what he should be. ie, client can bootstrap himself out of the fakebox produced by a hacked binary.
mircea_popescu: now obviously, this approach wouldn't be nearly as useful for dynamically linked clients ; but i deem the fact that it puts the security incentive on dumping dynamic linking a very good thing.
diana_coman: http://btcbase.org/log/2018-04-17#1801027 --> uhm, for starters this is not correct; initial hello is meant for....initial, no "previous comms" wtf; server needs to reply not with X(answer) but with R(answer) and yes, it needs to know the public rsa key of the account; the creation of accts is still a bit in the air as server needs to get somehow the public key
a111: Logged on 2018-04-17 16:50 mircea_popescu: at this juncture, server knows "someone" claiming to be A initiated a connection. it should therefore send X(answer) back, where X uses a key that S knows A should have, on the basis of previous comms.
mircea_popescu: diana_coman, well, two kinds of helo, yes ? when initiating a connection ; and when initaitng an account.
diana_coman: the idea was that if client loses all his X keys, he can send a hello message again
mircea_popescu: that's what i mean, this is kinda too fluid and i suspect it's because somewhere in my head i conflate two things.
diana_coman: it does seem like you have something else in mind indeed; hm
diana_coman: possibly the "register account" vs "authenticate"
mircea_popescu: diana_coman, in any case strictly speaking, the helo as we spec it does not include R pubkey ; whereas in practice it actually must. but read the whole blob, this is better compiled htan parsed.
diana_coman: server wants to look after clients so they don't end up without keys; it can, sure; all I'm saying is that I don't quite see the reason for this; perhaps other than "clients are idiots, let's at least avoid the case where they end up going hello hello all the time"
mircea_popescu: seems to me the threshold will practically be set at 1 as a matter of absolute necessity. once that is the case, setting it at 3 is in no substantial way different : just as many keys will be used as before, but the setting at 3 forces key creation at a time prior to when keys are needed, which seems to help with resource load spread.
mircea_popescu: diana_coman, kinda 90% of all server code aims to avoid "accidental client ddos".
mircea_popescu: yes, but here's the principle : if server knows something will be needed as a certainty, server should act rather than wait to be called to act. which is why it's a server rather than a client.
diana_coman: uhm, dunno about that certainty there; maybe client doesn't want to keep serpent keys between sessions for all I know
mircea_popescu: (for the oursiders : it is the agreement in minigame boardroom that rsa helo packets from existing clients will be lowest priority, after 1. serpent packets and 2. rsa helo packets from unknown clients. the idea is you keep your serpent keys, and continue your "session" whenever, it's kind of a stateless session)\
diana_coman: re creating account: it obviously needs the client's public rsa and atm that one is nowhere in there, yes; I thought you didn't want them in there because it's not just about "a rsa key" but rather one registered with deedbot sort of thing
diana_coman: so it's not enough that client plonks a key in there
mircea_popescu: (it does away with the "is user logged in". you can pm everyone all the time, they're always logged in anyway).
mircea_popescu: diana_coman, one consideration was that if it includes pubkey it will have to be multipacket and i wanted it to be singlepacket for some now incomprehensible reason.
mircea_popescu: but no, seems the correct approach is to replace 3.1.5 with "rsa pubkey". and ACTUALLY use that as the account id.
diana_coman: rsa pubkey if de-facto account id anyway i.e. identifies uniquely one account, yes
mircea_popescu: i know this isn't how it works now and hasn't been for a long time, but i'm ready to move on!!1
diana_coman: ok, so then there is hello-new-account with the R public key; there are otherwise *only* X messages? and if no X key then ...account lost or can it re-send "new account" and basically retrieve the old one?
mircea_popescu: im thinking it's actually best to have a single helo, with r-pubkey. if it is known to the server then it sends X keys ; if it is not known then... it sends X keys.
diana_coman: certainly; and it goes for the data types too; fwiw I wasn't keen on putting this up precisely because it's a bit in the air as it stands and I expect other issues to emerge at implementation time
mircea_popescu: yes. but hey, this is precisely why god gave us blogs in the first place.
douchebag: Yeah no problem, glad I could bring that to your attention
douchebag: So trinque, what is it exactly that got you interested in programming/networking/sysadmin stuff? What sort of things interested you the most and motivated you to keep learning?
trinque: mmm, got my dad's computer stuck in DOS back in the win95 days playing a game. I was about 7-8? he was away on a trip, so I had 2 days to "fix the computer" or certain asswhippin. found the thing in win.ini or w/e it was, changed it, avoided wrath.
trinque: clicked in my head that "oh, *this* is what the computer is for. change the text, and it does something different."
trinque: that's about it, really. pretty african origin story compared to the 80s kids
diana_coman: http://btcbase.org/log/2018-04-17#1801097 <- mircea_popescu looking at it again from all sides I think the consideration is not necessarily misplaced in itself i.e. multi-packet there does make a mess out of the neat "these are the only *packets* you may ever send"; this being said though, I don't quite see the solution that would *also* preserve the desired "whatever it is, server responds the same: with a set of X keys"
a111: Logged on 2018-04-17 17:55 mircea_popescu: diana_coman, one consideration was that if it includes pubkey it will have to be multipacket and i wanted it to be singlepacket for some now incomprehensible reason.
diana_coman: and at any rate, we end up with a "hello" packet that is the first one, containing version of comms protocol and client id string and all that jazz but *at most* some bits of the key only, followed by... more packets with the remaining, chopped-up public rsa key
diana_coman: alternatively the hello message stays single-packet and uses a keccak hash of the public key (n,e,comment) as "account ID" so 3.1.5; then key is sent via Data packages and basically I need to define another type for RSA public key; server can ask/expect the RSA key *every time* to preserve same answer behaviour or otherwise only if it doesn't know the key