channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=5&d=6

Sunday, 6 May 2018

00:00:00 --- log: started osdev/18.05.06
00:08:51 --- join: DusXMT (~dusxmt@84.245.121.33) joined #osdev
00:16:53 --- join: Naergon (~Naergon@unaffiliated/naergon) joined #osdev
00:20:59 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
00:22:30 <doug16k> gamozo, xsave is certainly faster
00:23:25 --- join: xerpi (~xerpi@150.red-83-45-192.dynamicip.rima-tde.net) joined #osdev
00:24:00 <doug16k> why? 1) xsaveopt will not write out registers that have not been modified since the last xrstor, 2) it will not write out zero registers - it will represent zero registers with a bitmap
00:24:28 --- quit: xerpi (Remote host closed the connection)
00:24:29 <doug16k> if you xrstor, run a thread, xsave, and that thread didn't modify any sse registers, it will elide the stores
00:24:38 <doug16k> er, xsaveopt
00:24:42 <gamozo> yeah
00:24:49 <gamozo> but normal xsave/xrstor are dumb aren't they?
00:24:53 --- join: xerpi (~xerpi@150.red-83-45-192.dynamicip.rima-tde.net) joined #osdev
00:25:21 <doug16k> idk if dumb is an accurate synopsis :D
00:25:42 <gamozo> but they just literally store/restore contents
00:25:48 <doug16k> it will flood the scheduler with the stores with no instruction decode bandwidth
00:26:18 <doug16k> all those giant mov to store them are hard to keep up with for the decoder
00:26:47 <doug16k> what about 256 bit avx? what about 512 bit avx-512, what about 32 512-bit avx-512 registers?
00:27:24 <doug16k> going to hammer out 32 entire cache line stores unconditionally plus the k0-k7? by hand?
00:27:59 <gamozo> that's fair
00:29:24 <doug16k> nicest thing about xsaveopt is you can set it up and it handles all the different xmm/ymm/zmm/0-15/0-31/k0-k7/x87 in one instruction
00:29:43 <gamozo> where do you tuck away your xsave page to? somewhere in [gs:]?
00:30:18 <doug16k> I allocate a separate stack just for the xmm contexts and maintain a pointer to the last one in the thread info block
00:31:32 <doug16k> it must be preserved - you can't just throw it on the general stack
00:31:49 <doug16k> that's why it can skip saving out registers that weren't modified - they are already there
00:32:46 <doug16k> the cpu remembers the address from which the last xrstor came. if it is the same when you xsaveopt, it will do the modified optimization and skip writing unmodified registers
00:34:00 <doug16k> it will also rapidly determine which register portions are zero, and instead of writing zeros, it will store out a bitmask which represents which ones are zero (aka, the init optimization)
00:34:47 <doug16k> so, if some thread is doing lots of scalar float, then it can skip writing the whole upper 128 bits of ymm / the whole upper 384 bits of zmm
00:35:13 <doug16k> it's crazy not to use xsaveopt :D
00:39:41 <doug16k> also, there is another optimization, it can use a compact storage layout. this can reduce the number of cache lines that get touched
00:40:59 <doug16k> for that you would want to use xsaves. xsaves can save more than just xmm/x87, it can save mpx state and other non-floating point states
00:42:54 <doug16k> my kernel supports fxsave,xsavec,xsaveopt. I need to add xsaves sometime
00:43:18 <gamozo> yeah, im gonna drop in xsaveopt support
00:43:40 <doug16k> note that there is a 32 bit and 64 bit version of those. the 64 bit version saves the x87 instruction and data pointer differently
00:43:55 <doug16k> gnu assembler has mnemonics suffixed with 64 for that
00:44:15 <doug16k> xsaveopt64, xsavec64, etc
00:44:48 <doug16k> without the 64, it truncates the offset and data pointers to 32 bits and stores superfluous segment value
00:45:31 <doug16k> afaik, it's no big deal unless some code is using float exceptions and they want that info
00:46:17 <doug16k> 64 puts rex.w prefix on it to make it have 64 bit behaviour
00:46:43 --- join: glauxosdever (~alex@ppp-94-66-45-221.home.otenet.gr) joined #osdev
00:49:11 <gamozo> strange, i'll see how it behaves with intel syntax
00:58:39 --- quit: Hdphn (Quit: Leaving)
01:03:08 --- quit: _sfiguser (Ping timeout: 268 seconds)
01:11:51 <gamozo> wow cool, that locked up my CPU
01:12:00 <gamozo> wonder if it's a phi specific bug
01:14:46 <mrvn> no fault, double fault or tripple fault?
01:15:04 --- join: _sfiguser (~sfigguser@130.108.214.77) joined #osdev
01:15:34 <gamozo> hard freeze, #IERR asserted in the CPU
01:17:42 <mrvn> try bochs and qemu for comparison
01:28:28 <gamozo> in this case it's a CPU thing, wouldn't crash on qemu
01:32:43 <mrvn> Do you know the feeling when you compile something 99% and then you get an error in common-header.h? I want a build system that remembers where it fails and tries to build that first the next time.
01:34:28 <doug16k> gamozo, you're checking cpuid for support right?
01:35:00 <doug16k> I'd be shocked if it didn't support it. how do they expect you to context switch avx-512? it must support it
01:35:22 <mrvn> doug16k: without support it should give an illegal instruction exception
01:35:38 <doug16k> you configure xsetbv and stuff right?
01:38:09 <gamozo> yeah
01:38:25 <gamozo> i just had a nasty typo in my interrupt handler for xsaveopt and it happened to break things pretty bad :P
01:38:49 <gamozo> should have #GPed or #DFed tho
01:41:52 <doug16k> https://media.tenor.co/images/1d44cb3dd69e88406e6e25bd70bbe9d6/raw <-- your cpu's reaction to the typo
01:42:37 <gamozo> yeah, I think I've had this happen before
01:42:46 --- quit: godel (Ping timeout: 260 seconds)
01:42:55 <gamozo> but the machine stops responding to reset as well, it needs to physically be unplugged and re powered
01:43:31 <doug16k> wow
01:44:32 <gamozo> and my IPMI event log is like "what the hell did you do everything is broken"
01:45:00 <doug16k> what was the typo?
01:45:14 <gamozo> didnt zero edx for xsave
01:45:19 <mrvn> Some mips CPU had it worse. They did reset when user space code did a certain sequence of opcodes. At some point gcc/binutils emited that sequence.
01:45:46 <gamozo> which you would hope wouldn't matter as it gets anded with xcr0... but apparently not
01:45:54 <gamozo> oh my xsave region was also not aligned
01:46:04 <gamozo> and the contents were not zeroed
01:46:11 <doug16k> gamozo, you can load edx:eax with all 1's, the cpu will and it with the enabled states
01:46:12 <gamozo> so _shrug_ could be one of many things
01:46:31 <gamozo> yeah, that's what I thought
01:46:43 <gamozo> might be somethign with avx512 and nonzeroed xsave state
01:47:01 <mrvn> zeroed shouldn't matter on save, only on load.
01:47:15 <doug16k> it matters
01:47:19 <gamozo> apparently it needs to be zeroed before saving
01:47:29 <gamozo> which makes sense if there are dirty state bits and such
01:47:42 --- quit: hmmmm (Remote host closed the connection)
01:47:46 <gamozo> i'm curious if intel put some bits in there which are unsafe to the CPU if not in a state they expect
01:48:05 <doug16k> once you get going you don't need to worry about it
01:48:16 --- quit: Pseudonym73 (Remote host closed the connection)
01:48:27 <gamozo> yeah, just the initial allocation of the xsave page should be zeroed, then after that xsave/xrstor is fine forever
01:48:30 <doug16k> you don't have to memset it before every save - just make it zeroed to begin with
01:48:39 <doug16k> right
01:48:59 <gamozo> it makes sense, the CPU has no other way of initializing it correctly
01:49:08 <gamozo> unless they added some `xsaveinit` or something instruction
01:49:12 <doug16k> the cpu is trying really hard not to have to fill every byte
01:49:30 <gamozo> I wouldn't be surprised if with KNL it's broken in some way
01:49:56 <gamozo> first CPU with AVX512, only sent to people running already stable environments, etc
01:52:35 <mrvn> Ahh, the fun of prefixing variable names with their type: Value::Val iUndefinedValue;
01:52:44 <mrvn> Works so well when the type gets changed later.
01:58:57 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
02:01:36 --- join: Philpax (~Philpax@144.132.100.253) joined #osdev
02:09:52 --- quit: quc (Remote host closed the connection)
02:10:08 --- join: quc (~quc@87.116.228.164) joined #osdev
02:11:31 --- quit: adam4813 (Quit: Connection closed for inactivity)
02:16:52 --- quit: nightmared (Quit: WeeChat 2.1)
02:17:14 --- quit: m_t (Quit: Leaving)
02:24:33 --- join: aleamb (~aleamb@unaffiliated/malpas) joined #osdev
02:26:21 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
02:29:35 --- quit: zhiayang (Client Quit)
02:30:17 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
02:36:06 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
02:36:52 --- quit: Halofreak1990 (Ping timeout: 268 seconds)
02:37:33 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
02:37:42 --- quit: zhiayang (Remote host closed the connection)
02:38:51 --- join: xerpi_ (~xerpi@150.red-83-45-192.dynamicip.rima-tde.net) joined #osdev
02:39:00 --- join: Philpax_ (~Philpax@144.132.100.253) joined #osdev
02:39:14 --- quit: xerpi (Read error: Connection reset by peer)
02:39:19 --- quit: tktech (Ping timeout: 240 seconds)
02:39:50 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
02:40:19 --- quit: sssnap (Ping timeout: 240 seconds)
02:41:10 --- join: tktech (~tktech@ec2-52-70-105-60.compute-1.amazonaws.com) joined #osdev
02:41:19 --- quit: Philpax (Ping timeout: 240 seconds)
02:42:22 --- quit: zhiayang (Client Quit)
02:42:59 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
02:44:34 --- quit: zhiayang (Client Quit)
02:47:14 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
02:48:49 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
02:49:27 --- quit: zhiayang (Client Quit)
02:52:55 --- quit: Goplat (Remote host closed the connection)
02:53:19 --- quit: Pseudonym73 (Ping timeout: 240 seconds)
02:54:47 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
03:00:27 --- part: Burgundy left #osdev
03:03:42 <AndrewBC_> who let an undefined type into your type hierarchy!?
03:03:55 <AndrewBC_> that person should be shot
03:05:15 --- join: light2yellow (~l2y@185.220.70.139) joined #osdev
03:06:05 <mrvn> AndrewBC_: it used to be int iUndefinedValue;
03:06:41 <AndrewBC_> oh so you intend to be gross
03:06:45 <AndrewBC_> carry on
03:06:54 --- quit: zhiayang (Quit: ZNC 1.8.x-nightly-20180502-d16817b0 - https://znc.in)
03:08:16 --- join: Halofreak1990 (~FooBar247@5ED0A537.cm-7-1c.dynamic.ziggo.nl) joined #osdev
03:08:43 <aalm> lol
03:09:14 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
03:14:20 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
03:17:27 --- quit: sortie (Ping timeout: 248 seconds)
03:18:19 <DusXMT> Hungarian notation can be useful if you have really long functions, but having really long functions isn't too desirable in the first place
03:18:37 <DusXMT> (I mean, that's what structured programming was invented to eliminate)
03:21:40 --- quit: jakogut_ (Quit: jakogut_)
03:22:44 --- nick: booyah_ -> booyah
03:23:26 --- join: jakogut_ (~jakogut@162.251.69.147) joined #osdev
03:24:49 --- quit: Darksecond (Read error: Connection reset by peer)
03:26:13 --- quit: jakogut_ (Client Quit)
03:26:53 --- join: jakogut_ (~jakogut@162.251.69.147) joined #osdev
03:31:09 --- quit: mavhq (Read error: Connection reset by peer)
03:31:41 --- join: Darksecond (~darksecon@a82-94-53-70.adsl.xs4all.nl) joined #osdev
03:32:26 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
03:37:06 --- quit: JonRob (Ping timeout: 260 seconds)
03:43:27 --- quit: aalm (Ping timeout: 240 seconds)
03:48:46 --- join: Hdphn (~akira@gateway/tor-sasl/hdphn) joined #osdev
03:51:34 --- quit: baschdel (Ping timeout: 260 seconds)
03:51:46 --- quit: Hdphn (Remote host closed the connection)
03:51:55 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
03:52:27 --- join: Hdphn (~akira@gateway/tor-sasl/hdphn) joined #osdev
03:52:58 --- quit: tux3 (Changing host)
03:52:58 --- join: tux3 (~tux@unaffiliated/tux3) joined #osdev
03:55:19 --- quit: immibis (Ping timeout: 264 seconds)
03:55:20 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
03:57:36 --- quit: dmj` ()
03:58:39 --- join: dmj` (sid72307@gateway/web/irccloud.com/x-kjzdamwplgiwhtcf) joined #osdev
04:01:44 --- quit: baschdel (Ping timeout: 256 seconds)
04:11:15 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
04:16:33 --- join: zeus1 (~zeus@197.239.32.34) joined #osdev
04:35:39 --- quit: sortie (Quit: Leaving)
04:39:40 --- join: baschdel (~baschdel@2a01:5c0:10:3d11:bca2:7797:3876:4668) joined #osdev
04:45:58 --- quit: swetland ()
04:46:11 --- join: swetland (sid155178@gateway/web/irccloud.com/x-bwbzqwzqdskuccqz) joined #osdev
04:47:26 --- quit: glauxosdever (Quit: leaving)
04:47:30 --- quit: [Brain] (Ping timeout: 276 seconds)
04:48:24 --- join: [Brain] (~brain@brainwave.brainbox.cc) joined #osdev
04:50:20 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
04:54:49 --- quit: Pseudonym73 (Ping timeout: 240 seconds)
05:00:43 --- quit: zeus1 (Ping timeout: 264 seconds)
05:06:36 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
05:07:01 --- quit: Tazmain (Max SendQ exceeded)
05:07:30 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
05:08:58 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
05:15:55 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:18:34 --- quit: jakogut (Remote host closed the connection)
05:18:34 --- nick: jakogut_ -> jakogut
05:34:15 --- join: JonRob (~jon@host165-120-84-64.range165-120.btcentralplus.com) joined #osdev
05:38:37 --- quit: JonRob (Remote host closed the connection)
05:42:28 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
05:44:48 --- join: zeus1 (~zeus@197.239.32.34) joined #osdev
05:50:47 --- join: oaken-source (~oaken-sou@p5DDB53E8.dip0.t-ipconnect.de) joined #osdev
05:51:54 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
05:54:56 <mrvn> I need a STTL (Standard Threadsafe Template Library)
05:55:26 --- quit: ALowther (Ping timeout: 268 seconds)
05:55:57 --- quit: Pseudonym73 (Ping timeout: 240 seconds)
05:57:18 --- join: TempNickLel (~user@194.135.171.224) joined #osdev
05:57:19 --- quit: zeus1 (Ping timeout: 240 seconds)
05:59:56 --- join: daniele_athome (~daniele_a@5.170.128.31) joined #osdev
06:06:10 --- quit: elevated (Quit: bye)
06:10:59 --- join: samathy (~samathy@barratt1.plus.com) joined #osdev
06:11:41 --- quit: Philpax_ (Ping timeout: 260 seconds)
06:20:55 --- join: X-Scale (~ARM@214.114.166.178.rev.vodafone.pt) joined #osdev
06:29:06 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
06:38:44 --- join: promach2 (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:41:11 --- join: zeus1 (~zeus@197.239.32.34) joined #osdev
06:42:21 --- quit: paulbarker ()
06:42:39 --- join: paulbarker (sid269702@gateway/web/irccloud.com/x-zylltxmphwfxzebx) joined #osdev
06:46:40 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
06:46:44 --- join: ryonaloli (ta@unaffiliated/ryonaloli) joined #osdev
06:49:06 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:53:18 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
06:57:11 --- quit: zeus1 (Ping timeout: 260 seconds)
06:57:31 --- quit: ALowther (Ping timeout: 256 seconds)
06:57:58 --- quit: Pseudonym73 (Ping timeout: 256 seconds)
07:02:26 --- quit: light2yellow (Quit: light2yellow)
07:07:41 --- quit: daniele_athome (Ping timeout: 260 seconds)
07:10:10 --- join: glauxosdever (~alex@ppp-94-66-45-221.home.otenet.gr) joined #osdev
07:12:32 --- join: daniele_athome (~daniele_a@5.170.128.191) joined #osdev
07:20:10 --- join: AndChat611184 (~clh@240e:a4:c203:2100:c130:7171:77c3:6574) joined #osdev
07:29:49 --- join: fujisan (uid4207@gateway/web/irccloud.com/x-jrzrfsegrtjfjihe) joined #osdev
07:35:26 --- quit: ryonaloli (Remote host closed the connection)
07:37:56 --- quit: glauxosdever (Quit: leaving)
07:41:02 --- quit: AndChat611184 (Quit: Bye)
07:42:09 --- join: zeus1 (~zeus@197.239.32.34) joined #osdev
07:49:31 --- quit: zeus1 (Ping timeout: 268 seconds)
07:51:24 --- quit: jjuran (Read error: Connection reset by peer)
07:53:19 --- join: jjuran (~jjuran@c-73-132-80-121.hsd1.md.comcast.net) joined #osdev
08:02:39 --- join: tacco| (~tacco@i59F5F1C4.versanet.de) joined #osdev
08:14:02 --- join: Esa_ (~esa.syt@99-50-199-38.lightspeed.snjsca.sbcglobal.net) joined #osdev
08:14:03 --- join: patv (a6303193@gateway/web/freenode/ip.166.48.49.147) joined #osdev
08:14:52 --- quit: quc (Remote host closed the connection)
08:15:05 --- join: quc (~quc@87.116.228.164) joined #osdev
08:20:18 --- join: SGautam (3bb6f800@gateway/web/freenode/ip.59.182.248.0) joined #osdev
08:20:46 <SGautam> Back when games were installed through InstallShield setup
08:20:52 <SGautam> So 2000s
08:23:16 <TempNickLel> We used to pay 3$ for pirated CDs
08:24:29 <SGautam> And have the setup start in Russian?
08:24:41 <SGautam> I used to buy pirated CDs but then that always happened.
08:26:10 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:26:20 <TempNickLel> Yeah
08:26:24 <TempNickLel> Russian companies
08:26:30 <TempNickLel> pirating shit allday
08:26:35 <TempNickLel> i had good time
08:29:59 --- quit: variable (Quit: Found 1 in /dev/zero)
08:30:08 <grange_c> Hello guys
08:32:42 <SGautam> Meh, most of the times the programs I bought for ~100 bucks (US 2) failed to properly install, or even when I got them to install the program crashed, or was unusable.
08:33:03 <SGautam> Piracy is dying now, since most commercial software is turning free.
08:33:24 --- join: zeus1 (~zeus@197.239.32.34) joined #osdev
08:35:43 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
08:36:54 --- quit: ovf ()
08:38:37 --- join: ovf (sid19068@gateway/web/irccloud.com/x-julhsbpxzclvmvtr) joined #osdev
08:41:25 --- join: malpas (~aleamb@81.61.178.198.dyn.user.ono.com) joined #osdev
08:41:25 --- quit: malpas (Changing host)
08:41:25 --- join: malpas (~aleamb@unaffiliated/malpas) joined #osdev
08:44:03 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:44:39 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
08:45:06 --- quit: aleamb (Ping timeout: 264 seconds)
08:46:49 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
08:54:52 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
08:59:11 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
08:59:19 --- quit: Pseudonym73 (Ping timeout: 240 seconds)
09:01:40 --- quit: freakazoid0223_ (Ping timeout: 268 seconds)
09:04:19 --- quit: promach2 (Ping timeout: 264 seconds)
09:04:44 --- join: freakazoid0223_ (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
09:06:49 --- quit: freakazoid0223 (Ping timeout: 240 seconds)
09:08:00 --- quit: zgrepc ()
09:08:42 --- join: zgrepc (sid43445@ircpuzzles/2015/april-fools/sixth/zgrep) joined #osdev
09:09:34 --- join: r00tus3r (uid126983@gateway/web/irccloud.com/x-qhvgxlqlrypupjlu) joined #osdev
09:09:47 --- quit: SGautam (Changing host)
09:09:47 --- join: SGautam (3bb6f800@unaffiliated/gautams) joined #osdev
09:09:47 --- quit: SGautam (Changing host)
09:09:47 --- join: SGautam (3bb6f800@gateway/web/freenode/ip.59.182.248.0) joined #osdev
09:12:42 --- quit: xerpi_ (Quit: Leaving)
09:13:58 --- quit: ALowther (Remote host closed the connection)
09:14:49 --- quit: NaNkeen (Ping timeout: 240 seconds)
09:19:37 --- join: promach2 (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
09:28:29 --- quit: malpas (Quit: Leaving)
09:30:27 --- join: NaNkeen (~nankeen@115.164.81.83) joined #osdev
09:31:25 --- quit: mavhq (Read error: Connection reset by peer)
09:32:40 --- join: mavhq (~quassel@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) joined #osdev
09:36:30 --- join: dennis95 (~dennis@mue-88-130-61-139.dsl.tropolys.de) joined #osdev
09:38:32 --- quit: fujisan (Quit: Connection closed for inactivity)
09:43:57 --- quit: NaNkeen (Ping timeout: 240 seconds)
09:44:19 --- quit: zeus1 (Ping timeout: 240 seconds)
09:44:38 --- quit: SGautam (Quit: Page closed)
09:45:11 --- quit: daniele_athome (Ping timeout: 260 seconds)
09:45:44 --- quit: Esa_ (Read error: Connection reset by peer)
09:46:02 --- join: Esa_ (~esa.syt@99-50-199-38.lightspeed.snjsca.sbcglobal.net) joined #osdev
09:51:52 --- join: daniele_athome (~daniele_a@5.170.130.12) joined #osdev
09:54:21 --- quit: patv (Ping timeout: 260 seconds)
09:54:49 --- quit: tsurai (Ping timeout: 267 seconds)
09:54:56 --- join: tsurai (~tsurai@2001:19f0:6c01:5d0:5400:1ff:fe49:f728) joined #osdev
09:55:28 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:55:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:56:16 --- quit: UNIVAC (Ping timeout: 260 seconds)
09:57:50 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
09:59:11 --- quit: freakazoid0223_ (Ping timeout: 260 seconds)
10:01:18 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:07:19 --- quit: freakazoid0223 (Quit: First shalt thou take out the Holy Pin. Then, shalt thou count to three. No more. No less.)
10:07:25 --- quit: cja ()
10:07:42 --- join: cja (sid161498@gateway/web/irccloud.com/x-vefrkqblfiplzkpp) joined #osdev
10:09:45 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
10:12:41 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:17:19 --- quit: daniele_athome (Ping timeout: 240 seconds)
10:17:34 --- join: pounce (~pounce@c-24-11-27-195.hsd1.ut.comcast.net) joined #osdev
10:20:37 --- join: vinleod (~vdamewood@unaffiliated/vdamewood) joined #osdev
10:20:44 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
10:20:57 --- quit: dude12312414 (Quit: Segmentation fault: 11)
10:21:10 --- quit: elevated (Remote host closed the connection)
10:22:01 --- quit: vdamewood (Disconnected by services)
10:22:02 --- join: elevated (~elevated@unaffiliated/elevated) joined #osdev
10:22:10 --- nick: vinleod -> vdamewood
10:22:26 --- join: daniele_athome (~daniele_a@5.170.129.100) joined #osdev
10:24:11 --- quit: R3x_ ()
10:24:29 --- join: R3x_ (sid181433@gateway/web/irccloud.com/x-yrgbrezcqdbgaqrx) joined #osdev
10:27:06 --- join: dude12312414 (None@gateway/shell/elitebnc/x-apvilqtrsqqjqgyi) joined #osdev
10:27:30 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
10:31:02 --- join: hmmmm (~sdfgsf@pool-72-79-161-213.sctnpa.east.verizon.net) joined #osdev
10:35:41 --- quit: quc (Ping timeout: 256 seconds)
10:35:59 <pounce> How can I get the current interrupt state? (enabled or disabled)
10:36:31 --- quit: pointfree ()
10:37:08 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-flrmquonluxddfqx) joined #osdev
10:38:10 <_mjg_> pounce: you can pushf/pop, see spin_lock_irqsave on linux
10:39:05 --- quit: ALowther (Remote host closed the connection)
10:39:43 --- join: mpt- (~tacco@i59F521D3.versanet.de) joined #osdev
10:40:36 --- quit: tacco| (Ping timeout: 260 seconds)
10:40:55 --- quit: promach2 (Ping timeout: 264 seconds)
10:53:27 --- quit: kasumi-owari (Ping timeout: 248 seconds)
10:55:19 --- join: kasumi-owari (~kasumi-ow@ftth-213-233-237-007.solcon.nl) joined #osdev
10:56:18 --- join: Pseudonym73 (~Pseudonym@124-168-223-127.dyn.iinet.net.au) joined #osdev
10:58:18 --- quit: Hdphn (Remote host closed the connection)
11:01:07 --- join: Burgundy (~yyomony@86.121.138.174) joined #osdev
11:01:18 --- quit: Pseudonym73 (Ping timeout: 268 seconds)
11:03:44 <pounce> What's the virtual interrupts flag?
11:05:19 --- join: BreakingFree (~libre@199.254.238.195) joined #osdev
11:08:50 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
11:14:57 <CrystalMath> pounce: whether v86 mode interrupts should be virtualized
11:19:36 --- nick: AvgJoe -> AverageJoe
11:19:50 --- nick: AverageJoe -> AverageJ0e
11:20:06 --- quit: TempNickLel (Quit: WeeChat 2.1)
11:21:33 --- quit: unixpickle (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:23:13 <pounce> I do not know what those words mean @w@
11:35:29 --- join: manwar (~manwar@41.37.92.65) joined #osdev
11:37:04 --- quit: manwar (Client Quit)
11:37:24 --- join: glauxosdever (~alex@ppp-94-66-45-221.home.otenet.gr) joined #osdev
11:46:08 --- join: Asu (~sdelang@AMarseille-658-1-105-68.w86-219.abo.wanadoo.fr) joined #osdev
11:47:09 --- join: attah (~attah@h-155-4-135-114.NA.cust.bahnhof.se) joined #osdev
11:50:02 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
11:54:19 --- quit: ALowther (Ping timeout: 240 seconds)
11:54:44 --- quit: maslan (Remote host closed the connection)
11:55:03 --- join: maslan (~maslan@192-0-134-110.cpe.teksavvy.com) joined #osdev
11:57:01 --- quit: r00tus3r (Quit: Connection closed for inactivity)
12:01:13 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
12:03:48 --- join: dbittman (~dbittman@2601:647:ca00:1651:b26e:bfff:fe31:5ba2) joined #osdev
12:06:36 --- join: unixpickle (~alex@c-24-5-86-101.hsd1.ca.comcast.net) joined #osdev
12:06:40 --- quit: ZipCPU (Ping timeout: 268 seconds)
12:06:41 --- join: ZipCPU_ (~ZipCPU@pool-72-73-32-180.clppva.fios.verizon.net) joined #osdev
12:09:16 --- join: ZipCPU (~ZipCPU@pool-72-73-32-122.clppva.fios.verizon.net) joined #osdev
12:12:11 --- quit: ZipCPU_ (Ping timeout: 260 seconds)
12:12:43 --- quit: JusticeEX (Ping timeout: 240 seconds)
12:15:19 --- quit: maslan (Ping timeout: 240 seconds)
12:16:37 --- join: maslan (~maslan@192-0-134-110.cpe.teksavvy.com) joined #osdev
12:17:28 <geist> huh that's interesting, the nasa insight mars probe launched with a polar injection
12:17:49 <geist> launched from vandenberg AFB, which puts it in a polar orbit
12:17:50 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
12:18:07 <geist> not sure they've ever done that before for an interplanetary launch
12:19:09 <pounce> My mom's been working at vandenberg \o/
12:19:29 <geist> neat
12:22:07 <pounce> So what's a good way to do CPU local variables? Should I store each one as an array that I index with :gs, store them in a separate page, etc.?
12:23:24 <geist> at least store them in structures cache line aligned and padded
12:23:57 <variable> goal for your OS
12:24:00 <geist> but it depends on precisely wha tyou mean by cpu local. as in are these cpu local that you have to access manually?
12:24:00 <variable> get ATLAS to compile
12:24:10 <geist> or for it to be some automatic TLS style thing
12:24:32 <variable> pounce: CPU local for what kind of thing ?
12:24:46 <geist> in general i'd recommend putting a pointer to a well defined per cpu local structure in gs
12:24:50 <geist> and then have some sort of accessor
12:25:04 <pounce> then should I have the other structures linked to that?
12:25:14 <geist> depends on what yo mean by 'other structures'
12:25:23 <geist> some, yes? depends on if it's per cpu or not
12:25:25 <pounce> things like the scheduler and IDT
12:25:34 <geist> if it's a per cpu scheduler, yes
12:25:58 <geist> things that are logically per cpu you should probably link off this. but at the minimum at least put the cpu number in the per cpu structure
12:26:06 <geist> so you can, with essentially one instruction, get the current cpu #
12:26:11 <geist> gs:0 or something
12:26:16 <variable> +1 to what geist said
12:26:33 <geist> then, you can if you choose link other stuff off it, or have other arrays that you can use the cpu # from. either way
12:26:44 <variable> also make sure its cache aligned so you don't acciidently evict for it
12:27:00 <geist> kinda works out the same. the trick is being able to look it up with a single instruction
12:27:02 <pounce> Isn't `gs` small though? I can't store a whole pointer in there
12:27:12 <geist> then you dont understand how gs works
12:27:21 <pounce> also what is evicting?
12:27:23 <pounce> geist: yes that is true
12:27:38 --- quit: t3hn3rd (Ping timeout: 268 seconds)
12:27:38 <geist> i'd suggest re-reading how segments work. are you in 64bit or 32bit mode?
12:27:54 <pounce> How I understand it it's a 16-bit offset, so I'd have to put it in the first 16-bit section of memory
12:27:54 <geist> note that gs/fs work almost completely differently in 32 vs 64
12:27:59 <pounce> 64-bit mode
12:28:06 <geist> nope. that's not at all how gs works.
12:28:12 <geist> that 16bit offset stuff is 100% incorrect
12:28:55 <variable> pounce: relevent https://en.wikipedia.org/wiki/X86_memory_segmentation
12:28:56 <bslsk05> ​en.wikipedia.org: x86 memory segmentation - Wikipedia
12:29:00 <geist> note that maintaining gs in 64bit world is actually fairly subtle and tricky
12:29:10 <variable> but also which memory adressing mode are you n?
12:29:16 <geist> so you have to really really understand it before you try to implement
12:29:23 <geist> variable: they said 64bit
12:29:28 <variable> oh, missed that
12:29:36 <pounce> Yeah I'm not super close to SMP right now but I want to start designing around it
12:29:45 <geist> in which case fs/gs work completely differently
12:29:52 <variable> sorry, I assumed 32
12:29:54 <variable> yeah
12:29:58 <geist> pounce: here's the gist that you can go re-read
12:30:04 <geist> fs/gs *value* are meaningless
12:30:22 <geist> there's a set of MSRs you can write a full 64bit pointer to that defines what fs/gs dereferences point to
12:30:41 <geist> so if in theMSR you have 0x1234, then a memory reference using gs:4 would actually be 0x1234 + 4
12:31:10 <geist> so, basically you use the MSR to point gs at the current cpu structure, such that gs:<offset> is just an offset within the structure
12:31:41 <geist> none of the rest of segmentation works in this case. there's no limit, no priviledge checks. gs dereferences just act as an implicit base address
12:32:25 <geist> and if that doesn't make any sense, i suggest reading the intel and AMD manual on the sections on this. keep in mind 64bit mode redefines it again. so dont be confused with real mode and protected mode descriptions of how segments work
12:32:37 * variable has an osdev account o.O ?
12:33:07 <geist> note that fs works the same too, but for other reasons that i dont want to describe here right now to confuse you, kernels use gs:
12:33:32 <variable> except for macOS IIRC
12:33:36 <variable> unless I'm confusing what they do
12:33:38 <geist> shush dont confuse em
12:33:59 <geist> yes there are always exceptions, etc. but when someone barely understands whats going on, it's usually better to just point them at the simple, standard path
12:34:03 <variable> sorry
12:34:03 <pounce> I see people saving gs: as part of their ISRs a lot, is this needed?
12:34:08 <geist> pounce: yes
12:34:25 <geist> well.... saving the value of gs: fs: is not really needed
12:34:38 <geist> but you'll probably see a 'swapgs' instruction, which is part of the complexity of the whole thing
12:34:45 <geist> first, understand how gs/fs work in 64bit
12:34:51 <geist> then it'll be more clear. and it's subtle
12:35:52 <geist> note that teh actually *value* in fs/gs is unused
12:35:57 <geist> it's meaningless. most systems leave it at 0
12:36:09 <pounce> What sections should I look at? I found `segment registers in 64-bit mode` but that isn't very helpful
12:36:16 <geist> thats probably it
12:36:32 <geist> it's actually not that complicated. it's very simple compared to 16/32 bit mode, it's just subtle
12:36:36 <geist> specifically with the 3 MSRs and swapgs
12:36:40 <geist> once you grok that you'll be cool
12:38:29 <geist> btw, what you're doing now where you try to get ahead of it to prepare for SMP is a great idea
12:38:37 <variable> +1
12:38:46 <geist> better to start structuring things as if there were multiple cpus, even if there's only one
12:38:52 <pounce> (I'd look in the AMD manual, but I assume that AMD and Intel are different bc MSR ?)
12:38:57 <pounce> Yeah, you told me to do it :p
12:38:59 * variable always feels like a fraud in this channel
12:39:06 <geist> pounce: there are not different at all
12:39:23 <geist> AMD added the 64bit extension, and the intel implemented the same thing
12:39:47 <geist> how fs/gs work and the MSRs and swapgs is part of the x86-64 extension, and both vendors implement it equivalently
12:40:05 <variable> pounce: the above sentence is why you'll usually (often?) see the ABI refered to as 'amd64'
12:40:05 --- join: v0l_ (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
12:40:08 <v0l_> hi
12:40:15 <geist> hola
12:40:19 <pounce> ah gotcha
12:40:53 <variable> this channel always make me feel like a fraud :(
12:40:57 <variable> but that's a good thing
12:40:59 * variable learns
12:41:20 <rain1> ive not even statred making my ow nos
12:41:24 <rain1> so your probably ahead of me variable
12:41:33 <geist> variable: why? everyone starts off not knowing anything
12:41:39 <v0l_> can someone please explain where exactly is the issue here? https://twitter.com/aionescu/status/991675604469669890 swapgs should not be used if PTI is enabled?
12:41:39 <bslsk05> ​twitter: <aionescu> Welp, it turns out the #Meltdown patches for Windows 10 had a fatal flaw: calling NtCallEnclave returned back to user space with the full kernel page table directory, completely undermining the mitigation. This is now patched on RS4 but not earlier builds -- no backport?? https://pbs.twimg.com/media/DcMjWcBUwAAris6.jpg https://pbs.twimg.com/media/DcMjZQVVAAAD8HC.jpg
12:41:56 <variable> geist: the feeling, and the actuality is not the same thing
12:42:12 <geist> sure, i have fairly crippling impostor syndrome myself
12:42:14 <variable> I try to compare myself to yesterday
12:42:15 <geist> but i get by
12:42:20 <variable> instead of comparing myself to other people
12:42:21 <variable> but its hard
12:42:33 <geist> right, the key is to make incremental progress, and then keep doing that forever
12:42:39 <variable> +1
12:42:45 <geist> after so many years folks start treating you like you know what you're talking about
12:42:52 <variable> the other thing is that my goals often don't directly align with others here
12:42:55 <geist> then you have to deal with your impostor syndrome, but you at least do know something
12:43:17 <variable> my goal has more to do with user impact on a production OS, than making one myself
12:43:26 <variable> so I learn a compltely different set of things
12:43:29 <variable> but then I hang out here
12:43:32 <variable> :\
12:43:33 <geist> v0l_: is that linking somewhere else? I can't view twitter here
12:44:00 <variable> rain1: what part are you up to? just learning? do you have a skeleton at all?
12:44:20 <rain1> i havent decided on what computer to write it for
12:44:21 <geist> i dunno the context of that swapgs thing that was linked
12:44:24 <rain1> i think i want to avoid x86
12:44:25 <v0l_> geist: https://pbs.twimg.com/media/DcMjWcBUwAAris6.jpg - https://pbs.twimg.com/media/DcMjZQVVAAAD8HC.jpg
12:44:30 <v0l_> can you see the imgs?
12:44:33 <rain1> where ar you about?
12:44:39 <geist> yes. but there's no where enough context to know what's going on there
12:44:58 <geist> i dunno precisely how it's related to swapgs
12:45:04 <v0l_> geist: "Welp, it turns out the #Meltdown patches for Windows 10 had a fatal flaw: calling NtCallEnclave returned back to user space with the full kernel page table directory, completely undermining the mitigation. This is now patched on RS4 but not earlier builds -- no backport??"
12:45:14 <geist> yes. but again, dunno the context there
12:45:23 <v0l_> from code in the imgs seems to be a return to userspacde from syscall
12:45:37 <geist> okey dokey. well i dont knowwhat you're looking for
12:45:58 <geist> i understand the code snippet, but it's just a piece out of a much larger picture that i dont know
12:46:06 <v0l_> that is what I am looking for, I don't get where the issue is from that tweet :)
12:46:18 <geist> then i dont either. alex is a good guy though
12:46:25 <geist> met him in person a few times. he really knows his stuff
12:46:30 <booyah> lol at people surprise INTEL releases backdors. They do not even hide it, _INTEL_ :}
12:46:43 <variable> lllool
12:46:47 <booyah> INTEL inside your CPU :)
12:47:47 <geist> maybe the problem there is in the second jpg, where it conditionally directly rets to user space without going through KiKernelExit(), which presumably does the KTPI swap back to the other cr3
12:48:04 <geist> but dunno
12:48:22 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
12:48:27 <geist> it's just a bug, when you slam through major changes like KTPI forced everyone to do in short succesion, it's almost guaranteed that bugs will slip in
12:48:30 <geist> and in this case, no different
12:48:43 <v0l_> geist: maybe the swapgs is done nly if PTI is not used?
12:48:47 <geist> KTPI is a *major* refactor of how memory is managed
12:49:03 <geist> v0l_: something like that, i suspect the swapgs isn't the interesting part
12:49:18 <geist> swapgs is just something you basically have to do on entry/exit to the kernel from user space
12:49:20 <v0l_> yeah, the interesting part is the if() statempent before
12:49:27 <geist> to make sure the gs pointer is pointing at the kernel gs
12:49:43 <geist> which is directy apropos to what pounce was asking about just before you joined the channel
12:50:36 * variable pounces on pounce
12:50:46 <v0l_> do you think that it still makes sense to use PTI when future CPUs are fixed?
12:50:52 <variable> v0l_: sort of
12:50:56 <geist> depends on how they're fixed
12:51:05 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
12:51:05 <peterbjornx> against possible future issues
12:51:16 <variable> v0l_: PTI also gives you other advantages/disavatages
12:51:16 <v0l_> PTI is not really needed on arm or amd, right?
12:51:28 <peterbjornx> it is
12:51:29 <geist> if intel/amd would add better PCID support then it could be made to be basically free
12:51:35 <geist> so i'd hope that's what they'd do
12:51:39 <variable> I was about to say: PCID is being used
12:51:42 <variable> in most cases
12:51:47 <v0l_> but PTI is not introduced only for meltdown, but for kernel/user PT separation
12:51:50 <geist> yes but PCID sucks, it only helps mitigate it
12:51:58 <geist> because it's not a very useful feature (and AMD doesn't even implement it)
12:52:11 <v0l_> amd doesn't have pcid?
12:52:14 <variable> right, but with fixed PCIID, KPTI gives you other advantages
12:52:23 <variable> like full address space use in 32 bit mode
12:52:23 <geist> ARM has a much more powerful PCID called ASID, which is baout 90% of what you want
12:52:35 <variable> I know nothing about ARM
12:52:35 <geist> yeah but who gives a crap about 32bit mode anymore
12:52:36 <peterbjornx> afaik ARM and AMD's x86 implementation are also theoretically vulnerable
12:52:45 <variable> geist: embedded applications :-)
12:52:46 <v0l_> they are?
12:52:47 <geist> so far not to KTPI
12:52:51 <variable> what's the difference between ASID and PCID ?
12:52:54 <geist> not to meltdown
12:53:15 <geist> variable: everything. it's a similar idea: tag the active address space's TLB entries with a number that the OS chooses
12:53:26 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
12:53:29 <geist> but the ARM one is far more flexible and useful. all OSes use it
12:53:43 * pounce pounces back on variable
12:53:49 <geist> whereas PCID is very limited and hard to use, hence why linux didn't really even use it until KPTI
12:54:03 <variable> CrystalMath: I forgot to mention: I like your nick
12:54:03 <variable> geist: oic
12:54:18 <CrystalMath> variable: thanks :) yours is nice too
12:54:26 <variable> geist: yaya
12:54:48 <geist> and AMD never implemented PCID. lemme double check it wasn't added on ryzen, but i dont think it was
12:54:59 <geist> yep, not present
12:55:44 <geist> and even then it's mor complicated. pcid got added i think back in nehalem, but then some additional instructios came along in the haswell days (i think) to make it more generically useful
12:56:16 <geist> so it was one of the cases where hte early feature add was probably some very specific use case that someone asked for, and then over time they listened to folks griping that it was not useful and added more instructions to help
12:56:28 <geist> i'm gonna guess that pcid is going to get extended farther in the future
12:56:56 <geist> but really TLB maintenance on x86 in general is in the stone age compared to most other arches. it's hard to do anything efficient TLB wise
12:57:16 <v0l_> why?
12:58:07 <geist> because the entire paging/tlb mechanism in x86 was added in 1985 and hasn't been fundamentally rethought since
12:58:16 <geist> and quite specifically it was not esigned with SMP in mind
12:58:39 <variable> v0l_: combine geis's comments with the issue that OSes have always assumed TLB flushes are expensive
12:58:43 <variable> and thus have workarounds for it
12:58:54 <variable> and thus don't see as much gain when tools are improved
12:58:55 <variable> etc.
12:59:00 <geist> right. you can see how it evolved to try to be a bit more efficient
12:59:10 <geist> ie, 386: mmu/tlb was added
12:59:24 <geist> 486: invlpg was added (now you can flush a single page at a time)
12:59:42 <geist> 586 (maybe 686): global bit was added (so your kernel doesn't have to dump it's TLB when it context switches)
12:59:56 <geist> nehalem: PCID was added
13:00:10 <geist> haswell: invpcid (or something likethat) was added to make PCID a bit more useful
13:01:04 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
13:01:11 <geist> and in the middle you had things like PSE, PSE36, PGE, 4 level, etc
13:01:16 <geist> but those are specifically efficienty related
13:01:17 <v0l_> why intel is so fucky?
13:01:38 <variable> backwards compatibilty
13:01:52 <v0l_> I guess that ARM added new features in years as well, but they are not so overcomplicated
13:02:23 <geist> well, ARM in particular is not forward compatible, and they only maintain backwards compatibility for a while
13:02:53 <geist> so every 10 years or so they put out a new version of the arch (armv8 is the current) and by going into that mode things can change in pretty fundamental ways
13:03:15 <geist> generally within an arch rev, if you have well designed kerel code you should work on all cores in that arch
13:03:25 <pounce> I'm looking through the MSRs and I can't really find anything
13:03:25 <v0l_> probably they can easily than intel
13:03:43 <geist> but say, when armv9 comes along, there's probably no guarantees that armv8 kernels will run on it without some modification
13:03:54 <geist> and then there's no guarantees that armv9 will maintain armv7 32bit compatibility or whatnot
13:04:04 <v0l_> ok
13:04:09 <geist> pounce: search for GS_BASE
13:04:14 <v0l_> so they just 'don't care about old cpus'
13:04:45 <geist> well, mor elike their marketing/sales department says 'lets get vendors to move to newer versions of the core so we can re-license it'
13:05:03 <geist> and then they made improvements to newer cores across the spectrum of designs to make it appealing for vendors to switch to newer designs
13:05:23 <geist> and then try hard to phase out old designs
13:05:44 <v0l_> it also makes OS dev better
13:05:45 <geist> and that whole process takes 5 or 10 years or so,but you're seeing it now
13:05:59 <geist> almost allnew SoCs coming out of vendors have switched at least to armv8 (and thus mostly 64bit) cores
13:06:19 <geist> whereas 3 or 4 or 5 years ago it was still a mix
13:06:26 --- quit: godel (Ping timeout: 260 seconds)
13:06:49 <geist> intel/amd are completely stuck because in the x86 world backwards compatibility is so important they can't move on if they wanted to
13:06:55 <v0l_> if I just think that x86 still needs to boot from real mode in 2018, I become crazy
13:07:05 <geist> intel is pushing hard now to remove at least BIOS, and if they're successful by 2020 or so all new machines will be EFI based
13:07:24 <pounce> Now that I've rewritten interruts, it's time to port a bunch of queues to my OS XwX
13:07:28 <geist> well, specifically without the CSM module. i'm assuming that's in prep for finally phasing out the 16 bit compatibility mode stuff
13:07:46 <geist> but they basically tried to switch off x86 in 1999 with ia-64 and that was a dismal failure
13:08:05 <v0l_> ia64 was just a mess
13:08:18 <SGautam> it had a cool name though
13:08:22 <SGautam> Itanium
13:08:26 <v0l_> yeah
13:08:42 <gamozo> ia64 had some great features, but intel seemed to not realize that backwards compat is what made them where they are now
13:08:43 <geist> it was neat from a osdev point of view. kind of every neat bell and whistle you can imaging
13:08:50 <geist> i still want to sit down and hack some kernel code for it some day
13:09:00 <gamozo> probably would have been a great arch if it werwent for back compat
13:09:03 <pounce> (now I should be able to create a `assert_throws(f: FnOnce)` function for testing though, which is nice ^w^)
13:09:14 <DusXMT> gamozo: They did realize it, the processors were able to run emulated x86 code
13:09:23 <DusXMT> but the performance of the emulated code wasn't great
13:09:51 <geist> yeah. the first version of itanium was pretty awful performance wise. but then that was mostly purely a test chip really
13:10:05 <geist> had awful cache performance, apparently, and the x86 emulation was purely in order and very slow
13:10:19 <geist> i actually bought one off ebay and ran one for about a year
13:10:22 <geist> it was... not great
13:10:24 <pounce> geist: `IA32-GS_BASE` ?
13:10:40 <gamozo> I think with modern compiler tech it could have been a bit faster
13:10:41 <geist> bingo, now go cross reference that into the docs to see how it's supposed to be used
13:11:03 <v0l_> they were also not fun to use ia64 and make more confusion with ia32 and x86_64 :)
13:11:10 <geist> i think they just underestimated how good OOO cpu architectures have become in the interim
13:11:26 <geist> yah. but then x86_64 didn't come along for another 3 or 4 years
13:11:26 <gamozo> all the cool kids say ia32e when referring to x86_64
13:11:36 <geist> that was AMD stealing intel's thunder
13:11:54 <gamozo> I'm sure intel isn't too happy about those royalties
13:11:56 <geist> 2003 is when i remember the K8 coming out. kind of to a whimper. the only people that cared where linux/bsds
13:11:59 <gamozo> they effectively lost their arch
13:12:35 <geist> since windows didnt support it for a while, functionally no one gave a crap about x86-64 for another few years
13:12:47 <geist> except open source folks
13:13:08 <geist> you could feel AMD losing their grip on their major tactical victory
13:13:41 <v0l_> also amd64 docs was better than intel :D
13:13:46 <geist> but i do remember the x86-64 transition re: linux distros and whatnot being fairly hard
13:14:10 <geist> totally. i still have an original amd64 doc set. AMD sent it to me completely preemptively because i was on the osdev community
13:14:20 <geist> i didn't even ask for it, just one day a box showed up with 5 manuals in it
13:14:22 <SGautam> IA32-E was the compatibility 32-bit mode, right?
13:14:22 <geist> AMD +1
13:14:33 <gamozo> ia32e 64-bit Intel x86
13:14:41 <gamozo> e is for extended
13:14:43 <v0l_> oh nice
13:14:45 <gamozo> or enhanced or something
13:14:47 <geist> since then i think they changed it officially to Intel64
13:14:51 <v0l_> I only have intel books at home
13:15:03 <DusXMT> and then there's people who call it x64
13:15:27 <gamozo> geist: you get a 2nd gen ThunderX yet?
13:15:33 <gamozo> I'm waiting for the juicy deets
13:15:39 <geist> yeah i resisted that forever, but we finally had a big meetng and agreed to change the name in fuchsia/zircon officially to x64
13:15:51 <gamozo> Fundamentally will arm64 be capable of high performance is my question
13:15:59 <geist> i'm starting to warm up to it. the name is an abomination, but it does succinctly describe precisely x86-64 in shorter letters with no _ or - in it
13:16:11 <geist> and arm64 and amd64 look too close next to each other
13:16:17 <gamozo> yeah
13:16:20 <SGautam> DusXMT, And then there's people who come up with WOW64
13:16:35 <geist> gamozo: i think the current ship date is somewhere in june
13:16:35 <v0l_> windows people?
13:16:39 <gamozo> wow64 makes sense
13:16:48 <DusXMT> Yeah, but it's confusing if you compare it to x86 and show it to someone unaware; "Wait, so this architecture has 86 bits? :o"
13:16:48 <geist> x32 is really dumb
13:16:51 <SGautam> W32OW64 makes sense IMO
13:16:58 <geist> since you'd think 'oh that's just another name for x86-32, i get it
13:17:08 <geist> but no, it's the stupid x64 + 32bit pointer thing
13:17:10 <SGautam> real men say x16
13:17:15 <SGautam> oh
13:17:17 <geist> so it fails the test: it doesn't directly describe what s going on
13:17:18 <gamozo> you gotta save those 4 bytse per pointer
13:17:19 <SGautam> What? That's stupid
13:17:49 <geist> so x32 should die in a fire as a result
13:18:02 <gamozo> I don't think anyone really runs it
13:18:04 <geist> of my completely arbitrary judgement of the whole merit of that strategy :)
13:18:16 <gamozo> I'm surprised someone was willing to clutter up the kernel to support it
13:18:20 <SGautam> (x32_PTR)x64
13:18:20 <geist> yah
13:18:25 <SGautam> the correct name
13:18:46 <geist> x644GW
13:18:47 <v0l_> linux used x64 if I remember correctly
13:19:01 <variable> x32 is a 64 bit compatible ABI
13:19:03 <geist> x64 i am fairly certain originated from windows
13:19:06 <variable> which is even more fun
13:19:11 <SGautam> i think linux calls it amd64
13:19:18 <geist> it was MSFTs name
13:19:32 <variable> its the 32 bit pointer for 64-bit machines ABI
13:19:34 <SGautam> now i shall call it i64
13:19:36 <v0l_> there were arch/x86 and arch/x64, if I remember correctly
13:19:50 <geist> and thus it slowly infected open source projects and whatnot, primarily ones that have a strong windows run base
13:19:54 <variable> so there is x86, x32, and amd64
13:19:56 <variable> bleh
13:20:04 <geist> v0l_: i think they are all collapsed into a single arch, as it should be
13:20:18 <v0l_> yes, now there is just x86
13:20:18 <variable> just for fun someone should start calling their variant x31
13:20:21 <geist> really x86-32 and -64 are so close that you can and should be able to compile them as a single code base
13:20:29 <SGautam> one thing i like about windows is how most of the time i dont have to give a shit about 32 or 64
13:20:31 <variable> because 0 to 31
13:20:33 <geist> it's what i do for LK and early zircon kernels when we still supported 32bit
13:20:47 <gamozo> what'd you do for ABI?
13:20:49 <geist> if you're actually fairly clever it turns out you can compile the exact same MMU code for 32, 32PAE, and 64bit
13:21:00 <geist> since functioally it's just bit placement, size of entry, and number of levels
13:21:43 <geist> armv7-32 vs armv8-64 though is almost a completely new architecture in every way, so it doesn' tmake sense to maintain the same arch
13:22:49 --- quit: andrei-n (Ping timeout: 240 seconds)
13:22:52 <gamozo> is arm64 much higher cost/power than arm32? I wonder if we'll see arm32 disappear quickly
13:23:55 <geist> it probably is, at the extremel low end
13:24:02 <SGautam> I wonder how much marketing would it require to get x86 off the consumer market
13:24:09 <v0l_> so it seems worth to learn more about arm, I should start it seriously
13:24:11 <SGautam> completely
13:24:25 <gamozo> arm wont be able to compete with x86 on the consumer market
13:24:33 <geist> so armv8 spec says that you can build a 64 only, 64/32 mixed, or 32 only core
13:24:36 <v0l_> at moment
13:24:46 <variable> if we believe that apple will move off of intel chips
13:24:52 <geist> for the most part with one exception ARM cortex-a* armv8 cores are all 64/32
13:24:52 <variable> that'd be a seismic shift
13:24:57 <SGautam> Look at Chromebooks for example
13:24:58 <gamozo> they probably can get to the same level of overall performance for a processor since they can do many core, but I don't see any arm64 chips pushing 4 GHz and pumping 2-4 instructions per cycle
13:25:00 <geist> *except* the cortex-a32, which is a 32bit only armv8 core
13:25:06 <SGautam> They are for the most part architecture independent
13:25:16 <gamozo> consumer needs strong single cores, arm64 I don't think will be able to get that ever
13:25:17 <geist> basically the smallest full functional (mmu/tlb, etc) armv8 core they make
13:25:20 <geist> i wish they hadn't don it
13:25:28 <SGautam> gamozo, Why not?
13:25:48 <SGautam> Limited by architecture design or the company is broke enough to not be able to manufacture high performance chips?
13:25:53 <geist> but probably at the super deep IoT space. say some larger MCU land where you want to run linux but otherwise want to use milliwats, the -a32 exists
13:26:08 <variable> SGautam: fabrication is the where you'll gain most
13:26:10 <gamozo> I'm not convinced that RISC can ever give strong per core performance
13:26:24 <geist> gamozo: i think you can. actually a high end cortex-a75 or so class core is actually fairly beefy
13:26:25 <variable> and intel currently has that as a pure win
13:26:45 <geist> even the a72 machine i have is clearly pumping out close to skylake level performance, it just is onl running at 2Ghz
13:26:59 <variable> (fwiw, I actually quite like the micro-op model; it takes most of the pros from both RISC and CISC)
13:27:14 <geist> ad if you look at the pipeline it's fairly close design wise. that's a 4 year old design but it's decoding 3 instructions, has like 6 back ends, completely OOO, etc
13:27:21 <gamozo> I haven't benched my macchiatobin yet, curious what its single core perf looks like
13:27:30 <geist> yeah tha's the machine i was talking about
13:27:47 <geist> i ran a bunch of random informal benchmarks and once you normalize it to Mhz it actually is not half bad
13:27:56 <gamozo> did you set your jumpers to 2GHz? :P I almost ended up running this at 1.6GHz
13:28:04 <geist> it oly appears to be about 2-2.5x as slow as my skylake
13:28:13 <geist> i did yeah
13:28:42 <geist> key is i think that basically everyone knows cpu architecture. intels lead over the magic knowhow to build highly OOO machines is now gone
13:28:56 <geist> so really it's a matter of time/energy/market potential and fab capability
13:28:59 <gamozo> how are the caches on the a72?
13:29:04 --- quit: baschdel (Ping timeout: 260 seconds)
13:29:06 <gamozo> 4 cycles for L1?
13:29:08 <geist> and fab capability clearly TSMC and global foundaries have largely caught up with intel
13:29:14 <variable> geist: that was always intel's strong suit though: fab
13:29:17 <graphitemaster> I think I broke GitHub
13:29:23 <geist> right
13:29:38 <variable> other vendors usuaully had better tech; intel just crushed it in fab
13:29:41 <geist> so i actuall yhave no reason to believe that Apple wont bust out a skylake class ARM chip if they haven't already
13:29:54 <geist> from a pure footprint size the modern apple arm cores are fairly gigantic
13:30:11 <geist> and in general that's an indicator of performance assuming they're doing everything right
13:30:15 <gamozo> they'll need a damn good x86 emulator when they drop it
13:30:21 <gamozo> which I think they can do
13:30:22 <geist> yah that'll be interesting
13:30:43 <geist> so the thing that arm64 will always lose on is code density though, and the affect that'll have on the icache
13:31:02 <geist> it's my experience that sure enough the .text segments are something like 15-20% larger on equivalent code
13:31:02 <variable> geist: yeah, that's one of the reasons I like the uOp model
13:31:06 <graphitemaster> I went to login to my account and I have 2FA setup so they send me an SMS that I need to put into the page, well I entered the _wrong_ # from the text message and was like "oops" so I select "send a new code" and got into my account, everything is fine, then five minutes later I get another SMS with another code. Now, for the past hour I've been getting nothing but continued SMSes from GitHub for 2FA, 18 of them actually, about one
13:31:06 <graphitemaster> every 3 minutes.
13:31:17 <variable> geist: another thing where arm will lose is specialized benchmarks
13:31:20 <variable> like AES or whatever
13:31:29 <geist> variable: uop model itself isn't interesting because all the high end risc machines do the same thing
13:31:30 <gamozo> they have some crypto accelerators
13:31:40 <geist> what you really mean is 'compressed ISAs such as x86 or thumb'
13:31:51 <variable> geist: true
13:31:52 <gamozo> arm64 is really only risc at this point with regards to being a load/store arch
13:31:58 <gamozo> they get all the fancy vector instructions
13:32:01 <geist> right, it's fairly unrisc
13:32:18 <geist> here's a fun one: armv8.1 adds a whole pile of atomic instructions that replace the existing ones
13:32:29 <geist> and surprise surprise, they're all single instruction read/modify/write
13:32:29 <gamozo> single instruction atomics or TSX-style stuff?
13:32:31 <geist> basically just like x86
13:32:32 <gamozo> yeah
13:33:01 <variable> things I wish worked: conditional instructions
13:33:08 <variable> things I wish never existed: delay slots
13:33:09 <geist> one of these cases where the load/store exclusive stuff was a RISC like exposure of the mechanism that no longer makes sense
13:33:14 <geist> hide it so that the core can do what it needs to do
13:33:29 <gamozo> variable: IT blocks are all you need!
13:33:45 <geist> also conditional instructions are gone in arm64, because that's another risc like exposure of the mechanism
13:33:54 <variable> geist: sure, but I wish they worked
13:34:02 <gamozo> I really don't see who thought it was a good idea to use so many bits in _every_ instruction in arm32 for conditional bits
13:34:08 <variable> in practice most of the research shows its a bad idea
13:34:08 <geist> they worked great in arm32. arm32 is a pleasure to write assembly for
13:34:08 <gamozo> complete waste of bits
13:34:12 <variable> but I love the idea :)
13:34:20 <geist> it's a nice combination of risc and symmetry and power
13:34:27 <geist> but alas, doesn't make sense
13:34:31 <variable> yeah
13:34:35 <gamozo> arm32 was my favorite arch to write exploits for
13:34:42 <gamozo> so many ways to load/store multiple
13:34:44 <variable> I really should learn arm
13:34:49 <variable> I know MIPS and x86
13:34:55 <variable> bleh
13:34:57 <geist> start with arm64, it's fairly simple
13:35:00 <gamozo> arm is just... like 4 arches
13:35:07 <gamozo> arm64 is just 1 (ignoring compat with armv7)
13:35:31 <geist> eactly. and thus far it's a complete pleasure to write system code for
13:35:37 <variable> gamozo: I'll add that to my ever growing list of projects I'll never get to :(
13:35:42 --- quit: dennis95 (Quit: Leaving)
13:35:44 <geist> our hypervisor guys love it too. writing a hypervisor for EL2 on arm64 is fun
13:36:00 <gamozo> I'm porting my OS to ARM64, hope to port my hypervisor to it too
13:36:02 <geist> it's very clean and orthogonal. as if some smart folks got in a room and designed it!
13:36:05 <variable> random trivia question: how long is the longest x86 instruction
13:36:14 <geist> easy. i'll letsomeone else answer
13:36:19 <gamozo> variable: usable it's 15
13:36:23 <doug16k> variable, maximum is 15 bytes
13:36:24 <geist> aww, gamozo got it
13:36:24 <gamozo> no instructions can be used >15 bytes
13:36:35 <gamozo> but, there are many encodings that exceed 15 byets
13:36:37 <gamozo> and thus cannot be used
13:37:01 <gamozo> http://sandpile.org/x86/opc_enc.htm
13:37:02 <bslsk05> ​sandpile.org: sandpile.org -- x86 architecture -- opcode encoding
13:37:05 <gamozo> notes #1 has some good examples
13:37:15 <geist> plus you can generally pile on prefixes
13:37:17 <variable> ya
13:37:19 --- quit: BreakingFree (Ping timeout: 255 seconds)
13:37:29 <geist> blows my mind that modern decoders can sort all that out in a single cycle nowadays
13:37:39 <gamozo> mulitple times too :P
13:37:41 <geist> that must be a pretty amazing block of transitors
13:38:23 <geist> but then it's probably a matter of 'yeah but even those millions of transitors for the decoder are nothing compared to the AVX unit' or something like that
13:38:48 --- quit: Asu (Remote host closed the connection)
13:38:51 <geist> its a matter where moores law let you build more and more complex decoders that are orders of magnitude larger than the previous generations entire cpus and still end up being just a tiny piece of the die
13:39:10 <gamozo> when did intel switch to uop model?
13:39:13 <gamozo> after p4?
13:39:17 <geist> pentium pro
13:39:22 <doug16k> x86 encoding is fairly consistent though
13:39:26 <geist> 686 was their Great Leap Forward
13:39:38 <doug16k> more consistent than it seems
13:39:46 <geist> prior to that it was also generally assumed across the industry that x86 was a dead end and risc would take over
13:39:48 <variable> for 32 bit
13:39:50 <variable> the max is 17
13:39:52 <variable> not 15
13:39:55 <variable> IIRC
13:40:08 <gamozo> I'd loev to see the tests for Pentium Pro
13:40:21 <gamozo> I'm sure the engis were shitting themselves "I hope this works like normal x86 when it's not under the hood"
13:40:23 <gamozo> huge undertaking
13:40:29 <geist> the decoder for ppro was fairly limited. i think it could decode 2 or 3 per cycle, but only if the pattern was a particular way
13:40:46 <geist> something like it could decode 2 simple and a branch or something, so if you wanted to schedule code for it you had to do that
13:41:14 <geist> also first gen ppro ran 16bit code badly. i thik it was because the register renaming stage couldn't handle mixed 8/16/32 register accesses properly
13:41:47 <geist> it treated any mixed accesses as a dependency stall, and since many 8/16 instructions dont modify the top of the register its pretty bad
13:41:48 <gamozo> still really bad on modern x86, that uop to megre the register is brutal
13:41:56 <gamozo> all 16-bit ops are like 2-3x slower than their 32-bit variants
13:42:09 <gamozo> maybe it's not a uop to merge, but it's bad
13:42:21 <geist> but... p2/p3 and then via fairly direct lineage pentium m and core series were all the same arch
13:42:53 <geist> i think it's a ship of theseus a long time ago where the old ppro arch has been superceded, but the lineage is supposedly all the way up through the core line
13:43:06 <geist> it was p4 and atom and whatnot that are the outlyers
13:43:32 <geist> anyway agner fog's optimization guide talks a lot about the ppro decoder and whatnot. good read
13:43:34 <Ameisen> \o/
13:43:40 <Ameisen> everything built, project buidls... then collect2 crashes.
13:43:47 <geist> you can see how they were just dipping their toes into OOO and largely pulled it off. it was a pretty big jump
13:44:16 <geist> note that other vendors were already messing with it. i think you can argue that AMD already tried OOO with K5 (and largely missed due to fab/complexity problems)
13:44:25 <geist> and cyrix and other vendors were doing OOO as well
13:44:34 <geist> intel was probaby a year late to the game
13:44:35 <doug16k> variable, before 80386 there was no limit on instruction length. since 386, 15 bytes is the limit, else #GP fault
13:44:42 --- join: Asu (~sdelang@AMarseille-658-1-105-68.w86-219.abo.wanadoo.fr) joined #osdev
13:44:43 --- part: acln left #osdev
13:45:58 <doug16k> the only way to make an instruction that big is redundant prefixes anyway, so 15 is more than enough
13:46:21 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:46:36 <geist> i had a ppro in college. was a dual ppro 180Mhz with 512KB ram (those were expensive server class chips at the time)
13:46:44 <geist> that was a darn good machine
13:46:54 <geist> was my main machine from probably 96-98
13:47:05 <geist> 512KB cache not ram
13:47:11 <doug16k> yeah, ppro looked so bad in the manuals. you could fill a phonebook with all the potential stalls. in practice they were amazing
13:47:39 <geist> they ran 32bit code nicely though. it was 16bit that they were lackluster on. so if you loaded up win95 on it or whatnot you got hu hum performance
13:47:43 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
13:47:45 <geist> compared to say a pentium mmx 233
13:48:17 <geist> but ppros also had fll speed cache. when the first p2 233s came out, which were almost identical cores to ppro, they just had the 16bit stalls fxied and mmx, but half speed caches
13:48:32 <geist> it wasn't until p2 got to around 300mhz or so that it finally fully surpassed ppro
13:48:48 --- quit: oaken-source (Ping timeout: 256 seconds)
13:49:06 <geist> but since i had a dual socket machine i tried as much as i could to run NT on it
13:49:16 <geist> and then a bit later linux when it finally got SMP support around the same time
13:49:34 <geist> though from a desktop point of view it was a toy compared to NT 4.0, which came out in 96
13:50:01 <geist> i only rebooted grudiginly into win95 to play a game or two
13:50:44 <geist> trying to think how much ram i had in that box. i think 32MB or so
13:50:56 <geist> which would have been a fairly decent size in 96
13:51:13 <geist> iirc NT 4 was fairly unhappy below 16MB, you started getting into swap territory there
13:54:11 <llmm_> I remember my old 80286, I even installed minix 2 on it, alongside dos
13:54:47 <llmm_> linux and windows didn't work on it
13:55:27 <geist> earlier windows 3.0 should have run on it, though probably not great
13:55:38 <geist> iirc, by 3.11 or so it required 386
13:55:44 <_mjg_> fun times
13:56:04 <_mjg_> my neighbor had windows 95, i had 3.11 at the time
13:56:10 <_mjg_> was jelly of desktop icons
13:56:54 <llmm_> yes, I tried win95 but no luck
13:57:08 <geist> yeah and if you had high color and the win95 plus! pack
13:57:16 <geist> awww yeah you had the niiiiice icons
13:57:21 <geist> and maybe full window drag
13:59:47 --- join: sortie (~Sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
14:01:42 --- quit: SGautam (Remote host closed the connection)
14:02:45 <variable> geist: I rememeber purchasing vista "ultimate edition" for the "extras" that never came
14:02:50 <variable> twas the last windows I ever used :/
14:03:01 <CrystalMath> variable: my last windows, too
14:03:13 <CrystalMath> i think i tried 7 on a machine that wasn't mine
14:03:23 <CrystalMath> but that doesn't count i guess
14:03:47 <CrystalMath> oh, and we had windows 10 in a classroom at the university, but that's all ubuntu now, so
14:04:30 --- join: BreakingFree (~libre@199.254.238.212) joined #osdev
14:06:02 --- quit: vdamewood (Quit: Textual IRC Client: www.textualapp.com)
14:10:51 <CrystalMath> would it be possible to reimplement linux from scratch?
14:11:11 <sortie> Sure?
14:11:12 <CrystalMath> clean room
14:11:16 <CrystalMath> and make it GPLv3
14:11:21 <CrystalMath> or better let, AGPLv3+
14:11:37 <CrystalMath> *yet
14:11:58 <sortie> I mean, my OS is essentially a LFS but with my own base system
14:12:18 <dbittman> once you get to the point where you have a decent libc, that's what happens.
14:12:19 <sortie> That's not how licenses work, CrystalMath
14:12:31 <dbittman> then you have to hope you have a decent "auto-build/port" system :)
14:13:41 <CrystalMath> it would be a full reimplementation from scratch, like ReactOS
14:13:41 <CrystalMath> but linux
14:13:41 <CrystalMath> maybe with something else different, hmm....
14:13:41 <CrystalMath> but still compatible
14:13:42 <CrystalMath> it sounds fun
14:13:49 --- join: redgek (~redgek@unaffiliated/redgek) joined #osdev
14:13:52 --- quit: aiwakura (Quit: Ping timeout (120 seconds))
14:14:13 <CrystalMath> sortie: the linux license cannot affect me, because i won't look at the linux code
14:14:16 --- join: aiwakura (~aiwakura@163.172.213.86) joined #osdev
14:14:16 --- quit: v0l_ (Quit: Page closed)
14:14:16 <CrystalMath> nor use any of it
14:14:26 <CrystalMath> sortie: just like the windows license can't affect ReactOS
14:14:46 <Shamar> sortie: actually, one could reimplement the linux kernel api from scratch with another license... why not?
14:15:07 <Shamar> I mean, with a couple of centuries of time...
14:15:12 <CrystalMath> and if there are drivers in linux that are GPLv2+
14:15:17 <CrystalMath> they can link to the new kernel
14:15:21 <CrystalMath> because of the +
14:15:21 <sortie> So CrystalMath wants to reimplement all the software in LFS under AGPLv3+?
14:15:29 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-ugzhbanxmveriuat) joined #osdev
14:15:29 <CrystalMath> no not all the software
14:15:34 <CrystalMath> just the kernel
14:16:21 <Shamar> drivers are linked to the kernel... if they were licensed GPLv2 you cannot reuse them in a GPLv3
14:16:44 <Shamar> you need to rewrite them too from scratch
14:17:08 <peterbjornx> you can also ask the developers to relicense, unlikely but possible
14:18:12 <CrystalMath> Reactix :P
14:18:12 <CrystalMath> Shamar: the kernel API should be done within a year really...
14:18:16 <CrystalMath> especially if the implementation can be less efficient
14:18:40 <Shamar> CrystalMath: with all respect, I doubt it
14:18:44 <CrystalMath> it's the drivers that are an impossible task
14:18:58 <CrystalMath> but hopefully some of them have a license that's compatible, maybe
14:19:48 <Shamar> note that you have to be able to prove the clearroom, in case Google or SCO sue you
14:19:56 --- quit: Esa_ (Ping timeout: 260 seconds)
14:20:37 <Shamar> I'd say this is theoretically possible from a legal point of view (if carefully organized) but practically impossible
14:20:48 --- join: Esa_ (~esa.syt@99-50-199-38.lightspeed.snjsca.sbcglobal.net) joined #osdev
14:20:55 <Shamar> and also... I would ask "why?"
14:20:55 <CrystalMath> Shamar: the internal API would even be different
14:21:02 --- quit: Kimundi_ (Read error: Connection reset by peer)
14:21:16 <CrystalMath> Shamar: i think that some drivers are GPLv2+
14:21:22 <CrystalMath> which means those can be included
14:21:47 <Shamar> CrystalMath: out of curiosity, do you have previous experience in kernel hacking?
14:21:58 <CrystalMath> this is #osdev
14:22:01 <CrystalMath> of course i do
14:22:18 --- join: immibis (~chatzilla@222.155.160.32) joined #osdev
14:22:19 --- quit: kleinweby (Ping timeout: 240 seconds)
14:22:22 <CrystalMath> i work on ReactOS and my own OS project, monolithium
14:22:51 --- quit: LambdaComplex (Ping timeout: 260 seconds)
14:22:51 --- quit: klys (Ping timeout: 260 seconds)
14:23:00 --- quit: attah (Remote host closed the connection)
14:23:02 <CrystalMath> and i was going to GPL-ify an old GPL-compatible-licensed release of Net/2, which i was going to call CrystalOS, but i didn't want to trash my other projects to allocate the time for it
14:23:22 <CrystalMath> i'd have to implement all of the x86 support for it
14:23:25 <Shamar> fine, just asking
14:23:33 --- join: klys (~mdasoh@45.55.20.239) joined #osdev
14:23:51 --- join: kimundi (~Kimundi@i577A94E0.versanet.de) joined #osdev
14:23:56 <CrystalMath> Shamar: rewriting all of linux would be interesting, sadly the drivers are not really feasible without a huge team
14:24:01 <Shamar> technically, however, what's the point of having one more linux?
14:24:11 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
14:24:17 --- quit: Asu (Quit: Konversation terminated!)
14:24:20 <CrystalMath> it'd be a middle finger to Linus Torvalds for not upgrading to GPLv3
14:24:40 <CrystalMath> so, just out of hate
14:24:45 <CrystalMath> maybe it would be C++ too
14:25:03 <Shamar> you know this sound like trolling? :-D
14:25:19 --- join: kleinweby (~kleinweby@unaffiliated/kleinweby) joined #osdev
14:25:25 <CrystalMath> when i said i'm going to write a 486 emulator completely from scratch, they said i was crazy
14:25:32 <CrystalMath> and i did it
14:25:37 <CrystalMath> this also sounds crazy
14:25:42 <CrystalMath> but i know i can do it
14:25:53 <CrystalMath> except for the drivers...
14:25:55 <vdamewood> Just because you did it doesn't mean you're not crazy.
14:26:08 <CrystalMath> vdamewood: well :P
14:26:27 <Shamar> perfect, but don't you think there are more creative OS to hack than rewriting linux?
14:26:36 --- quit: kimundi (Read error: Connection reset by peer)
14:26:43 --- join: kimundi (~Kimundi@i577A94E0.versanet.de) joined #osdev
14:26:58 <CrystalMath> i started writing software, first because i hated that some software is paid
14:27:06 <CrystalMath> and then later because some software is proprietary
14:27:12 <CrystalMath> literally all the programming i ever did
14:27:16 <CrystalMath> was out of some emotion
14:27:25 <CrystalMath> so it's as much art as it is work
14:27:29 <Shamar> I mean, I'm using Debian GNU/Linux right now, but frankly linux is boring
14:27:49 <Shamar> ok
14:28:02 <CrystalMath> if i can't reuse most of the drivers, then i don't know if it's worth it unless i somehow hack around the GPLv2 linking stuff
14:28:09 * vdamewood hugs his copy of the 4.4BSD-Lite 2 source code
14:28:39 <CrystalMath> maybe if the drivers were running in usermode, and not sharing structures with the kernel, but some host program that is GPLv2+
14:28:58 <CrystalMath> and then that host program talks to the kernel with some interface
14:29:01 <CrystalMath> as in a microkernel
14:29:04 <CrystalMath> it could work
14:29:08 <corecode> sure
14:29:17 <corecode> would be much better anyways
14:29:23 <Shamar> sounds like L4
14:29:45 <CrystalMath> tbh that would be great for reactos too
14:29:54 <CrystalMath> reactos is seriously driver-deficient
14:30:03 <corecode> hurd it
14:30:05 <CrystalMath> if there was a host program providing linux drivers
14:30:06 --- quit: empy (Ping timeout: 264 seconds)
14:30:13 <CrystalMath> it would really help
14:30:19 <Shamar> corecode: I was thinking about Hurd too :-)
14:31:13 <Shamar> so you should have a kernel with an api that let userspace programs directly communicate with hardware
14:31:18 --- join: empy (~l@174-21-142-205.tukw.qwest.net) joined #osdev
14:31:18 --- quit: empy (Changing host)
14:31:18 --- join: empy (~l@unaffiliated/vlrvc2vy) joined #osdev
14:31:25 --- quit: kimundi (Ping timeout: 256 seconds)
14:31:44 <CrystalMath> Shamar: well, all it takes is IOPL=3 and the ability to map physical memory
14:31:48 <corecode> their hardware
14:31:49 <Shamar> and a linux emulator in userspace running the drivers
14:31:58 <CrystalMath> Shamar: and some good locking system
14:32:11 <CrystalMath> but even normal processes deserve that
14:32:28 <CrystalMath> in ReactOS/Windows, CSRSS can get IOPL=3
14:32:33 <CrystalMath> so it can do in/out
14:32:37 <Shamar> well, linux ABI is notably unstable though
14:33:57 <Shamar> however if you release the linux kernel ABI emulator as GPLv2, you could use the linux's drivers I think
14:34:27 <CrystalMath> or GPLv2+, so the code of the emulator itself can be used in GPLv3 projects, without the GPLv2-only stuff
14:34:36 <Shamar> right
14:34:38 <CrystalMath> don't have to limit my code
14:34:51 <Shamar> sure
14:35:43 <Shamar> I see it as a HUUUGGEEE challenge (even for osdev standards...) but AFAIK it could work
14:35:56 <CrystalMath> i might really be useless though, linux can still be Tivoized
14:36:11 <CrystalMath> even if my hack OS or a full reactix is GPLv3
14:36:21 <CrystalMath> companies can still put linux in tivo-like devices
14:36:24 --- quit: xenos1984 (Quit: Leaving.)
14:36:33 <CrystalMath> as long as any linux... well any good system... is GPLv2
14:36:38 <CrystalMath> it will be a problem
14:36:49 <sortie> Oh no my OS is ISC licensed
14:36:53 --- join: kimundi (~Kimundi@i577A94E0.versanet.de) joined #osdev
14:36:53 <CrystalMath> even if linux changed to GPLv3 today it wouldn't solve it
14:37:23 <CrystalMath> but maybe in a decade they'd have to start letting users flash their tivo devices to be able to use linux 12.5
14:37:39 <CrystalMath> *12.6
14:37:42 --- join: LambdaComplex (~LambdaCom@unaffiliated/lambdacomplex) joined #osdev
14:37:53 <CrystalMath> assuming they don't give up on the whole even number = stable version thing
14:38:18 <Shamar> CrystalMath: are you really sure you are directing your energy in the most effective direction?
14:38:28 <CrystalMath> sortie: quite literally, if people never asked money for software, i never would have learned any programming language
14:38:58 <CrystalMath> i learned how to write software because i was angry and i thought "i will make the same thing and give it away for free"
14:39:09 --- quit: glauxosdever (Quit: leaving)
14:39:13 <CrystalMath> i became a programmer out of hatred
14:39:23 <Shamar> CrystalMath: but what's the point for you, money to save or freedom to spread or... what else?
14:40:02 <CrystalMath> Shamar: i don't think about myself as much as the good of everyone
14:40:36 <CrystalMath> but of course i love that there's a lot of free software i can use
14:41:04 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
14:41:16 <CrystalMath> at first my idea was making gratis software, but after realizing that doesn't really hit the point well enough, i switched to making libre software
14:41:57 <Shamar> actually libre software can be sold
14:42:01 <CrystalMath> i know
14:42:27 <Shamar> and you can be paid to write free software
14:42:29 <CrystalMath> however, it is always possible for someone to distribute it for free
14:42:39 <Shamar> sure
14:42:40 <CrystalMath> well that technically makes the whole thing better
14:42:51 <Shamar> fine
14:42:58 <CrystalMath> it's no longer evil, because it's not out of reach for the poor
14:43:46 --- quit: redgek (Remote host closed the connection)
14:43:46 <Shamar> mmm... except that poor need a pc to run it...
14:44:46 <Shamar> beware that if your enemy is capitalism, you should be pretty aware of how it works
14:45:20 <Shamar> in particular if your way to fight it, is by hacking software
14:45:27 --- quit: ALowther (Ping timeout: 240 seconds)
14:46:07 --- quit: Vercas (Quit: No Ping reply in 180 seconds.)
14:46:36 --- join: Vercas (~Vercas@gateway/tor-sasl/vercas) joined #osdev
14:47:04 <corecode> capitalism makes me sit in a house with food in a refrigerator
14:47:18 --- join: redgek (~redgek@unaffiliated/redgek) joined #osdev
14:47:43 <Shamar> writing a surrogate for Windows or a surrogate of Linux might not be the most effective approach
14:48:23 <Shamar> corecode: everybody loves the nuts :-D
14:48:31 --- quit: FreeFull (Ping timeout: 260 seconds)
14:48:52 --- join: FreeFull (~freefull@defocus/sausage-lover) joined #osdev
14:49:23 <corecode> what nuts
14:49:39 --- join: pisculic1i (pisculichi@shell.bshellz.net) joined #osdev
14:50:07 --- quit: immibis (Ping timeout: 256 seconds)
14:51:03 <Shamar> you look at the few things that capitalism gives you, and you don't see the many things that it takes from you and from everybody else
14:51:22 <corecode> what does it take from me?
14:52:57 --- join: MathAmphetamine (~coderain@reactos/developer/theflash) joined #osdev
14:52:57 <Shamar> well it depends: usually time, freedom, often friendship and love...
14:53:11 <MathAmphetamine> <CrystalMath> i mostly disliked non-gratis software because it's out of reach for the poor, but also because it spies on users, and stuff
14:53:15 <MathAmphetamine> <CrystalMath> i was like 12 when i started programming
14:53:21 <MathAmphetamine> i don't know if those two messages got through
14:53:21 <corecode> i don't think that's capitalism that does that
14:53:25 <MathAmphetamine> i lost connection
14:53:41 --- quit: kimundi (*.net *.split)
14:53:41 --- quit: JusticeEX (*.net *.split)
14:53:41 --- quit: CrystalMath (*.net *.split)
14:53:41 --- quit: zhiayang (*.net *.split)
14:53:41 --- quit: nightmared (*.net *.split)
14:53:41 --- quit: _sfiguser (*.net *.split)
14:53:41 --- quit: nj0rd (*.net *.split)
14:53:41 --- quit: doug16k (*.net *.split)
14:53:41 --- quit: bauen1 (*.net *.split)
14:53:41 --- quit: awordnot (*.net *.split)
14:53:41 --- quit: tux3 (*.net *.split)
14:53:41 --- quit: CWiz (*.net *.split)
14:53:41 --- quit: pisculichi (*.net *.split)
14:53:41 --- quit: multi_io (*.net *.split)
14:53:41 --- quit: Dreg (*.net *.split)
14:53:41 --- quit: giraffe (*.net *.split)
14:53:41 --- quit: kuldeep (*.net *.split)
14:53:42 --- quit: trn (*.net *.split)
14:53:42 --- quit: bpye (*.net *.split)
14:53:42 --- quit: diginet (*.net *.split)
14:53:42 --- quit: eam (*.net *.split)
14:53:42 --- quit: Gaudasse (*.net *.split)
14:53:42 --- quit: Kydd (*.net *.split)
14:53:42 --- quit: htafdwes (*.net *.split)
14:53:54 <MathAmphetamine> oh... no, apparently i didn't
14:53:54 <corecode> hi MathAmphetamine
14:54:03 <MathAmphetamine> the server went down or something
14:54:13 <Shamar> corecode: it's called market segmentation
14:54:16 <corecode> i want a better programming language, but i don't know where to start
14:54:21 --- nick: MathAmphetamine -> CrystalMath
14:54:25 <CrystalMath> hi corecode :)
14:54:30 --- join: kimundi (~Kimundi@i577A94E0.versanet.de) joined #osdev
14:54:30 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
14:54:30 --- join: zhiayang (~zhiayang@124.197.97.227) joined #osdev
14:54:30 --- join: nightmared (~nightmare@unaffiliated/nightmared) joined #osdev
14:54:30 --- join: _sfiguser (~sfigguser@130.108.214.77) joined #osdev
14:54:30 --- join: nj0rd (~nj0rd@i577BC046.versanet.de) joined #osdev
14:54:30 --- join: doug16k (~dougx@198-91-135-200.cpe.distributel.net) joined #osdev
14:54:30 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
14:54:30 --- join: awordnot (~awordnot@67.184.137.130) joined #osdev
14:54:30 --- join: tux3 (~tux@unaffiliated/tux3) joined #osdev
14:54:30 --- join: CWiz (~cipherwiz@216.21.169.52) joined #osdev
14:54:30 --- join: multi_io (~olaf@185.56.132.5) joined #osdev
14:54:30 --- join: Dreg (~Dreg@fr33project.org) joined #osdev
14:54:30 --- join: kuldeep (~kuldeep@unaffiliated/kuldeepdhaka) joined #osdev
14:54:30 --- join: bpye (~bpye@unaffiliated/bpye) joined #osdev
14:54:30 --- join: diginet (~diginet@107.170.146.29) joined #osdev
14:54:30 --- join: htafdwes (~elspru@liberit.ca) joined #osdev
14:54:30 --- join: eam (~eam@ruby/jackass/eam) joined #osdev
14:54:30 --- join: Gaudasse (~Gaudasse@bitwise.fr) joined #osdev
14:54:30 --- join: Kydd (kydd@dikunix.dk) joined #osdev
14:54:39 --- join: trn (jhj@prone.ws) joined #osdev
14:54:46 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
14:54:46 <Shamar> CrystalMath: no didn't read thos messages
14:54:49 <corecode> Shamar: i'm pretty sure i have more free (leisure) time that i'd have if i was a subsistence farmer
14:55:01 --- quit: diginet (Excess Flood)
14:55:04 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
14:55:12 <CrystalMath> Shamar: i think it's understandable that my philosophy changed since i was 12yo :P
14:55:25 --- join: diginet (~diginet@107.170.146.29) joined #osdev
14:55:26 <Shamar> CrystalMath: I didn't read it
14:55:31 <Shamar> actually yes
14:56:00 <CrystalMath> Shamar: back then it was about software being gratis
14:56:06 --- quit: freakazoid0223 (Ping timeout: 260 seconds)
14:56:29 <corecode> CrystalMath: come and make open source hardware
14:56:39 <corecode> what used to be called just hardware back in the day
14:56:42 --- quit: port443 (Quit: Candlejack has no power he)
14:56:46 <CrystalMath> corecode: heh :)
14:56:47 --- join: giraffe (skarn@gateway/shell/firrre/x-qqjmzhfplfteggai) joined #osdev
14:57:04 <corecode> everything came with a schematic
14:57:09 --- nick: giraffe -> Guest43927
14:57:42 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
14:58:28 --- quit: Darksecond (Quit: ZNC - 1.6.0 - http://znc.in)
14:58:44 --- join: diginet_ (~diginet@107.170.146.29) joined #osdev
14:58:51 <Shamar> corecode: sound a bit like a lack of fantasy. you should not compare capitalism with a world based on subistence farming
14:59:33 <corecode> no?
14:59:34 --- join: kuldeep_ (~kuldeep@unaffiliated/kuldeepdhaka) joined #osdev
14:59:35 <Shamar> it's like saying: Windows is fine! I mean do you really want DOS?
14:59:53 --- join: port443 (~wizardmin@mtndewcode.red) joined #osdev
15:00:00 <Shamar> there's a plenty on unexplored alternatives
15:00:10 <corecode> ah yes
15:00:46 --- quit: diginet (Ping timeout: 260 seconds)
15:00:46 --- quit: maslan (Ping timeout: 260 seconds)
15:00:52 <corecode> i'd love to chat about possible improvements, but this channel is probably the wrong place
15:00:53 --- nick: diginet_ -> diginet
15:01:12 <Shamar> corecode: I was thinking the same :-)
15:01:17 --- quit: kuldeep (Excess Flood)
15:01:21 --- join: Darksecond (~darksecon@a82-94-53-70.adsl.xs4all.nl) joined #osdev
15:01:27 --- quit: CWiz (Ping timeout: 240 seconds)
15:01:35 --- join: maslan (~maslan@192-0-134-110.cpe.teksavvy.com) joined #osdev
15:01:49 --- join: CWiz (~cipherwiz@216.21.169.52) joined #osdev
15:03:19 <Shamar> btw, CrystalMath, IMHO, you should direct your talent into something more innovative or more useful than rewriting Linux, if your end goals are political
15:04:34 --- quit: unixpickle (Read error: Connection reset by peer)
15:07:23 <Shamar> CrystalMath: if you consider how your philosophy changed in the past, you might consider alternative philosophies for the future
15:07:39 <CrystalMath> of course
15:07:58 <Shamar> and I guess that basing your life on hate, is not what you will do in the future
15:09:01 <CrystalMath> oh, it's not what i do, but it's what i did then and i learned a lot of things, and then i suppose i went further in that direction
15:09:41 <CrystalMath> and some of the things i say don't make a lot of sense, so i suppose it's reasonable to say my philosophy may change
15:11:56 <Shamar> for example, in the past I spent a huge amount of time on a free AGPLv3 framework (that I still think IS ahead of times) because I wanted to create a successful company aroung it
15:12:11 <CrystalMath> Shamar: sometimes i just read about something and then get angry about it and then talk about it on IRC
15:14:14 <Shamar> now it was a great project from a technical point of view, I've learnt a lot and I used it myself in a couple of projects, but it never got traction
15:15:30 <CrystalMath> i see
15:15:37 <Shamar> so I was a bit deluded...
15:15:58 <CrystalMath> at least i never aimed for success...
15:16:01 <CrystalMath> never disappointed myself :P
15:16:34 <Shamar> well, I did! And it has been a good thing.
15:18:57 <Shamar> because when it became clear that the nobody was really interested in a framework to build high quality DDD software, I took some time to consider how it was possible, given the hype that DDD had and the actual need of business
15:19:11 <corecode> what is DDD?
15:19:23 <Shamar> corecode: domain driven design
15:19:31 <corecode> what's that
15:20:37 <Shamar> https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
15:20:40 <bslsk05> ​www.amazon.com: Domain-Driven Design: Tackling Complexity in the Heart of Software: Eric Evans: 8601300201665: Amazon.com: Books
15:21:03 <corecode> you have a short version where i don't have to buy a book?
15:21:43 <Shamar> https://www.infoq.com/minibooks/domain-driven-design-quickly
15:21:45 <bslsk05> ​www.infoq.com: Domain Driven Design Quickly
15:22:42 <corecode> so no short version
15:22:45 <Shamar> corecode: DDD is a method to design and develop software whose value is in the complex business rules that it has to follow/enforce
15:23:31 --- quit: godel (Ping timeout: 260 seconds)
15:23:31 --- quit: sortie (Quit: Leaving)
15:23:43 <corecode> how does it differ from other design methods?
15:24:11 <Shamar> it's based on making your sources adopt the language of the domain expert, a person (or a group) that is expert in the business
15:24:25 <corecode> ah yes, that makes sense
15:24:34 <Shamar> in many ways, for example you should not find technological terms in your domain model
15:24:41 --- quit: Darksecond (Read error: Connection reset by peer)
15:25:54 --- join: Darksecond (~darksecon@a82-94-53-70.adsl.xs4all.nl) joined #osdev
15:25:57 <Shamar> but actually it's in part a design technique in part a development technique...
15:26:34 --- quit: vdamewood (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:27:28 <Shamar> btw, after analyzing the various issue that caused my failure with my DDD framework, I realized that actually I do not really care about the target projects that it would have improved
15:27:38 <corecode> :)
15:27:45 <corecode> making tools for tools sake
15:27:54 <Shamar> not exactly
15:28:03 <Shamar> the fact is that I use DDD at work
15:28:11 <CrystalMath> Shamar: i had to make a tool like that in college
15:28:20 <Shamar> I work for big banks
15:28:41 <Shamar> the kind of project I apply DDD to have budgets in the 6 figures
15:29:11 <Shamar> I was optimizing that specific use cases
15:29:38 <corecode> ah that's why you don't like capitalism :)
15:30:22 <Shamar> not banks in particular, but projects that have relatively high budgets and an high non-technological complexity
15:30:38 <Shamar> corecode: yes, because I know very well how it works! ;-)
15:31:17 <corecode> do you?
15:31:28 <Shamar> well, I think so :-)
15:32:46 <Shamar> not just for my job, but even for my studies at University: I studied Political Science, that is a lot of history plus a lot of economy
15:34:07 <Shamar> btw, CrystalMath ultimately I do not care about how to help software companies improve their profits on such large projects
15:34:35 <corecode> ultimately?
15:34:38 <corecode> or formost
15:36:56 <Shamar> uhm... I do not care at all... DDD is a funny technique when your process is very complex (eg you talk to a couple of lawyers during analysis)
15:38:29 <Shamar> it's funny to see the code that contraddict the experts after a while, and you are able, debugging, to explain the expert why the code IS RIGHT and their insight is wrong (according to what they have explained you)
15:38:58 <Shamar> but... it's just funny... it's not good
15:39:13 --- quit: daniele_athome (Ping timeout: 240 seconds)
15:39:39 <Shamar> so I asked myself: what I do really care about?
15:39:55 <Shamar> the answer was obvious: my daughters
15:41:10 <Shamar> so no I decided to waste my free time exploring alternative to the mainstream stack that goes from the dynamic linking to the glory of the browsers
15:41:41 <Shamar> via my own osdev
15:42:08 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
15:42:48 <Shamar> my suggestion CrystalMath is to analyze what you really care about, and focus your curiosity on something that help with that
15:43:55 <Shamar> I care about my daughters and I'd like to let them live in a better technological world that this shitty mess...
15:43:59 --- join: daniele_athome (~daniele_a@5.170.124.155) joined #osdev
15:45:12 <corecode> shitty mess?
15:45:14 <Shamar> since nobody else seem to really challenge the status quo, like if the web was always this mess and was always gone to remain such mess, I do it myself
15:45:15 <corecode> it's delightful
15:45:22 <corecode> it can be better
15:45:34 <corecode> but it's pretty good as a baseline
15:45:47 <Shamar> what are you talking about, exactly
15:45:59 <Shamar> I might be in deep disaccord :-)
15:46:04 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
15:46:15 <corecode> the overall situation
15:46:18 <corecode> tech
15:46:27 <Shamar> lool!
15:46:28 <corecode> best it ever has been
15:46:42 <Shamar> I strongly disagree
15:46:51 <corecode> you don't have to toggle in programs into "microcomputers"
15:46:57 <corecode> when was it better?
15:47:33 <Shamar> uh... this is going to be a long discussion! but I have to go sleeping! :-)
15:48:11 <Shamar> it was better when the web was a standardized content distribution system, for example
15:48:13 --- quit: daniele_athome (Ping timeout: 240 seconds)
15:48:23 <corecode> but it still is
15:49:01 <Shamar> no, now it's an application platform
15:49:36 <Shamar> HTML5 (that is Javascript in diguise) destoyed the semantic web
15:49:57 --- quit: redgek (Quit: Leaving)
15:51:23 <corecode> html5 is actually a step towards more semantics
15:51:39 <corecode> that whole web 2.0 js stuff is different tho
15:51:41 <Shamar> it turned it into a weapon since every time you run a Javascript controlled from a company in the US (or in China or in Italy or whatever) you are giving control of your computer to a foreign state
15:51:53 <corecode> sure
15:52:05 <corecode> i don't like that either
15:52:25 <corecode> but it sure is convenient for all the webpage authors
15:53:13 <Shamar> this mess? do you know how many js framework exists?
15:54:19 <Shamar> and have you ever considered that with XHTML, an Ad blocker would have been coded in few XSLT lines?
15:54:47 <Shamar> it's not delightful at all
15:55:05 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
15:55:37 <corecode> that specifically is not good
15:55:51 <Shamar> more, in the past, from 70 to early 90, CS research was spread all over the world
15:56:06 <Shamar> Dijkstra noticed that it was turning into a monoculture
15:57:02 <Shamar> now, it IS a monoculture
15:57:42 <corecode> in what way?
15:57:50 <corecode> you mean js?
15:57:52 <Shamar> now back to something technical, do you want to talk about how much Linux sucks compared to eg Plan 9?
15:58:09 <corecode> no
15:58:11 <Shamar> corecode: no in general, IT...
15:58:46 <Shamar> take AI research: most researcher and most AI based companies are in the US
15:59:20 <Shamar> Microsoft is in the US, Facebook too, Google too, Amazon too
15:59:26 <corecode> so?
15:59:31 <Shamar> monoculture
15:59:40 <corecode> i don't think monoculture is the right term there
15:59:51 <Shamar> there is ONE culture
16:00:13 <corecode> if you define it very broad
16:00:17 <Shamar> that spread in information technology
16:00:33 <Shamar> no the shared part is not much broad
16:00:40 <Shamar> it's very specific
16:00:52 <Shamar> it's the culture of american capitalism
16:00:57 <corecode> aha
16:01:04 <Shamar> pretty specific
16:01:29 <Shamar> currently the only alternative is from China
16:01:38 <corecode> baidu?
16:01:45 <Shamar> which, I think you would agree, is not a nice thing
16:03:01 <Shamar> no I was thinking about Chinese researchers
16:03:09 <corecode> ah
16:03:19 <corecode> france does a lot of research
16:03:31 <corecode> sweden too
16:03:42 <corecode> naturally china
16:03:48 <corecode> japan
16:03:57 <corecode> korea
16:04:07 <Shamar> everybody do research
16:04:13 <Shamar> the point is how
16:04:28 <corecode> they write papers
16:05:24 <Shamar> yes, in China and US with a huge budget and motivation (for different reason)
16:06:06 <Shamar> best European researchers... go work in US (or for US corporations)
16:06:48 <Shamar> now, the problem is not this fact in itself
16:07:14 <Shamar> everybody should be free to go whereever he want
16:07:38 --- join: Beato (~Beato@unaffiliated/beato) joined #osdev
16:08:04 --- join: epony (~nym@79-100-134-61.ip.btc-net.bg) joined #osdev
16:08:09 <Shamar> but this monoculture hurts IT itself, because it reduce variety and it concentrate the power that come from knowledge
16:08:30 --- quit: aalm (Ping timeout: 264 seconds)
16:09:04 <Shamar> so... now we could talk about signals, about ioctl/fcntl, about dynamic linking, about priviledge escalations...
16:09:20 <Shamar> what exactly do you think is delightful...
16:09:29 --- join: aalm (~aalm@37-219-119-194.nat.bb.dnainternet.fi) joined #osdev
16:10:33 <corecode> that i can listen to music streamed from somewhere else that was created by some other person while cycling
16:10:44 <corecode> or to podcasts
16:11:13 <Shamar> hum... the nuts...
16:11:20 <corecode> what nuts?
16:12:01 <corecode> this must be an idiom i don't know
16:12:04 <Shamar> these are not such a great think compared to your mails traveling in clear text among smtp servers, don't you thing?
16:12:21 <Shamar> nuts: small things
16:12:26 <corecode> ah
16:12:44 <epony> Shamar what mono-culture?
16:12:49 <corecode> yea, i try to use gpg, but few people use it
16:12:51 <corecode> it's pretty bad
16:14:12 <epony> Shamar n"i"ts and thin"k"
16:14:58 <corecode> maybe mails not being encrypted is "nuts"
16:15:13 <corecode> only old people use mail anyways
16:15:19 <Shamar> lool
16:15:28 <corecode> i think instagram is where it's at
16:15:57 <Shamar> yeah, every enterprise in the world communicate via instagram
16:16:11 <corecode> actually, xmpp over instagram
16:16:38 --- quit: BreakingFree (Remote host closed the connection)
16:16:40 <epony> What do you call "enterprise"?
16:16:50 <Shamar> company
16:17:19 <Shamar> all companies in the world communicate via xmpp over instagram? are you sure?
16:17:19 <epony> That's wrong terminology then.
16:17:30 <Shamar> sorry... my english sucks..
16:17:40 <corecode> yes, all do that
16:18:10 <epony> It's alright, maybe you're picking the terms online. It is a lingo that shows popular pseudo media influence.
16:18:28 <corecode> epony: what's the difference?
16:18:41 --- join: BreakingFree (~libre@199.254.238.212) joined #osdev
16:18:53 <corecode> company, enterprise, firm, business
16:18:57 <Shamar> oh... somebody should tell it Google, I wonder how many inactive accounts they have on GMail then...
16:19:05 <epony> That this conveys a certain pessimistic or rather pretense annoyed position on the view of matters which are very insignificant at all.
16:20:10 <Shamar> epony: ??
16:20:27 <epony> If you line up all the terms together, it does not give you many options to say something other than the generally circulated conclusions presented to the reader / viewer / public before their own process of reaching this point of view.
16:20:45 <epony> So, don't mono-culture IT.
16:21:37 <corecode> i think IT is sometimes too much all over the place
16:21:45 <epony> Just only the term "IT" is loaded with bullshit.
16:21:50 <corecode> yea
16:22:06 --- quit: BreakingFree (Remote host closed the connection)
16:22:19 --- quit: kimundi (Ping timeout: 240 seconds)
16:22:20 <epony> Too general of a term, and usually used to mark consumer electronics related media talk.
16:22:32 <corecode> ah?
16:22:36 <epony> Just like the term "tech".
16:22:45 <corecode> to me it sounds like data processing
16:22:55 <epony> It sounds like nothing.
16:23:05 <Shamar> epony: CS would be more accurate?
16:23:06 <epony> Empty word.
16:23:09 <corecode> is it grumpy sunday night?
16:23:13 <epony> Nope.
16:23:36 <epony> It is optimistic attitude readjustment nits.
16:23:56 <geist> blergh? or spluh. this is the question
16:24:10 --- join: BreakingFree (~libre@199.254.238.212) joined #osdev
16:24:16 <epony> It's not that grim and muddy as it's getting spread around. That's journo-FUD.
16:24:22 <Belxjander> IT? . Information Technology, Intelligence Trapping, Incorrigdable Twattery ? :) all-of-the-above?
16:24:30 --- quit: BreakingFree (Remote host closed the connection)
16:24:36 <epony> :-)
16:25:10 <Shamar> btw... it's late here... need to go sleep...
16:25:25 <Shamar> good night!
16:25:36 <epony> So, the point is, there is no mono-culture, it is too many loud noises with no meaning, which make it appear that there is no other ideas and choices.. Which is incorrect.
16:25:39 <geist> before you go. is 'shamr' a word in in another language?
16:25:46 <geist> i know of someone else that uses it, who is russian
16:25:56 <geist> so thinking it's a russian thing, but i can't find it online
16:26:03 <epony> Shamar is a "slap" to the face.
16:26:04 <Shamar> Shamar is ebraic
16:26:18 <Belxjander> epony: I treat the acronym as the regular word and generally throw it back in the speakers face by getting them to define what the hell "it" is that they are talking about...and absolutely refuse the whole "you know" argument...with "no, actually I don't because I can't read your mind...." as a good starting point :)
16:26:32 --- join: BreakingFree (~libre@199.254.238.212) joined #osdev
16:26:33 <Shamar> it means "custodian"
16:26:34 <epony> Belxjander That's what I asked.
16:26:35 <geist> oh i read it as shamr. never mind
16:26:41 <geist> but maybe shamar is it too
16:27:09 <epony> geist Your suggestions was right if read in Russian.
16:27:27 * geist nods
16:27:33 <geist> i'll have to ask him next time i see em
16:27:48 <epony> Belxjander I asked "what mono-culture"..
16:28:28 <epony> It's interesting to see what makes people so pessimistic or dummy mode so they repeat the same thing over and over without much question is it really so?
16:28:38 <Belxjander> epony: well yeah... 2 people with 5 opinions each? same thing as the idea of "normal" and "common sense" being defined by the opposite ;)
16:29:08 <Shamar> by mono culture I mean a culture that is structured around a limited number of believes shared among all the person in a group
16:29:25 <epony> Shamar Well, there you go, it is not so.
16:29:26 <Belxjander> all psychology is abnormal with "normal" the lack of an abnormality ( general consensus by default presumed and assumed)
16:30:21 <Belxjander> Shamar: anything technology related is about as mono-cultured as herding an island of cats... ( can7t be done and they are NOT all grey after midnight...)
16:30:21 <epony> Shamar Within a small team of people who are in the same room at work, or share the same boss... maybe. Outside that micro fart zone, it's no mono-culture, too many of a variety of everything.
16:31:02 --- quit: jordyd (Quit: Bye!)
16:31:24 <epony> "beliefs"
16:31:29 <Shamar> epony: thanks
16:31:49 <Belxjander> epony: even within such a microcosm for a project it won't be a mono-culture since individuals in the group will compete idea-wise for presenting various solutions to problems the group will face in dealing with the project changes over time
16:32:50 <epony> I think that mono-culture can only be used in farming vast areas of land with the same genome of plant / animal for industrial process.
16:34:00 <Shamar> guys, how many of you do not have a stackoverflow account?
16:34:08 <epony> It is an offense to slap (pun intended) this term on information technology disciplines and areas for all people actually in these fields (pun again) of work. Observers have the right to be called unqualified at comments.
16:34:24 <epony> Shamar Why would you want such an account?
16:34:32 <Belxjander> epony: mono-culture is cloning as far as I am concerned...and that's generally non-viable without a seriously self-imposed dependence on technologies we don't have (and the variations in biology alnog with viral and other pathogens generally make cloning a dead-end tech for long-term survival purposes afaik)
16:34:35 <Shamar> ok
16:34:54 <epony> Shamar I typically ignore these stack exchange sites as stupid and utterly full of baseless advice.
16:34:57 <Shamar> how many of you do not use google to search things on internet?
16:35:07 * Belxjander doesn't have one because he doesn't contribute to that site
16:35:08 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
16:35:26 <epony> There is 1% of actual information that is surrounded by a large time sink of useless commentaries and hearsay.
16:35:32 <Shamar> Belxjander: I mean you use it to find answers if not to ask
16:35:37 <Belxjander> Google, I use that regularly (along with my two android tablets ...)
16:35:56 <epony> I disagree with the model of Q&A sites for dummies and don't use or contribute to these too.
16:36:04 <Belxjander> Shamar: well using stackoverflow...semi-randomly...but no I don't have an account there
16:36:13 <Shamar> fine
16:36:17 <Shamar> it's not a sin
16:36:26 <epony> If there is information to be found, direct source of information is it, not a commentary site for uneducated random people.
16:36:52 <Shamar> I was just trying to make you realize that we all use the same tools that come from the same place
16:37:09 <epony> Shamar No, we don't all use the same web sites.
16:37:36 <Shamar> ok... I'm glad to be wrong :-)
16:37:39 <epony> :-)
16:37:52 --- quit: samathy (Quit: WeeChat 2.1)
16:37:56 <Shamar> but now I really need to go sleep.. good night!
16:37:57 <Belxjander> Shamar: actually...no we don't...we use a common theme of tools for the same tasks but not the same tools for every individual to solve the same problems
16:38:28 <Belxjander> good night Shamar
16:38:34 --- quit: Shamar (Quit: leaving)
16:39:06 <epony> Shamar Actually I know what you meant, but it's not "all the people" and not "the same pages" :-) Some of us actually call research "papers and publications" of scientific and/or encyclopaedic or text book quality information, rather than using a silly pseudo ranking search engine with commercial goals.
16:40:02 <Belxjander> epony: missed him here is what appears to have happened... and yeah...good information sources are always better ;)
16:41:21 <epony> Well, one person less "mono" talker at the moment :-)
16:42:19 <epony> Mono-culture is reproducing the same series of pessimistic and otherwise mass circulated prepositions and misinformation.
16:42:40 <Belxjander> then there is the "idea of language" vs "language(s) spoken/written" and the confusion endemic of assuming the idea is the basis of the instances :)
16:42:49 --- quit: Tazmain (Quit: Leaving)
16:43:48 <pounce> are each of the serial control registers 8bits wide?
16:44:11 <epony> In any case, it is not that pleasing to hear a young person express such a view on a field that is so interesting and unlimited in ideas and options.
16:44:18 <corecode> pounce: on what chip
16:44:26 <variable> I'm somewhat confused. Am I supposed to read the documentation before I clone llvm ? https://llvm.org/docs/GettingStarted.html#checkout makes it very unclear
16:44:28 <bslsk05> ​llvm.org: Getting Started with the LLVM System — LLVM 7 documentation
16:44:31 <Belxjander> epony: do you know of anyone using distcc with Amazon/Google Cloud Compute setups for accelerating compilation or working around compiling projects where the memory on the machine needing the results is not enough ?
16:44:46 <variable> Belxjander: that'd be ... expensive
16:44:49 <corecode> epony: i still can't get a grip on the overwhelming complexity, especially in distributed systems
16:45:03 <variable> Belxjander: we're doing distributed compilation at work, but for jvm not C
16:45:04 <pounce> corecode: amd64
16:45:15 <epony> I don't know anyone using GC/AWS.
16:45:41 <epony> But I know what these are, incl. distc
16:45:59 --- quit: Guest31018 (Ping timeout: 248 seconds)
16:46:25 <Belxjander> variable: I'm running into a limitation on my laptop just building up a basic installation (the machine locks up and dies partway through some packages so I need to offload compilation somewhere ... currently looking at "what can I do with free tier AWS or Google Cloud systems and distcc? as a possible solution
16:46:41 <epony> Belxjander what are you compiling?
16:47:01 <variable> <troll> stop using a compiled language </troll>
16:47:19 <epony> Belxjander Can your laptop pass a memtest https://en.wikipedia.org/wiki/Memtest86
16:47:19 <bslsk05> ​en.wikipedia.org: Memtest86 - Wikipedia
16:47:31 <Belxjander> generally just trying to get a recent KDE with plasma-desktop environment installed along with Container Virtual-Machine support and a few other things...unless I can find a decent supply of memory that I can spend bitcoin to purchase
16:47:48 <epony> Belxjander what is the target OS / distribution?
16:47:52 <Belxjander> epony: yeah...memtest passes with no issues
16:48:03 <epony> Belxjander raise the mem on the VM
16:48:38 <Belxjander> the issue is more "how much" memory and that when I have Linux running swap-(files/partitions) are unsupported by default..regardless of the kernel built-in support for them being enabled
16:48:41 <epony> KDE runs on laptops, it is not reasonable to define your work load as unsolvable on a single system
16:49:00 <Belxjander> it's not "blah in a VM"...
16:50:03 <Belxjander> I'm sertting up the host system and including VM's and whatnot as addditional package items that also fail due to "ceph" and other KDE/Gnome packages not completing the build process to install
16:50:07 <Belxjander> +
16:50:15 <epony> Maybe you can talk specifics and define what size is the memory / CPU model in the machine and how it is delegated to various tasks
16:50:34 <Belxjander> Linux kernel 4.16.3
16:50:39 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:4dbe:db94:f1b4:acf5) joined #osdev
16:50:54 <Belxjander> Fujitsu Lifebook PH50/E (Japan exclusively sold)
16:50:58 <epony> Also another idea is to install from pre-compiled packages..
16:51:20 <Belxjander> with AMD64 Dual-Core E-450 processor (includes Radeon r600 graphics core )
16:51:45 <Belxjander> 2GB of physical memory (swap memory support is enabled but non-functional producing an error at "swapon")
16:52:10 <epony> I don't really know what are the requirements to compile the entire chain of dependencies you have, but most probably it is getting something trivial blocking the installation / compilation.
16:52:24 <Belxjander> epony: I don't want to be trapped with dependency hell from deb/rpm packaging
16:52:46 <epony> Most probably 2GB of RAM will not be enough, and maybe a package / lib is missing.
16:52:55 --- join: Pseudonym73 (~Pseudonym@e-nat-unimelb-128-250-0-57.uniaccess.unimelb.edu.au) joined #osdev
16:53:27 <Belxjander> which generally force me o accept packages that I don't weant as "you really need this" for optional things along with breaking packages into seperate compiled parts which makes actually having a "complete install" a goddammed mess of packaging crap
16:53:28 <epony> I would just install the packages from the OS repo.
16:53:44 <Belxjander> using gentoo...
16:53:51 <Belxjander> the repo is source tarballs
16:53:56 --- quit: chao-tic (Ping timeout: 260 seconds)
16:54:36 <Belxjander> I have found replacement memory (hell I can afford to pump the machine up to 16GB installed using supported memory)
16:54:37 <epony> There you go, so as the raven in the pilot seat asked the other animals in the pilot cabin "can you fly if this thing breaks? no? then why are you touching the controls?"
16:54:55 <Belxjander> the only limitation is I only have bitcoin for the forseeable future with which to buy anything :|
16:55:21 <epony> you better buy a ram stick than feed your money to GOOG / AMZN.
16:55:33 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
16:55:38 <variable> you know, maybe if you modified the compiler flags on the compiler, it'd be fast enough to compile plasma
16:55:52 <Belxjander> I only use the free teir with AWS/GC2 anyway
16:55:54 <variable> like recompile the compiler with -ffast-math (which should be default)
16:56:07 <epony> That CPU is probably a bit on the edge of usability for KDE though.
16:56:14 <variable> and then use the clang-with-fast-math to compile KDE
16:56:27 <epony> Belxjander Maybe compile on the desktop and move your packages to the laptop..
16:56:32 <variable> though that may be too pedestrian for the gentoo fans
16:56:37 <Belxjander> variable LLVM 6.0.1 is one of the packages that it locks up on due to memory limits
16:56:47 <epony> :-D
16:57:20 <variable> Belxjander: fwiw using the free tier on AWS is not likely going to give you good speeds for compilation
16:57:28 <Belxjander> unless I can get a matching compiler setup on a raspberry pi and push compilation off to that...(HA! it's a whole lot of crawling to workaround crazy brokenness)
16:57:30 <epony> Another idea, maybe ask in #gentoo and #KDE too, just in case there is something obvious you're missing in plain sight.
16:57:42 <Belxjander> epony: been there and done that
16:57:58 <variable> we're in #osdev
16:58:10 <variable> so clearly the right solution is to modify the VFS layer
16:58:11 <epony> Belxjander The RPI is a different arch, you can't use same binaries as the x86.
16:58:18 <variable> and the VM layer of your computer
16:58:24 <variable> so that it takes less RAM to compile
16:58:30 <variable> epony: cross-compile!
16:58:42 <Belxjander> ran into crap asumptions (they generally assume a desktop not a laptop for a start...and I had to repeat myself "laptop..." to most suggestions which went on about reseating hardware...)
16:58:54 * variable continues to be helpful
16:59:06 <epony> Cross compile on a RPI what a e450 can't cope with? forget it
17:00:10 <Belxjander> I actually want the laptop so I can run a cross-compiler for targetting a specific PPC toolchain (something I already have sources for...just need to build them) along with RPi cross-compilation of AROS to play with driver coding there
17:00:30 --- quit: atk (Quit: Well this is unexpected.)
17:00:42 --- join: atk (~Arch-TK@ircpuzzles/staff/Arch-TK) joined #osdev
17:00:47 <epony> It is an 18W reasonably performing dual core CPU of the 40nm process..
17:00:58 <variable> well there's the problem!
17:01:09 <variable> 40nm is too small to store all the data
17:01:14 <variable> try getting a 60nm ram
17:01:26 <epony> No, try using GCC.
17:01:46 * Belxjander wonders where variable is and whether variable actually wants a stick (or two) applied with excessive force to break things....
17:02:20 <epony> Belxjander It is recommended you compile the larger packages on a desktop indeed, they may have been right in their assumptions, you know..
17:03:25 <variable> Belxjander: you're a gentoo user - that practically means you're /expecting/ this
17:04:57 --- quit: adam4813 (Quit: Connection closed for inactivity)
17:07:02 <pounce> Is there any reason why there are two writes to the line control register in https://wiki.osdev.org/Serial_Ports#Example_Code (0x80 and 0x03)? Can't I just do them in one write
17:07:04 <bslsk05> ​wiki.osdev.org: Serial Ports - OSDev Wiki
17:08:17 <variable> pounce: read the parahgraph
17:08:23 <variable> "Notice that the initialization code above writes to [PORT + 1] twice with different values. "
17:08:47 <pounce> so it does @w@
17:08:58 <epony> Belxjander you're making a couple of wrong choices
17:09:27 * variable makes wrong choices all the itme
17:09:37 * variable mostly exists /to/ make wrong choices
17:09:49 * variable out
17:10:22 --- quit: variable (Quit: Found 1 in /dev/zero)
17:11:00 <epony> variable I'm glad it's working out well for you so far.
17:11:22 <epony> The reality however is, wrong choices - unsolved tasks.
17:21:16 --- quit: ALowther ()
17:28:05 --- quit: _rubik (Quit: *Yawwwn*)
17:28:55 --- join: promach2 (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
17:32:10 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
17:38:27 --- quit: pounce (Ping timeout: 240 seconds)
17:48:07 --- quit: spare (Quit: leaving)
17:49:40 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
18:00:45 --- quit: Pseudonym73 (Remote host closed the connection)
18:01:19 --- quit: godel (Ping timeout: 240 seconds)
18:02:24 --- join: Pseudonym73 (~Pseudonym@e-nat-unimelb-128-250-0-57.uniaccess.unimelb.edu.au) joined #osdev
18:05:08 --- quit: freakazoid0223 (Ping timeout: 276 seconds)
18:17:45 --- quit: ACE_Recliner (Remote host closed the connection)
18:22:36 --- quit: MarchHare (Ping timeout: 260 seconds)
18:28:49 --- quit: chao-tic (Ping timeout: 240 seconds)
18:30:47 --- join: freakazoid0223 (~IceChat9@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
18:31:42 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
18:35:04 --- join: SGautam (~GautamS@unaffiliated/gautams) joined #osdev
18:36:15 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:38:53 --- join: quc (~quc@87.116.228.164) joined #osdev
18:39:00 --- join: dengke (~dengke@106.120.101.38) joined #osdev
18:43:13 --- quit: promach2 (Ping timeout: 240 seconds)
18:46:28 --- quit: ALowther (Remote host closed the connection)
18:50:03 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
18:59:12 --- join: MarchHare (~Starwulf@mo-184-5-204-232.dhcp.embarqhsd.net) joined #osdev
19:01:31 --- quit: ALowther (Remote host closed the connection)
19:03:22 --- join: josuedhg_ (~josuedhg_@192.55.54.42) joined #osdev
19:04:36 --- quit: josuedhg (Ping timeout: 260 seconds)
19:17:15 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:24:03 --- quit: BreakingFree (Remote host closed the connection)
19:25:54 --- quit: Pseudonym73 (Remote host closed the connection)
19:28:01 --- join: BreakingFree (~libre@199.254.238.212) joined #osdev
19:28:31 --- quit: awang (Ping timeout: 260 seconds)
19:36:07 --- quit: Celelibi (Ping timeout: 264 seconds)
19:37:25 --- join: hmmmmm (~sdfgsf@pool-72-79-167-102.sctnpa.east.verizon.net) joined #osdev
19:40:11 --- quit: hmmmm (Ping timeout: 260 seconds)
19:43:49 --- quit: JusticeEX (Ping timeout: 240 seconds)
19:49:39 --- join: Pseudonym73 (~Pseudonym@e-nat-unimelb-128-250-0-57.uniaccess.unimelb.edu.au) joined #osdev
19:52:19 --- quit: mpt- ()
19:54:40 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
19:55:07 --- quit: Arcaelyx (Read error: Connection reset by peer)
19:56:13 --- quit: BreakingFree (Ping timeout: 255 seconds)
19:58:57 --- quit: awang (Ping timeout: 240 seconds)
20:07:55 --- join: Arcaelyx (~Arcaelyx@2604:2000:f14a:2500:44df:ad7f:de2f:8c04) joined #osdev
20:12:24 --- quit: Arcaelyx (Read error: Connection reset by peer)
20:12:29 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
20:12:47 --- join: godel (~gonzalo@190.192.95.122) joined #osdev
20:13:19 --- quit: nj0rd (Ping timeout: 240 seconds)
20:14:33 --- join: Arcaelyx (~Arcaelyx@cpe-184-152-29-2.nyc.res.rr.com) joined #osdev
20:16:55 --- quit: ALowther (Ping timeout: 264 seconds)
20:18:56 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
20:26:51 --- quit: Arcaelyx (Read error: Connection reset by peer)
20:26:52 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
20:27:07 --- join: Arcaelyx_ (~Arcaelyx@2604:2000:f14a:2500:1963:ed33:3d5b:68cc) joined #osdev
20:28:14 --- join: nj0rd (~nj0rd@i577BC090.versanet.de) joined #osdev
20:45:07 --- join: NaNkeen (~nankeen@122.0.31.67) joined #osdev
20:45:34 --- join: NaNkeen_ (~nankeen@203.188.234.181) joined #osdev
20:45:41 --- quit: NaNkeen (Client Quit)
20:45:41 --- quit: NaNkeen_ (Client Quit)
21:00:41 --- quit: awang (Ping timeout: 260 seconds)
21:10:55 --- quit: chao-tic (Ping timeout: 256 seconds)
21:13:44 --- join: ACE_Recliner (~ACE_Recli@c-73-18-225-48.hsd1.mi.comcast.net) joined #osdev
21:17:38 --- quit: air (Quit: cria 0.2.9cvs17 -- http://cria.sf.net)
21:18:06 --- join: air (~brand@c-73-20-100-123.hsd1.ut.comcast.net) joined #osdev
21:22:07 --- quit: BreakingFree (Remote host closed the connection)
21:23:34 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
21:27:22 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
21:35:50 --- quit: chao-tic (Quit: WeeChat 1.0.1)
21:43:42 --- quit: freakazoid0223 (Quit: Wink, Wink, nudge, nudge. Know what I mean?)
21:46:07 <SGautam> https://www.qubes-os.org/video-tours/ huh
21:46:07 <bslsk05> ​www.qubes-os.org: Video Tours of Qubes OS | Qubes OS
21:46:34 <SGautam> so they basically came up with the idea of ultimate security and decided to virtualize the entire userspace
21:47:01 <SGautam> (as in every app is compartmentalized)
21:47:38 <bcos> So, they reinvented processes from the 1950s?
21:47:47 <drakonis> nope
21:47:50 <drakonis> they're still running linux
21:48:16 <drakonis> basically crazy sec people
21:49:11 <bcos> Ah, they reinvented processes from the 1950s (just replacing one kind of hardware isolation with a more expensive kind), and then broke all the "global resource sharing" the kernel does by turning Linux into an exokernel layer?
21:49:37 <drakonis> they're running linux inside xen
21:49:50 <drakonis> so, yes
21:49:54 <SGautam> this is satire
21:49:55 <drakonis> yes its an exokernel
21:50:01 <drakonis> its not satire sadly
21:50:10 <drakonis> its a real thing
21:50:31 <SGautam> now i'm thinking they have a VPN for every app
21:50:39 <SGautam> that would actually be cool
21:55:10 --- join: sixand (~Thunderbi@175.44.160.12) joined #osdev
21:55:11 --- quit: BreakingFree (Remote host closed the connection)
21:55:17 <SGautam> okay so instead of processes they have full blown VMs
21:55:30 <SGautam> an interesting thing is they have the kernel running inside a VM?
21:55:48 <SGautam> ah right, it's running inside Xen
21:56:45 <drakonis> yes
21:56:53 <drakonis> so they run multiple VMs with different distros
21:57:07 <drakonis> linux is the dom0 and there's VMs with distros in each
21:57:14 <SGautam> you know, i'm tempted to say it sounds magical
21:57:16 <drakonis> its kinda baffling
21:57:20 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
21:57:36 <bcos> xen = "Linux + hardware virtualisation + overhead to make Linux IO emulate device interfaces". Then on top of that they put Linux inside the guests (inside each app) plus more overhead (device drivers) to make "Linux IO/APIs" back into a form the emulated devices want.
21:57:58 <drakonis> yes
21:58:02 <drakonis> its terrible
21:58:17 --- join: xenos1984 (~xenos1984@2001:bb8:2002:200:6651:6ff:fe53:a120) joined #osdev
21:58:32 <bcos> And then break all the resource control - e.g. if one app has high priority tasks and another app has low priority tasks, then Xen doesn't know about the priorities and ...
21:58:57 <bcos> (and similar for IO priorities, etc)
21:59:26 <bcos> (and probably similar problems for memory management - one app swapping like crazy while another has unused RAM)
21:59:40 <SGautam> it looks smooth
21:59:51 <SGautam> maybe the guy is running it on i7 6700K
21:59:54 <bcos> If they fixed all of the problems and bloat; it'd probably be as good as "normal Linux"
22:00:01 <bcos> :-)
22:02:02 <bcos> Of course you can bet it's still susceptible to all the hardware vulnerabilities (spectre, meltdown, rowhammer, ...); and if there's a security vulnerability in Linux then having twice as many Linux kernel's won't help that, so...
22:04:24 --- quit: AverageJ0e (Quit: Leaving)
22:04:28 <drakonis> it also burns up ram
22:04:31 <drakonis> per vm
22:04:41 <drakonis> they recommend 16GB+
22:04:44 <Mutabah> Damn
22:05:08 <drakonis> actually 4, but if you run a lot of VMs 16GB is best
22:06:02 --- join: Lowl3v3l (~Lowl3v3l@141.35.23.133) joined #osdev
22:06:37 --- quit: Arcaelyx_ (Quit: Textual IRC Client: www.textualapp.com)
22:10:08 <SGautam> well we aren't far from that in the gaming industry
22:10:15 <SGautam> 8GB RAM is soon going to be minimum
22:10:23 <SGautam> 12GB would be recommended
22:11:12 <Ameisen> turns out if you build GCC to statically link to its libraries... it builds the LTO plugin as a static lib
22:12:41 <drakonis> 8GB is the minimum already
22:12:44 <drakonis> the next step is 16GB
22:13:30 <drakonis> the xbonex has 12gb
22:13:40 <drakonis> 9 allocated to games
22:14:01 <drakonis> why the hell does it need so much ram anyways, what the hell do they stick there anyways
22:14:08 <Mutabah> textures?
22:14:14 <Mutabah> collision geometry?
22:14:18 <Mutabah> entities
22:14:19 <drakonis> what no
22:14:21 <drakonis> the system ram
22:14:23 <drakonis> it needs 3gb
22:14:28 <Mutabah> Oh
22:14:38 <drakonis> i assume it is windows OS jankiness
22:15:07 --- quit: bauen1 (Remote host closed the connection)
22:15:23 --- join: Celelibi (celelibi@par69-9-88-166-81-29.fbx.proxad.net) joined #osdev
22:16:05 --- quit: BreakingFree (Remote host closed the connection)
22:16:45 <SGautam> 'xbonex'
22:16:54 <SGautam> what the fuck lmao
22:16:59 <SGautam> 'bonex'
22:17:30 <drakonis> yes lmao
22:17:33 <SGautam> someone needs to tell microsoft how to brand their stuff
22:17:48 <SGautam> i just learned their JIT compiler for Edge is called chakra
22:17:58 <drakonis> i have been calling it xbone since release
22:18:04 <drakonis> have you xboned today?
22:18:10 <SGautam> which makes sense cause chakra is a wheel just like the cursor wheel that keeps spinning while you fire up edge
22:18:23 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
22:20:57 --- quit: Celelibi (Ping timeout: 240 seconds)
22:21:27 <drakonis> https://i.imgur.com/f0TO2TS.gifv
22:21:27 <bslsk05> ​i.imgur.com: Cat massage
22:22:47 --- join: andrei-n (~andrei@51.214-65-87.adsl-dyn.isp.belgacom.be) joined #osdev
22:23:52 <SGautam> [QUICK SNEEK PEEK: Watch how man tries to revive Windows Phone user after phone update takes too long]
22:23:53 --- quit: BreakingFree (Remote host closed the connection)
22:26:30 --- quit: dbittman (Ping timeout: 255 seconds)
22:29:01 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
22:29:52 --- join: MaryJaneInChain (~user@223.255.127.32) joined #osdev
22:40:00 --- quit: `Guest00000 (Ping timeout: 276 seconds)
22:47:09 --- quit: Beato (Quit: Bye!)
22:51:21 --- join: `Guest00000 (~user@37.113.172.28) joined #osdev
22:53:07 --- quit: jakogut (Quit: jakogut)
22:53:29 <jjuran> The memory consumption increases xbonextially
22:56:30 --- join: NaNkeen (~nankeen@122.0.31.67) joined #osdev
22:59:50 --- quit: NaNkeen (Client Quit)
23:00:03 --- quit: BreakingFree (Remote host closed the connection)
23:00:04 --- join: NaNkeen (~nankeen@203.188.234.181) joined #osdev
23:00:29 --- quit: NaNkeen (Client Quit)
23:01:18 --- join: NaNkeen (~nankeen@203.188.234.181) joined #osdev
23:02:11 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
23:02:23 --- join: awang (~awang@cpe-98-31-27-190.columbus.res.rr.com) joined #osdev
23:02:33 --- quit: BreakingFree (Remote host closed the connection)
23:03:13 --- join: ALowther (~alowther@68.200.236.134) joined #osdev
23:04:45 --- join: BreakingFree (~libre@kite.riseup.net) joined #osdev
23:07:13 --- quit: BreakingFree (Read error: Connection reset by peer)
23:07:51 --- quit: ALowther (Ping timeout: 260 seconds)
23:17:13 --- quit: sdk93 (Quit: Connection closed for inactivity)
23:20:54 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:23:01 --- join: Celelibi (celelibi@par69-9-88-166-81-29.fbx.proxad.net) joined #osdev
23:24:18 --- join: daniele_athome (~daniele_a@5.170.128.175) joined #osdev
23:27:03 --- join: immibis (~chatzilla@222-155-160-32-fibre.bb.spark.co.nz) joined #osdev
23:30:49 --- quit: awang (Ping timeout: 240 seconds)
23:37:40 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
23:41:27 --- quit: NaNkeen (Ping timeout: 240 seconds)
23:43:01 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
23:45:14 --- quit: drakonis (Remote host closed the connection)
23:48:06 --- quit: godel (Ping timeout: 260 seconds)
23:52:46 --- quit: `Guest00000 (Ping timeout: 260 seconds)
23:53:05 --- join: NaNkeen (~nankeen@122.0.31.67) joined #osdev
23:53:09 --- join: Humble (~hchiramm@2405:204:5700:90f6:982b:b68c:a68e:42c2) joined #osdev
23:56:24 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
23:59:05 --- quit: SGautam (Quit: Leaving)
23:59:59 --- log: ended osdev/18.05.06