02:14:10 <hansh> where is monerod.exe storing the blocks it syncs?
02:14:57 <hansh> only in-ram?
02:16:30 <hansh> nope, definitely not ram
02:16:35 <jwinterm> hansh, C:\ProgramData\Monero
02:16:37 <jwinterm> or something
02:16:54 <jwinterm>  \ProgramData\bitmonero maybe
02:17:33 <hansh> C:\ProgramData\bitmonero yeah
02:17:34 <hansh> thanks
02:17:41 <jwinterm> np
02:18:08 <hansh> is it basically verifying everything since the beginning of the network?
02:18:19 <jwinterm> yea, exactly
02:18:29 <hansh> and when was the start of the network?
02:18:33 <jwinterm> 2014
02:18:41 <jwinterm> if you run with pruning it will end up ~30 GB
02:18:46 <jwinterm> without pruning ~90 GB
02:21:09 <hansh> and minimum ram requirements for cli wallet?
02:21:13 <moneromooo> It won't verify some stuff for the first 95% or so. Use --fast-block-sync 0 to force verification of everything.
02:37:09 <hansh> does a sender need to know anything about the recipient other than the "public view key" ?
02:38:42 <jwinterm> I think both public view and spend keys
02:38:47 <jwinterm> but I am not a mathologist
02:39:32 <Ymgve> yes, to send you need both public keys
02:42:25 <hansh> hmm slightly confusing, seems a mining pool is only asking for the primary address, is knowing the primary address sufficient to send to someone?
02:43:21 <Lyza> yes
02:44:50 <hansh> so in order to send to someone, you need *either* the "public view key:public spend key" pair, -or- the primary address, does that sound correct?
02:45:30 <hansh> sdfgdgbnh
02:45:53 <Lyza> Just opened a wallet in the CLU it's using <20 MB of RAM
02:46:19 <Lyza> never heard of using pub keys to send to someone but ig you could
02:46:48 <Lyza> I think you'd use the pub keys to generate addresses then send to an address
02:47:31 <hansh> sorry im just confused.. and should probably be in bed anyway
02:48:26 <Ymgve> well, the "address" is a 95-ish character long base58 string
02:48:33 <Ymgve> which contains both public keys
02:48:49 <hansh> oh
02:48:52 <Ymgve> maybe that's what they're asking for
02:49:00 <hansh> yes definitely, thanks
02:49:19 <Lyza> pfft sorry I was thinking of private view key doy
02:49:32 <Lyza> should also be in bed ig
02:50:22 <hansh> the topic says "stay away from minergate", i've been using them a little, but i moved over to herominers.com , anything to say about herominers.com ?
02:52:55 <hansh> is the "address" basically just the 2 public keys concatenated, or is there more to the address than the 2 public keys?
02:55:27 <Ymgve> nope, just two public keys encoded in a slightly weird way
02:55:56 <Ymgve> well, there's also the network ID byte at the start and a checksum
02:56:10 <hansh> oh thank you
02:56:20 <hansh> ... network id?
02:56:42 <Ymgve> yeah, like mainnet, testnet etc
02:57:30 <hansh> ok, i guess there's supposed to be less than 257 of them for the foreseeable future? :p
02:59:41 <hansh> what does this mean, why is it both "54% synced" and "38% synced" at the same time?: Synced X/X (54%, X left, 38% of total synced, estimated X hours left)
03:00:03 <hansh> https://i.imgur.com/9vvtHMQ.png
03:08:12 <nioc> probably % of blocks and estimated % of time completed
03:08:29 <nioc> don't know how reliable the time is
10:15:54 <fullmetalScience> #monero
10:16:06 <fullmetalScience> #monero
10:16:30 <fullmetalScience> wordi #monero
10:16:32 <fullmetalScience> #monero
10:16:45 <fullmetalScience> #monero
10:17:12 <fullmetalScience> wordi #monero
10:17:12 <fullmetalScience> #monero
10:17:18 <fluffypony> fullmetalScience?
10:17:34 <fullmetalScience> wordi #monero
10:17:34 <fullmetalScience> #monero
10:21:19 <manifest> i see
10:23:21 <fullmetalScience> In GUI is there a known bug with Trezor on Mac? Getting 'BridgeTransport enumeration failed:Bridge enumeration failed'
10:23:53 <fullmetalScience> 'No matching Trezor device found. Device specifier: ""'
10:24:06 <fullmetalScience> 'Device connect failed'
10:25:03 <fullmetalScience> This happens on the screen where the HW device is selected, after filling all forms and trying to continue to the next screen.
10:43:04 <selsta> fullmetalScience: do you have the latest trezor firmware?
10:43:13 <selsta> and latest version of trezor bridge?
10:58:37 <fullmetalScience> selsta: Good question. Is the Trezor Bridge even required? On Linux with Monero CLI it works without it.
10:59:19 <selsta> It's not required on all systems. It might be required on Mac.
11:03:07 <fullmetalScience> Hm .. Trezor Wallet (the online one for BTC and others) works. I'll try to gather more info.
11:15:18 <selsta> I would still try installing trezor bridge and latest firmware
11:30:46 <fullmetalScience> I did. With bridge installed it works, which is strange given that it wasn't installed before, but it worked last year (with the previous Monero version).
11:44:54 <selsta> on the same OS?
11:48:32 <fullmetalScience> Same machine and OS.
11:50:52 <fullmetalScience> Although I determined that bridge wasn't installed before solely by what the Trezor site told me. So there's a chance I simply forgot I installed it back then and the site didn't notice an old version being there. Maybe Mac has some logs about installs some where ...
11:54:48 <fullmetalScience> Oh, it actually has and there's an entry for Trezor Bridge dating back to mid of 2019.
11:54:53 <fullmetalScience> So that was probably it. My bad.
12:16:47 <selsta> Trezor bridge should not be necessary theoretically
12:16:59 <selsta> according to the trezor dev
12:17:05 <selsta> but guess there might be a bug
12:20:05 <fullmetalScience> A bug that wants to go a different route than direct USB access?
14:29:56 <Frenn_> what's the meaning of launching monerod in "simple mode" ?
14:32:00 <matthewcroughan_> Frenn_: from the GUI?
14:33:04 <Frenn_> matthewcroughan_: yes but manually like --no-sync
14:33:27 <matthewcroughan_> I don't think there is a CLI "simple" mode
14:33:44 <moneromooo> Is that synonymous ? That's bad. "Simple mode" sounds attractive, and --no-sync is bad.
14:34:15 <moneromooo> --no-sync will not sync the chain, it was meant to allow a node to look for public RPC nodes on the P2P network.
14:34:21 <matthewcroughan_> moneromooo: I synced monerod last night and realised it takes up a crap ton of space lol
14:34:26 <matthewcroughan_> How much does monerod rewrite?
14:34:31 <moneromooo> Oh wait, it'd do that... nvm.
14:34:41 <Frenn_> I don't want to use this, just wanted to understand what is it. Oh ok thanks moneromooo
14:34:50 <matthewcroughan_> In other words, how bad is Monero's DB for an ssd? Does it only write once?
14:35:55 <moneromooo> It writes every time you get a new block, or a new tx.
14:36:05 <matthewcroughan_> what about re-orgs?
14:36:22 <matthewcroughan_> Basically my question is whether it's really that bad for something such as an SD card?
14:36:42 <matthewcroughan_> Raspberry Pi nodes.
14:37:01 <matthewcroughan_> If it only writes once, and *does not* re-write under any circumstances, it may not be that bad.
14:37:58 <moneromooo> The firmware decides what to rewrite.
14:38:15 <moneromooo> monerod writes a lot, nevertheless.
14:38:20 <matthewcroughan_> No I mean does monerod rewrite?
14:38:34 <matthewcroughan_> Does it get things wrong a lot, and thus cause more writes than necessary?
14:38:43 <matthewcroughan_> e.g half-download a block, half-write a block, then give up and try again.
14:39:04 <matthewcroughan_> or does it do all of that in ram, instead of on disk?
14:39:42 <matthewcroughan_> What I would want is for it to do all write intensive operations in RAM, and *never* sync to disk unless it only has to write once.
14:40:20 <matthewcroughan_> i.e not using the disk as ram, unless it really needs to. Even if this slows down sync massively, as to allow RPi-like devices with sd card flash media to last longer.
14:41:06 <moneromooo> That should be in RAM.
14:41:22 <moneromooo> It's the OS's decision what to swap though.
14:41:32 <matthewcroughan_> Yeah but imagine there's no swap configured
14:41:44 <matthewcroughan_> I would hope that monerod works this way already, but I have no idea if it does :D
14:43:06 <selsta> moneromooo: we also have a simple mode that syncs the chain
14:43:17 <hyc> Rpi doesn't have enough RAM
14:43:18 <selsta> the user can select it on first startup
14:43:29 <matthewcroughan_> hyc: what determines the minimum ram requirements?
14:43:47 <hyc> the volume of the blockchain
14:43:59 <matthewcroughan_> why couldn't the node just slow down?
14:44:18 <hyc> a pi is pretty slow
14:44:41 <selsta> syncing on a different device and then moving the blockchain to the raspberry should work
14:44:43 <matthewcroughan_> Indeed, but why is there such a thing as minimum ram requirements? Why couldn't the node just process slower?
14:44:48 <hyc> the software already uses ram optimally
14:45:19 <hyc> it already does exactly that
14:45:49 <matthewcroughan_> There's also  --db-sync-mode=fast
14:46:07 <hyc> there is no hard minimum unless you're mining
14:46:08 <matthewcroughan_>  --db-sync-mode=fastest:async
14:46:47 <matthewcroughan_> So a slow node when mining is goin to leave you with a lot of orphans? Is that right?
14:47:00 <hyc> the default is already async with background flushes
14:47:29 <matthewcroughan_> yes, but the cpu usage is massive, because it =safe instead of =fastest, right?
14:47:41 <hyc> no
14:48:00 <hyc> safe doesn't use more cpu
14:48:07 <matthewcroughan_> oh, I thought it did
14:48:37 <matthewcroughan_> Does --fast-block-sync use the checkpoints.cpp?
14:49:35 <selsta> fast-block-sync uses checkpoints.dat
14:50:19 <selsta> which is different from checkpoints.cpp afaik
14:51:26 <matthewcroughan_> So have the hardware requirements for Monero grown, to run a node?
14:51:53 <selsta> monero has way more usage now
14:52:09 <matthewcroughan_> So the mempool is full more? Or do you mean something else?
14:52:21 <selsta> more transactions per block
14:52:30 <matthewcroughan_> Is there anything for Monero that has been discussed that would allow people to run nodes on more embedded devices, such as a phone or a pi?
14:52:52 <matthewcroughan_> Some sort of lighter node. If at all possible.
14:52:58 <selsta> 15:44 <selsta> syncing on a different device and then moving the blockchain to the raspberry should work
14:53:00 <selsta> does that work?
14:53:11 <selsta> I run nodes on VPS with 2GB ram
14:53:20 <matthewcroughan_> Yeah but they're hacks.
14:53:20 <selsta> raspberry has 4gb afaik, so should work
14:53:41 <matthewcroughan_> MimbleWimble inherantly allows pruning of transactions, for example.
14:53:54 <selsta> MimbleWimble has other tradeoffs
14:54:12 <matthewcroughan_> Is there anything we could do to implement that sort of thing, past a certain date, to make all future transactions prunable with no drawbacks, for example?
14:55:38 <matthewcroughan_> Or better yet, what is the state of second layer networks with Monero?
14:57:23 <matthewcroughan_> Ah is that really Tari? The marketing for Tari seems to change year by year :D
14:57:47 <selsta> This was posted recently https://eprint.iacr.org/2020/1441
14:58:20 <selsta> Tari is not related to this.
14:58:35 <matthewcroughan_> I think the daemons for bitcoin and monero are just too bloated already
14:59:16 <selsta> The daemons?
14:59:29 <matthewcroughan_> the chains, rather, they're so big already.
15:00:48 <matthewcroughan_> If there is no solution for pruning in either base chain, there's going to come a point at which it's just too demanding for regular users to sync
15:00:55 <selsta> 30GB for a pruned monero chain is quite manageable IMO
15:01:22 <matthewcroughan_> Yes, today. But I'm thinking about 5 years later.
15:01:41 <selsta> Storage capacities will also increase in 5 years.
15:01:44 <matthewcroughan_> Today, it took almost no time at all (20 mins) on my gigabit internet, lotsa ram
15:02:25 <matthewcroughan_> Hmm, how does this pruning work?
15:02:29 <matthewcroughan_> I didn't think the chain was pruned.
15:03:29 <selsta> --prune-blockchain
15:03:39 <selsta> do you mean how does it work internally?
15:03:55 <matthewcroughan_> If every node in the world ran with `--prune-blockchain`, what would the consequence be?
15:04:34 <selsta> Pruned nodes keep a random 1/8 of the pruneable data unpruned
15:04:59 <matthewcroughan_> wouldn't it be detrimental to the network for everyone to prune their nodes?
15:05:16 <selsta> so even if all nodes were pruned it would be possible to sync up and verify the blockchain completely
15:05:31 <matthewcroughan_> that's crazy
15:05:35 <matthewcroughan_> did not know that's how it worked
15:05:54 <matthewcroughan_> alright, the state of things is progressing nicely, hah
15:06:33 <matthewcroughan_> so the only real scaling issue for the daemons is storage space
15:06:57 <selsta> 16:05 <selsta> so even if all nodes were pruned it would be possible to sync up and verify the blockchain completely <-- this is assuming that there are enough other nodes out there
15:08:19 <selsta> phones ship with 64-128GB base storage now, I would not worry about storage in 5 years
15:08:45 <matthewcroughan_> They've shipped with that as base storage for the last 6 years
15:08:46 <selsta> obviously depends on usage
15:09:25 <matthewcroughan_> My OnePlus One came with 64GB, that was released in 2014, 6 years ago.
15:09:49 <selsta> iPhone 6 shipped with 16GB base storage
15:09:56 <matthewcroughan_> Apple's cheap
15:10:02 <selsta> iPhone 12 64 / 128GB
15:10:13 <matthewcroughan_> that is absolutely pathetic lol
15:10:16 <matthewcroughan_> I can't believe that
15:10:26 <matthewcroughan_> took them 6 years to catch up haha
15:17:07 <selsta> The largest amount of Monero's chain growth was between once RingCT was introduced.
15:17:43 <selsta> Luckily bulletproofs were developed afterwards which reduced transaction sizes by 80% or so.
15:18:03 <selsta> Now we have CLSAG and in the future Bulletproofs+ which will also reduce chain growth.
15:37:29 <hyc> BP+ is less than 5% improvement tho, right?
15:38:01 <matthewcroughan_> g
15:38:07 <matthewcroughan_> you're not firefox D:
15:38:25 <matthewcroughan_> using a tiling window manager, sometimes you accidentally hit the wrong window lol
15:40:04 <hyc> anyway - devs are on top of things, scaling is well in hand
15:40:15 <hyc> you can still run a node on a pi if you want to. personally I hate Rpis.
15:40:21 <matthewcroughan_> selsta: that eprint.iacr post is great.
15:40:33 <hyc> but my geekbox still works, and a bunch of other arm64 tvboxes I have around the place
15:40:37 <matthewcroughan_> I don't actually see the utility of BTC if Monero scales off chain like that.
15:40:50 <hyc> BTC is a dinosaur
15:40:53 <matthewcroughan_> Not having privacy on the base chain is a massive, massive, understated mistake.
15:41:02 <hyc> and like a dinosaur, it takes a while for the brain to realize itś actually dead
15:41:27 <matthewcroughan_> Maybe people will find out the hard way.
15:41:39 <matthewcroughan_> HMRC is already tracing BTC nicely.
15:49:27 <selsta> hyc: sarang posted some BP+ numbers in #monero-research-lab
15:51:51 <matthewcroughan_> How does Monero compare to BTC in terms of scale, as-is?
15:52:13 <matthewcroughan_> Can it currently handle more capacity? Despite all the privacy features increasing transaction size?
15:53:33 <selsta> Dynamic block size is helping Monero.
15:54:35 <matthewcroughan_> Right, but what I mean to ask is whether BTC is inferior even in terms of scalability, compared to Monero, today?
15:54:58 <matthewcroughan_> Or whether there are enough features packed into BTC Core to be competitive
16:01:39 <hyc> yes, Monero today can handle more capacity than BTC
16:01:49 <matthewcroughan_> Exciting.
16:02:14 <hyc> BTC is still hard-limited to 7tx/s. in practice, it never exceeds 3.5tx/s.
16:02:14 <matthewcroughan_> And with all the benefits of privacy, what reason not to use it? :p
16:02:17 <matthewcroughan_> And better code, maybe..
16:02:50 <hyc> (If you look at the chain during the 2017 bullrun, youĺl never see it exceed 3.5tx/s even with all the mad rush going on)
16:03:49 <matthewcroughan_> So what is Monero's tx/s?
16:04:01 <hyc> limited only by network speed
16:04:14 <matthewcroughan_> what, blocktime?
16:04:27 <hyc> over 1000tx/s back in 2017
16:04:28 <matthewcroughan_> or you mean propogation of txs across nodes?
16:05:14 <hyc> it is naturally faster now with the tx optimiztions done since then
16:05:56 <matthewcroughan_> FreeBSD vs Linux. BTC vs Monero.
16:07:01 <hyc> poor comparison, freeBSD has fewer developers than linux. BTC has more than monero
16:07:14 <hyc> they're just not as progressive
16:07:26 <matthewcroughan_> Yup, just like FreeBSD :D
16:08:06 <hyc> I suspect if corporations invested as much in freeBSD as they did in Linux, the result would be comparable
16:08:20 <hyc> the same is clearly not true for BTC vs Monero
16:08:38 <hyc> since we have already done much more with far less.
16:09:55 <matthewcroughan_> hyc: I don't think so. FreeBSD has lots of investment.
16:10:07 <matthewcroughan_> It's the license difference.
16:10:22 <matthewcroughan_> And not just that, but they just don't want to implement certain technologies like runc containers.
16:10:48 <matthewcroughan_> They believe things must be done in a different way. Which has lead to less corporate adoption. Additionally, those who do use them do *not* contribute back.
16:12:09 <hyc> yes, BSD-style licenses suck
16:12:33 <hyc> they are anti-developer, pro-corporate
16:12:41 <matthewcroughan_> Take a look at games consoles, macOS, netflix. They all use FreeBSD so they can get free shit. Of those, only Netflix has contributed back to the kernel.
16:13:24 <matthewcroughan_> Sorry, I meant BSD, not FreeBSD lol.
16:20:25 <donkeydonkey[m]> <hyc "they are anti-developer, pro-cor"> not really
16:20:52 <donkeydonkey[m]> <hyc "yes, BSD-style licenses suck"> lots of developers like to be able to use source code as is and not make their code open source in the process.
16:21:40 <hyc> which is pure BS
16:21:53 <hyc> they took from the community for their benefit and gave nothing back in return
16:22:24 <donkeydonkey[m]> not true. thats an abstract idea you have. lots of people write code and license it under bsd style. that is giving.
16:22:40 <hyc> if they don't make their code open source in the process, they are not giving.
16:22:54 <hyc> that's not abstract, that's quite concrete.
16:25:25 <hyc> you're talking about two different groups of developers.
16:25:40 <hyc> yes, lots of devs license their code with a FLOSS license
16:25:40 <donkeydonkey[m]> not really true that they are "not giving" if they dont open source their code. they could be giving in a different way. or they could be shitty coders and maybe its good that they dont contribute. or they could give in another way. some coders like to give their code for actual free. licenses where you have to open source your derivative is not fully giving. its giving with a stipulation. and one could argue they are
16:25:40 <donkeydonkey[m]> not giving.
16:26:26 <hyc> devs who exploit open source but don't release their own code in return are not giving, simple as that
16:26:53 <matthewcroughan_> Precisely true.
16:27:07 <matthewcroughan_> Where is the Nintendo Switch code?
16:27:19 <matthewcroughan_> I'd love to understand more about the PS4.
16:27:23 <matthewcroughan_> And the PS5.
16:27:27 <matthewcroughan_> But no, they just took it.
16:30:13 <matthewcroughan_> What about macOS' Darwin kernel? There's PureDarwin, but that took a lot of effort and wasted a lot of people's time.
16:30:21 <hyc> "or they could be shitty coders and it's good that they don't contribute" - this is a laughable excuse
16:30:34 <hyc> if they're shitty coders contributing gives them an opportunity to learn
16:30:58 <hyc> and if whatever they tried to write was important enough that they were motivated to write it, it may also be important enough to someone else
16:31:04 <hyc> who will then come along and improve it
16:31:09 <matthewcroughan_> Linux really shoulda been a MicroKernel though.
16:31:22 <matthewcroughan_> Would lend itself well to the community and GPLv2 aspect of Linux.
16:31:32 <hyc> microkernels suck
16:31:43 <matthewcroughan_> So do vendor drivers that break your shit.
16:31:46 <hyc> performance is all sucked away by IPC
16:32:00 <donkeydonkey[m]> its great to contribute to open source. its just not great to use the law to force people to contribute.
16:32:03 <matthewcroughan_> Some performance is sucked away by IPC.
16:32:43 <hyc> donkeydonkey[m]: the law is already used to prevent people from having access. twisting the law to enforce access seems to me like justice.
16:32:58 <matthewcroughan_> I just do not think it is acceptable that NFS or Intel Wifi can take my system down.
16:33:15 <hyc> vendor  drivers that break shit won't be fixed by microkernels. it gets fixed by better code, which comesfrom open source.
16:33:16 <matthewcroughan_> because of a change some code monkey somewhere made.
16:33:54 <donkeydonkey[m]> plenty of greedy evil corps already steal and derive and keep secret the opensource code that has a license where derivatives are required to open sourced
16:33:59 <matthewcroughan_> hyc: Avoiding errors is *not* the same as stopping these errors from breaking your system by architectural design.
16:34:15 <hyc> donkeydonkey[m]: that's not an excuse
16:34:28 <matthewcroughan_> Avoiding errors is not a good approach. Having errors be inconsequential is a better approach than simply avoiding issues by writing better code.
16:34:40 <matthewcroughan_> In addition, lines of code and bugs is a linear correlation.
16:34:56 <matthewcroughan_> 13,000 lines of code for Minix, 500,000 for Linux. Linux has more bugs, statistically.
16:35:13 <matthewcroughan_> Microkernels are objectively better, but have performance issues like you said. But I want to run one.
16:35:13 <hyc> that's a meaningless statistic
16:35:47 <matthewcroughan_> How?
16:35:49 <hyc> if you add enough drivers to minix so that it has the same breadth of features as linux, it will have a large line count too
16:35:52 <matthewcroughan_> How is it meaningless?
16:36:07 <matthewcroughan_> More lines of code = more bugs. How is this meaningless? Don't you want less bugs?
16:36:08 <hyc> it's meaningless because minix has nowhere near the capability as linux
16:36:17 <matthewcroughan_> It's about as simple as saying more cars = more car accidents.
16:36:35 <hyc> yes but useless
16:36:41 <matthewcroughan_> How is it useless?
16:36:49 <hyc> because the number of people who need cars to get where they're going isn't going to decrease
16:36:56 <matthewcroughan_> Why not?
16:37:10 <matthewcroughan_> I could make the argument that people need cars less now, especially with coronavirus.
16:37:21 <hyc> this is a temporary state
16:37:25 <matthewcroughan_> That's unprovable.
16:37:31 <hyc> lol
16:37:37 <matthewcroughan_> Everything is temporary.
16:37:39 <hyc> this line of discussion is pointless
16:37:49 <matthewcroughan_> Everything's pointless to a nihilist such as yourself :P
16:38:28 <hyc> if you have a population of 150 million drivers, telling them "there'd be fewer accidents if fewer of you drove" is an empty statement
16:38:40 <hyc> unless you can remove the reasons why they need to drive.
16:38:45 <hyc> but you haven't addressed that.
16:38:52 <hyc> so yes, your discussion is pointless.
16:39:27 <matthewcroughan_> Have you not seen NetBSD/Minix3?
16:39:29 <hyc> it's like saying "if we didn't need to breathe oxygen, we could go into space without space suits"
16:39:37 <matthewcroughan_> You can run a lot of NetBSD packages under Minix3.
16:39:48 <matthewcroughan_> It's not that disadvantageous. You make it seem worse than it is.
16:40:02 <matthewcroughan_> It's not even on the same level as car vs bike.
16:41:25 <hyc> read this test result https://www.realworldtech.com/forum/?threadid=197081&curpostid=197081
16:41:26 <matthewcroughan_> hyc: You make a lot of false equivalences :D
16:41:58 <matthewcroughan_> hyc: What does that have to do with microkernels?
16:42:06 <hyc> of all the x86-based POSIX OSs, Linux has the fastest system call interface, fastest context switches
16:42:18 <matthewcroughan_> Yeah, and TempleOS is even faster.
16:42:22 <hyc> MacOS is built on a microkernel you dimwit
16:42:25 <matthewcroughan_> It's like an Atari.
16:42:41 <matthewcroughan_> TempleOS is very easy to crash, Linux is almost as easy to crash.
16:44:36 <matthewcroughan_> hyc: Well I had no idea.
16:44:43 <matthewcroughan_> Don't call me a dimwit D:
16:45:09 <hyc> "TempleOS is a biblical-themed lightweight operating system designed to be the Third Temple prophesied in the Bible." are you f'in kidding me?
16:45:41 <marmulak> it's serious
16:45:46 <matthewcroughan_> I'm looking around and I can't find anything stating that Darwin is a microkernel.
16:45:47 <hyc> don't ask stupid questions like "what does a linux vs macos comparsion have to do with microkernels"
16:46:28 <marmulak> matthewcroughan_: I read some paper or something on its architecture many years ago. I think Darwin is a hybrid kernel where they started with the mach microkernel and added a bunch of monolithic Apple shit to it
16:46:56 <marmulak> so probably not microkernel, for formerly microkernel
16:46:59 <hyc> MacOSX came from NeXT. NeXTOS used Mach as its base, and put a 4.3BSD interface on top
16:47:16 <matthewcroughan_> hyc: Well, you didn't know what TempleOS was
16:47:16 <hyc> it is still a microkernel, with a lot of services isolated into separate kernel processes
16:47:18 <matthewcroughan_> you big stinky
16:49:08 <hyc> also Linux runs a ton of stuff in separate kernel processes these days, so it's not like you can call it monolithic
16:50:21 <matthewcroughan_> hyc: it's not self evident that those perf differences have anything to do with microkernel stuff
16:50:40 <matthewcroughan_> It proves there is a difference. That is all.
16:50:49 <hyc> sure, that's just one forum post
16:51:06 <hyc> there's tons of research tho, any runtime profile will tell the same story
16:51:12 <matthewcroughan_> I'd like to see more detail yeah.
16:51:31 <matthewcroughan_> I'd love to see something pinning the blame on more specific parts.
16:51:43 <matthewcroughan_> Guess we'll never have that since it's not really open source, lol
16:51:45 <hyc> it's the same as the perf difference between SYsV STREAMS vs BSD sockets
16:52:16 <hyc> SysV STREAMS wastes a ton of time queueing messages from one protocol layer module to the next
16:52:27 <hyc> BSD sockets just does direct function calls from IP to TCP to whatever
16:52:44 <hyc> message-passing is slow, inherently.
16:55:02 <hyc> message passing is flexible. SysV STREAMS lets you stack protocol modules in arbitrary order, define new protocols dynamically, etc.
16:55:27 <hyc> but nobody needs that kind of flexibility today, nobody is developing brand new network protocols. they only need performance.
16:56:24 <matthewcroughan_> hyc: Actually, that test you gave me is representative of nothing.
16:56:34 <matthewcroughan_> Compiling Firefox on macOS vs Linux is flawed comparison.
16:56:54 <matthewcroughan_> It is *not* the same amount of work. Both platforms require use of different libraries at build time.
16:57:08 <matthewcroughan_> They are not equivalent load.
16:57:08 <hyc> eh? that test is pretty significant to me, a a software developer
16:57:21 <marmulak> firefox is amazing
16:57:38 <matthewcroughan_> Yeah fair enough, but it's not represenative of the massive difference you want to claim about microkernels.
16:57:42 <hyc> at least 90% of the libraries are identical, because they're all bundled in the firefox source tree
16:58:01 <matthewcroughan_> It's representative of a difference in compile time between macOS and Linux. Not of their kernels, but of the platform differences in compile time due to libraries.
16:58:07 <selsta> > since you can cross-compile the inputs are also identical. Thus the differences are down to low-level libraries (libc, pthread), the kernel and a handful of system utilities such as tar, cp and friends.
16:58:22 <selsta> should be negligible
16:58:24 <hyc> yep
16:58:34 <matthewcroughan_> hmm
16:58:40 <matthewcroughan_> thank you for highlighting that
16:59:38 <hyc> you can eliminate the difference in system utilities if you just run GNU fileutils on both
16:59:59 <hyc> but at that point the differences are in the noise
17:01:54 <matthewcroughan_> hyc: Friend says being tested in a VM makes this flawed.
17:02:04 <hyc> lol
17:03:14 <hyc> you would have to show that the virtual devices are giving different performance for Linux than for some other OS
17:03:47 <hyc> otherwise, you have to accept that both OSs are running in uniform environment.
17:05:53 <matthewcroughan_> No, you just have to prove the results are invalid.
17:06:09 <hyc> invalid why?
17:06:25 <hyc> you have to show that there was an unfair behavior somewhere
17:07:29 <matthewcroughan_> No, you just have to do the test outside of a VM and show differing results.
17:07:33 <matthewcroughan_> That's science.
17:07:39 <matthewcroughan_> What you've provided is a fallacy :D
17:07:55 <hyc> nonsense. but you can certainly repeat the test on real hardware.
17:07:58 <matthewcroughan_> You do *not* have to prove why, you just have to prove difference.
17:08:02 <matthewcroughan_> Science 101
17:08:08 <hyc> turn your PC into a hackintosh, you'll get the same end result
17:08:19 <matthewcroughan_> That's a hypothesis.
17:08:34 <hyc> if you can't explain the difference, then you're just engaging in superstition
17:08:34 <matthewcroughan_> Needs someone to do it.
17:08:46 <matthewcroughan_> That is incorrect. That comes later.
17:09:08 <hyc> cargo cult. "when I do A, B happens. therefore I will always do A."
17:09:14 <hyc> that is not science.
17:09:15 <matthewcroughan_> All you have to do is prove different results from the same instructions outside of a VM.
17:09:21 <matthewcroughan_> That is it. Nothing more, nothing less.
17:09:36 <matthewcroughan_> That will either prove or disprove the validity of the article you linked.
17:10:04 <matthewcroughan_> You've misrepresented what I have just said.
17:10:27 <matthewcroughan_> What I am saying is: If A says B, but C gets different results than A, B must be false.
17:11:13 <matthewcroughan_> That is what I am saying, and that is absolutely the most basic truth in science. It's literally explained by Feynman here, the most popular video I know of on the scientific method. https://www.youtube.com/watch?v=EYPapE-3FRw&t=217s
17:12:31 <hyc> scientific method is a tool, yes. it is not an end in itself. the end is knowledge and understanding. without explanations and understanding, you haven't conducted science.
17:12:47 <hyc> you have collected data.
17:12:49 <hyc> nothing more.
17:15:35 <matthewcroughan_> And by collecting that data, have added evidence to suggest that B is wrong.
17:15:55 <matthewcroughan_> As with blockchain, there is only a confidence in a result, not absolute truth or certainty.
17:18:10 <hyc> close enough. Knowing that gravity on the surface of the moon is 1/6th of the Earth's, I can calculate how much I will weigh on the Moon without having to go there and measure it. With high confidence.
17:18:29 <hyc> Because I understand the difference between the earth and moon's surface.
17:18:58 <matthewcroughan_> And we only have that confidence because of the reproducibility of experiments.
17:19:05 <hyc> Knowing where the potential sources of perf change can arise in a virtual machine, I can predict whith high confidence the difference in behavior between running on real hardware and running in the VM
17:19:10 <matthewcroughan_> Many hundreds of thousands of experiments. Before we sent people to the moon on that basis.
17:19:34 <matthewcroughan_> Rather than one post from realworldtech.com that suggests there is a 30% difference in gravity on the moon.
17:19:36 <hyc> which is why I said to you - point out where the virtual devices will behavoe differently between OSs
17:20:02 <hyc> there's a large body of experience with virtual machines by now
17:20:05 <matthewcroughan_> You'll notice that we don't have to explain *why* gravity is different on the moon
17:20:24 <matthewcroughan_> We only have to say what that difference is, with math, over and over.
17:20:47 <matthewcroughan_> I don't have to prove what's causing it. I only have to disprove this result.
17:21:04 <matthewcroughan_> only then can we hone in on the cause, but it has to happen in this order.