ec changed the topic of #elliottcable to: a π―ππ ππ π―πππππππππ π―ππππππ slash sΝΜuΝΝpΝΝeΜΜΊrΜΌΜ¦iΜΌΜoΜΜ¬rΜΜ cΜΝα»₯Μ§ΝαΈ·Μ‘ΝΕ£ΝΜ || #ELLIOTTCABLE is not about ELLIOTTCABLE
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
asecretcat has quit [Quit: let us connect our intestines and mutually digest]
asecretcat has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Max SendQ exceeded]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
<ec>
asecretcat: lmao
<ec>
good luck.
<ec>
idk game things, i'm a boring tooling-programmer.
<ec>
but I love Celeste, like a lot, a lot.
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
muelleme has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
muelleme has quit [Ping timeout: 256 seconds]
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
<asecretcat>
ec: games are my blood.
<asecretcat>
long live the games...
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
cloudhead has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
cloudhead has quit [Ping timeout: 264 seconds]
prophile has quit [Read error: Connection reset by peer]
prophile has quit [Read error: Connection reset by peer]
<joepie91>
cloudhead: Q: how does this solve the original problem of not enough voluntary (monetary) contributions flowing into the open-source ecosystem in the first place?
prophile has joined #elliottcable
<cloudhead>
we're not relying on those so much
<cloudhead>
we're creating demand around participation in project direction/governance basically
<joepie91>
okay, so fundamentally, where does the money come from?
prophile has quit [Read error: Connection reset by peer]
<cloudhead>
in the short term to mid term it's minted
<cloudhead>
in the long term it's companies mainly
prophile has joined #elliottcable
<joepie91>
'companies' in what sense? like, what incentivizes them to put money into said ecosystem?
<joepie91>
(I'm missing the economics part of the explanation on the oscoin site)
<cloudhead>
they benefit from it, they get a say in what gets prioritized for example
<joepie91>
right, so effectively feature voting with money
<cloudhead>
yea kind of
<cloudhead>
but it's done through a concept similar to shares
<joepie91>
that can work economically; if a project is willing to accept the tradeoffs of that (namely, it prioritizes the needs of commercial parties over those of non-commercial parties)
<cloudhead>
exactly
<joepie91>
what I can't see working economically is minting; the tokens don't have any value if there's no other value backing them in some way
<cloudhead>
so the idea is that each project can decide on the tradeoff
<cloudhead>
ex. how much ownership to give away
<joepie91>
so money or other value has to enter the system *somehow* for the tokens to be worth anything
<joepie91>
right
<cloudhead>
yes, and it will
<cloudhead>
because initially we will sell a % of those
<cloudhead>
that will set a starting price for them
<joepie91>
right, but why would people want to buy those?
<cloudhead>
2 reasons
<cloudhead>
1. the token is useful for participating in the network, ex. you need some tokens to open an account and do stuff
<cloudhead>
2. you use the tokens to create organizations, kind of like a naming service
<cloudhead>
ie. to register an org so that it is recognized and synced
<cloudhead>
of course some of that will also be driven by speculation on future value
<cloudhead>
but it's based on the token having utility in the network
<joepie91>
I can't see those aspects bringing sufficient value into the ecosystem unless the cost of entry is prohibitively high, though
<joepie91>
the two points that is
<joepie91>
as for speculation, it's easy to obtain money by attracting people who want to speculate, but I'd also consider that an unethical model :)
<cloudhead>
hmm yeah that's hard to predict
<cloudhead>
yeah that's not the goal
<joepie91>
and there's still one fundamental question
<joepie91>
why does this require a blockchain, ipfs, etc.?
<cloudhead>
the question of "is there enough money at all" is the hardest one to answer
<joepie91>
I mean, theoretically, yes, but the entry fees alone aren't going to be sufficient for it most likely
<joepie91>
the feature voting has much more financial merit in that sense
<cloudhead>
but our bet is that oss is generating X amount of value, and only X/100 is being distributed back to the community
<joepie91>
(although that comes with its own issues)
<cloudhead>
the rest is in profits in megacorps
<joepie91>
right, the problem is that you can't necessarily get access to the other 100-X
<cloudhead>
blockchain is required for a decentralized ledger, to keep track of everyone's ownership of oscoin + ownership in the various orgs
<joepie91>
cloudhead: so for example, have you been following the various threads about corporate donations?
<joepie91>
cloudhead: yes, but why does this need to be trustlessly decentralized?
<joepie91>
trustless decentralization is extremely costly from an operational POV
<cloudhead>
because no one would trust a for-profit business to do this
<cloudhead>
just imamgine
<joepie91>
federated models typically provide a much better cost:benefit tradeoff for decentralized systems
<joepie91>
there's not just 'trustlessly decentralized' vs. 'single centralized business'
<joepie91>
fundamentally what you're building is a concept, not a service
<joepie91>
this could run in a federated manner just fine
<cloudhead>
in some senses it will be federated
<cloudhead>
it's a mix between permissioned/permissionless
<joepie91>
then I don't think you want a blockchain here at all
<joepie91>
it will be unnecessarily costly, both financially and maintenance-wise
<cloudhead>
how do you keep a consistent view of the ledger accross a wide network?
<joepie91>
like, blockchains aren't actually desirable things, they're "last resort" solutions to tricky trustless decentralization problems for cases where you really have no other options and even the expensive option is better than nothing
<joepie91>
this does not sound like such a case
<joepie91>
cloudhead: why is that necessary in the first place?
<cloudhead>
well, I need to know if I have X$ or Y$
<cloudhead>
no matter which node I ask
<cloudhead>
so somehow they have to be strongly consistent
<joepie91>
cloudhead: why do you need a single global view of this?
<joepie91>
why can't there be individual bookkeeping on individual federated systems?
<cloudhead>
well if there isn't one then it's easy to double spend
<joepie91>
no, it's not
<joepie91>
double spending is a blockchain-specific issue
<joepie91>
I'm talking about federation
<cloudhead>
nono
<joepie91>
ie. each node has its own isolated state
<cloudhead>
blockchain tech was created to solve double-spend in a decentralized manner
<joepie91>
if you do not need trustless decentralization, you also don't need a blockchain
<joepie91>
and this is what people tend to overlook
<cloudhead>
right but you always need a certain amount of trustlessness
<joepie91>
blockchains are an incredibly specific solution for an incredibly specific problem that almost nobody has, and in that very specific situation they work well
<joepie91>
it's no different from eg. bittorrent
<cloudhead>
bittorrent cannot work for bookkeeping
<joepie91>
cloudhead: that's not what I meant
<joepie91>
cloudhead: I meant that they're both very specific solutions to niche problems and virtually useless outside of those niche problems
<cloudhead>
oh right I get you
<joepie91>
(this is a general theme with decentralized tech btw, it's not a criticism of the tech)
<cloudhead>
do you have an example of a federated system I can look into?
<cloudhead>
I am not tied to blockchain specifically, but more to the problems I want to solve
<cloudhead>
I think you need some kind of publically verifiable event log though
<cloudhead>
or else you ask people to entirely trust a bunch of nodes
<joepie91>
cloudhead: back, sorry, doorbell
<cloudhead>
and then it's really no different from a centralized system
<joepie91>
cloudhead: just any federated system, or do you mean specifically for OSS funding?
<cloudhead>
no I mean any
<joepie91>
e-mail, XMPP, mastodon :)
<cloudhead>
ah yes, ok I see what you mean
<joepie91>
cloudhead: so the thing with federation is that some degree of trust is always involved; but the point is to make that trust 'portable'
<joepie91>
(assuming you use a third-party node instead of running your own)
<joepie91>
once you distrust a node, you can move to a different node without losing your network participation
<joepie91>
different federated systems are portable to different degrees, but this is the general concept behind it
<joepie91>
so it's not trustless, rather your trust is portable, and in exchange for relaxing the trustlessness requirement you end up with orders of magnitude lower complexity and operational cost
<joepie91>
and much better scalability
<cloudhead>
yeah that makes sense
<cloudhead>
but still one thing I don't understand
<cloudhead>
what happens if I tell node A that I want to spend $100, and I tell node B that I also want to spend $100, and I get services from both
<cloudhead>
but I only have $100 on my account
<cloudhead>
do A and B talk before offering me their service?
<ec>
βEven should the interest wane to nothing, open source software survives still: its life as machine may be suspended, but it becomes as literature, waiting to be discovered by a future generation.β
<joepie91>
cloudhead: it depends on the exact federation model, but it's totally possible that you don't actually have a single 'central account'
<joepie91>
but rather one account per federated service, with limited interaction
<cloudhead>
ah hmm
<joepie91>
so eg. individual nodes may exchange information about what the user is funding for display purposes, but they all have individual bookkeeping
<joepie91>
(then the worst a node can do to the network is lie about the generosity of somebody without actually affecting the project)
<cloudhead>
what if a node is compromised
<cloudhead>
or decides to be malicious
<cloudhead>
and gives other nodes the wrong information
prophile has quit [Read error: Connection reset by peer]
<cloudhead>
I will look into this though, thanks
prophile has joined #elliottcable
<joepie91>
cloudhead: in the example I'm giving - note that this is not the only possible approach! just the simplest one - each node is individually responsible for handling the bookkeeping for each project that uses it (and all the users that fund those projects), and the only 'federated interaction' is of a statistical nature, eg. nodes broadcasting to other nodes that person X just contributed to project Y, and then the worst case for a malicious node
<joepie91>
is that person X *didn't* actually contribute Y but it appears on his 'network-wide' profile anyway
<joepie91>
which is annoying, but not harmful
<cloudhead>
hmm
<cloudhead>
seems like there is a high potential for abuse though as soon as money is involved
<cloudhead>
if it's just e-mail, then yes that works
<cloudhead>
but if there's anything liquid on there
<cloudhead>
like tokens
<cloudhead>
or contributions which can be turned into tokens
<joepie91>
cloudhead: so eg. LibreOffice and Apache might use one node (say, the ossfunding.org service), and then Firefox may use a different node (funding.mozilla.org), and these nodes would exchange information about contributions, but for somebody to contribute to Firefox they'd need to top up an account at funding.mozilla.org and pay through that (most of which can be done transparently in the right interface, but the bookkeeping is still specific to
<joepie91>
funding.mozilla.org)
<joepie91>
cloudhead: right, that's why the simplest option is absolutely no token exchange between services at all
<joepie91>
each service is responsible for handling its own funds
<cloudhead>
right
<cloudhead>
so that's already how I'm thinking about it in a way
<joepie91>
and if Apache goes "oh actually these ossfunding.org people are scammers", they move their project to funding.mozilla.org
<cloudhead>
each org has its own network
<cloudhead>
with its own token
<ec>
prophile: hi, you, too
<ec>
<3
<joepie91>
cloudhead: it's probably more useful to think of it as 'balance', not 'token', otherwise you're going to be designing everything around Ethereum's concept of a token :)
<cloudhead>
haha
<joepie91>
a token is just one possible balance representation
<joepie91>
in the case I'm describing above for example, there'd be no token; just a balance in a DB
<joepie91>
probably in USD or whatever
<cloudhead>
true
<cloudhead>
I think it could work but it's a very different trust model
<cloudhead>
so have to think about that
<joepie91>
yeah, the tradeoffs will definitely be different
<joepie91>
cloudhead: thanks for taking the feedback seriously btw
<joepie91>
that has, uh, not usually been my experience with ICO-y things so far
<joepie91>
:;
<joepie91>
:P*
<cloudhead>
of course, it's solid feedback
<cloudhead>
haha
<cloudhead>
yeah unfortunately the space is overrun by noobs right now
<ec>
yeah I'm a little shocked
<ec>
first off, that anybody I know other than yrashk is stβ uhhhhh, nβ¦aiveβ¦? enough to get into cryptocurrency shit,
<ec>
and then secondly that I just saw a crypto-user *accept criticism* of crypto, what.
* ec
removes hat
* ec
bows
<cloudhead>
lol
<ec>
colour me impressed
<cloudhead>
I was very skeptical too
<cloudhead>
that's why I'm open to other views
<cloudhead>
I've earned my right to be here
<ec>
:3
<joepie91>
cloudhead: oh btw
<ec>
also, 3. that joepie91 so clearly elucidated most of my biggest problems with cryptocurrency shit
<cloudhead>
haha
<joepie91>
cloudhead: very important warning: IPFS is _NOT_ a persistent storage system
<cloudhead>
we're not going for IPFS
<ec>
although he didn't mention the environmental impact of "spent electricity" as a base store of value
<cloudhead>
after I read more about it
<joepie91>
almost everybody gets this wrong, thanks in large part to misleading representation from IPFS itself :(
<cloudhead>
decided against it
<cloudhead>
yeah
<joepie91>
cloudhead: so IPFS isn't *bad* from a tech POV, but you have to understand what it actually is
<ec>
lol joepie91 chewed me out about this too :P
<cloudhead>
they are selling something it isn't
<joepie91>
it's basically bittorrent with a different data representation
<joepie91>
for embedded use
<ec>
I want to use IPFS for a packaging system
<joepie91>
which is, like, totally fine if that's what you need
<joepie91>
but it doesn't magically persist data :P
<cloudhead>
yeah I realised that after doing more research :p
<cloudhead>
need to update the site
<joepie91>
cloudhead: also, fwiw, as far as I'm aware trustlessly decentralized storage is an unsolved problem
<joepie91>
like
<joepie91>
nobody has actually figured out proof-of-storage yet, for example
<cloudhead>
well, filecoin is working on it
<cloudhead>
but yeah
<joepie91>
sure, they're all "working on it"
<cloudhead>
we're not going to solve that
<joepie91>
:)
<joepie91>
there's just a fundamental limitation
<cloudhead>
this is where a certain level of trust is useful
<joepie91>
cloudhead: so the problem with trustless storage is this; you cannot both reliably verify third-party storage *and* not have the data stored yourself
<joepie91>
at least not without re-retrieving the data for every check
<cloudhead>
hashes?
<joepie91>
because if you don't store the data yourself, you can't generate dynamic challenges
<ec>
they can store the hash though
<joepie91>
any static challenges can be collected
<joepie91>
by malicious nodes
<joepie91>
that's the impossibility behind it
<cloudhead>
yeah I guess they could store hashes for every bit of data
<joepie91>
but storing hashes isn't enough
<joepie91>
because then so can a storage node
<joepie91>
and every time you ask for the hash it just feeds you back the hash
<joepie91>
even if it doesn't have the data anymore
<joepie91>
so you need to either:
<joepie91>
1) retrieve all the data every time you want to check, to hash it locally
<joepie91>
2) trust the storage nodes
<joepie91>
or
<joepie91>
3) keep a local copy to generate dynamic challenges from
<joepie91>
so trustless backup can work, trustless storage cannot
<joepie91>
cloudhead: it can just store the pre-image
<joepie91>
there's a variety of attacks you have to deal with, mind; sybil attacks, proxy attacks, etc.
<joepie91>
proxy attacks are especially problematic
<joepie91>
they're an attack where a malicious node requests the actual data from a legitimate node and then forwards it to the requesting client for verification
<joepie91>
or fulfills a challenge
<joepie91>
they're difficult to mitigate and mean that unless you mitigate it, you can't actually have any assurance of having N>1 copies
<cloudhead>
the pre-image is the data itself in this case
<cloudhead>
yeah that's tough
<joepie91>
no matter what way you do it, unless you dynamically generate challenges (eg. "hash from byte X to byte Y"), the node can store precomputed hashes
<cloudhead>
yeah, that's what filecoin is attempting
<cloudhead>
periodic challenges
<joepie91>
cloudhead: emphasis: dynamic
<cloudhead>
yes
<joepie91>
so that the storage node can't know upfront what the challenges will be
<joepie91>
problem: how do you verify dynamic challenges? :)
<joepie91>
without storing the data yourself...
<cloudhead>
:)
<joepie91>
cloudhead: the usual 'clever' answer to this is "precompute a pool of challenges and don't disclose them to the client upfront"
<joepie91>
which is the closest anybody has ever come to solving this
<joepie91>
but it also doesn't work :P
<joepie91>
because one malicious node can exhaust the pool of challenges and share the challenges with other malicious nodes from the same operator
<joepie91>
and wait for a file to be relocated to one of those malicious nodes (eg. when a legitimate node disappears from the network)
<joepie91>
and then receive the data, generate all the challenges, and throw away the data
<joepie91>
and so on and so forth
<joepie91>
tl;dr trustless storage is a nightmare
<cloudhead>
yeah it might indeed be fundamentally impossible to do it "correctly"
<cloudhead>
it's a bit of an observation problem
<cloudhead>
you can only check that the data is there by actually not checking but retrieving all the data
<cloudhead>
one line of thought would be to store diffs locally
<cloudhead>
and store the final hash of original+diff
<cloudhead>
and send those diffs and check the returned hashes
<cloudhead>
but again, the node can contact an honnest node and get the data from there
<joepie91>
yep
<cloudhead>
but that might be expensive
<joepie91>
cloudhead: fwiw, if periodic re-retrieving is acceptable, then a precomputed pool of hashes can be an *acceptable* solution
<joepie91>
it's just not equivalent to the guarantees provided by centralized storage
<cloudhead>
right
<cloudhead>
yeah
<joepie91>
which is where the problem is, all these projects trying to replace centralized storage
<joepie91>
another problem is that a lot of these people don't realize that decentralized systems are always, /always/ more expensive than centralized systems
<joepie91>
due to infrastructure redundancy
<joepie91>
so I've seen a bunch of startups peddling 'store your data decentralized because it's cheaper' which just can't work
<joepie91>
(and it didn't(
<joepie91>
)*
<cloudhead>
hahaha
<cloudhead>
yeah no
<cloudhead>
although I think the future is decentralized, and we'll absorb the costs
<cloudhead>
you know it's like SPECTR etc.
<joepie91>
basically almost nobody in the ICO industry has any clue what they're doing :P
<joepie91>
it's a bit of a shame really
<joepie91>
a bit less hype and it could have attracted a new crop of competent decentralized developers
<cloudhead>
we went performance first without realising we had created a fatal flaw
<cloudhead>
centralization is a little like that
<joepie91>
now almost every serious developer stays the hell away from ICOs because it's a lemon market
<cloudhead>
yeah, but it'll come
<joepie91>
sure, once the ICO hype dies and thousands of people lose their life savings
<joepie91>
:p
<joepie91>
cloudhead: anyway, decentralization is not always desirable, not just from an economic perspective but also from a maintainability perspective
<joepie91>
it's not without reason that centralized systems virtually always win out over decentralized ones in terms of popularity
<joepie91>
decentralized systems are way, way harder to build, because you don't have a central point of trust that you can execute arbitrary code on
<joepie91>
(Ethereum doesn't solve this either because of the fundamental scalability issues)
<joepie91>
it's made worse because you can't performantly keep consistent global state
cloudhea1 has joined #elliottcable
<joepie91>
these are major roadblocks to developers who just want to Build A Thing And Have It Work
<cloudhea1>
sorry am in cafe and they shut me off
<joepie91>
and so decentralized alternatives almost always lag behind their centralized counterparts in terms of usability and featureset, just because it's harder to build stuff
<joepie91>
heh
yrashk has quit []
cloudhea1 is now known as cloudhead_
<joepie91>
cloudhea1: what was the last you read?
<cloudhead_>
I said "it's a hype wave"
<cloudhead_>
and then disconnected
<joepie91>
[12:52] <joepie91> sure, once the ICO hype dies and thousands of people lose their life savings
<cloudhead_>
lol
<joepie91>
[12:52] <joepie91> :p
<joepie91>
[12:52] <joepie91> cloudhead: anyway, decentralization is not always desirable, not just from an economic perspective but also from a maintainability perspective
<joepie91>
[12:53] <joepie91> it's not without reason that centralized systems virtually always win out over decentralized ones in terms of popularity
<joepie91>
[12:53] <joepie91> decentralized systems are way, way harder to build, because you don't have a central point of trust that you can execute arbitrary code on
<joepie91>
[12:53] <joepie91> (Ethereum doesn't solve this either because of the fundamental scalability issues)
<joepie91>
[12:54] <joepie91> it's made worse because you can't performantly keep consistent global state
yrashk has joined #elliottcable
<joepie91>
[12:54] <joepie91> these are major roadblocks to developers who just want to Build A Thing And Have It Work
<joepie91>
[12:54] <joepie91> and so decentralized alternatives almost always lag behind their centralized counterparts in terms of usability and featureset, just because it's harder to build stuff
<joepie91>
</log>
<cloudhead_>
yeah, fully agree
<cloudhead_>
you ideally don't want to be building a decentralized system as an engineer
<joepie91>
pretty much
<joepie91>
insert rant about microservices here
<joepie91>
'distributed system' would be more accurate I guess
<cloudhead_>
yeah
<cloudhead_>
perfect example
<joepie91>
a decentralized system is just a distributed system with more untrusted actors :D
<cloudhead_>
:)
cloudhead has quit [Ping timeout: 268 seconds]
kier has quit [Ping timeout: 268 seconds]
<cloudhead_>
I think yeah especially within a company, stay away from microservices
<cloudhead_>
it's almost always a bad idea
<joepie91>
cloudhead_: but yeah, devs are starting to slowly realize that microservices were a terrible fucking idea, haha
<joepie91>
I'd say "always"
<joepie91>
without qualifications
<cloudhead_>
haha
<joepie91>
for a very specific reason
<ec>
cloudhea1: THUS IT BEGINS
<cloudhead_>
I still have some faith in people knowing what they're doing for some reason
<joepie91>
namely, the concept of 'microservices' itself is about unnecessarily splitting out services
<joepie91>
it's the difference between microservices vs. splitting out services
<cloudhead_>
oh right
<cloudhead_>
I just use the term for both
<joepie91>
the latter is technologically valid; the former is not
<joepie91>
right, I explicitly don't due to the above :P
<joepie91>
cloudhead_: anyway, I'd like to see more decentralized systems... but I also realize that the engineering value just isn't there, so I'm not so convinced that decentralized systems are The Future
<joepie91>
cloudhead_: I think, if anything, tools will come to exist that make it easier to build decentralized trustless systems *where necessaru*
<joepie91>
necessary*
<purr>
that only goes back to, like, 2012, though
<purr>
we had a textual log-file going back to mid 2000's, laying around somewhere sshrug
purr is now known as ec
<cloudhead_>
joepie91: yeah makes sense
<joepie91>
ahh, my 'new' tablet arrived
<cloudhead_>
I don't think they are the future of all systems
<cloudhead_>
only infrastructural ones, the 'commons' essentially
<cloudhead_>
but that's also a philosophical standpoint
<joepie91>
cloudhead_: did you know: the first generation of Lamassu Bitcoin ATMs used Nexus 7 tablets as their screen + CPU
<cloudhead_>
vs. a logical one
<cloudhead_>
hahaha no way
<joepie91>
yep
<cloudhead_>
that's cool
<joepie91>
cloudhead_: I'm currently working on the software for a client
<ec>
I have one of those as the head to my miners
<joepie91>
and I just received my second-hand Nexus 7
<joepie91>
for local testing
<ec>
it doesn't work worth shit
<joepie91>
oh sure
<ec>
anybody want some free bitcoin miners
<joepie91>
they're crap
<joepie91>
the tablets at least
<cloudhead_>
hehe
<joepie91>
well, crap for purposes other than being a tablet
<ec>
they're probably not worth the cost to ship
<joepie91>
cloudhead_: the Nexus Lamassus also run some gentoo distribution with busybox
<joepie91>
telnet access only
<ec>
also they're definitely not worth the hundreds of dollars a month you're gonna spend to power them :P
<joepie91>
horrible things to work with
<joepie91>
cloudhead_: I actually surprisingly managed to remote-debug one over the internet
<joepie91>
they run Node + Chrome in kiosk mode...
<joepie91>
I uh, have Opinions about the choice of technology stack there, but at least I could connect my Chrome instance to it and debug a browser bug remotely
<joepie91>
lol
<joepie91>
it's a pretty fun project, it's just very bizarre hardware to work with
<joepie91>
the newer models use AEEON(?) industrial tablets
<cloudhead_>
hah yeah sounds fun
<joepie91>
they just run Lubuntu
<joepie91>
much easier
kier has joined #elliottcable
<joepie91>
tablet won't turn on, not a great start
cloudhead_ has quit [Ping timeout: 256 seconds]
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
cloudhead_ has joined #elliottcable
ljharb has quit []
ljharb has joined #elliottcable
cloudhead_ has quit [Ping timeout: 260 seconds]
cloudhead_ has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
cloudhead_ has quit [Ping timeout: 255 seconds]
cloudhead_ has joined #elliottcable
cloudhead_ has quit [Ping timeout: 264 seconds]
cloudhead_ has joined #elliottcable
<asecretcat>
ec: haven't played it yet because bad laptop :<
prophile has quit [Read error: Connection reset by peer]
prophile has joined #elliottcable
cloudhead_ is now known as cloudhead
muelleme has joined #elliottcable
muelleme has quit [Ping timeout: 256 seconds]
cloudhead has quit [Ping timeout: 248 seconds]
cloudhead has joined #elliottcable
prophile has quit [Read error: Connection reset by peer]
muelleme has joined #elliottcable
prophile has joined #elliottcable
muelleme has quit [Ping timeout: 252 seconds]
cloudhead has quit [Ping timeout: 248 seconds]
muelleme has joined #elliottcable
muelleme has quit [Ping timeout: 268 seconds]
prophile has quit [Read error: Connection reset by peer]