Search logs:

channel logs for 2004 - 2010 are archived at ·· 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

Wednesday, 1 June 2022

05:54:00 <Clockface> if a language can compile the language that it its compiler is written in, is it self hosting?
05:54:00 <klys> yeah as long as it's turing complete
06:09:00 <klange> That is generally the definition of self-hosting for languages.
07:52:00 <Andrew> Or lambda calculus-complete :D
08:24:00 <Andrew>
08:24:00 <bslsk05> ​ Multiboot - OSDev Wiki
08:24:00 <Andrew> 403
08:25:00 <Andrew> from my laptop
08:25:00 <Andrew> but using my server, it's 200
08:25:00 <Andrew> Ah, it's because of my user agent
08:25:00 <Andrew> I provided "Andrew's Browser" as my user agent
08:25:00 <Andrew> Please fix
08:49:00 <sortie> curl --verbose --head -s -H "User-Agent: Andrew's Browser" ← Can't reproduce
09:08:00 <klange> Andrew: Are you sending the correct line endings for an HTTP request?
09:52:00 <stephe> if i have a GDT with 3 descriptors, it should have size 24 bytes right? but then you put 23 in the gdt descriptor size field, is that correct?
09:53:00 <Mutabah> Yes.
09:53:00 <Mutabah> The field name is "limit", which is size minus 1
09:58:00 <stephe> that's what i thought, i see a lot of examples where its being set to 24 though, which is weird
10:00:00 <klange> gdt can have an extra byte, as a treat [do not do this]
10:00:00 <mrvn> it's stupid that the gdt size isn't in multiple of slots.
10:02:00 <Andrew> That's ... weird
10:02:00 <Andrew> Whatever, it's not too important to me
10:04:00 <Andrew> ./b 25
10:06:00 <Mutabah> Eh, I'd assume it's using similar logic/circuitry to the segments themselves, which have a limit instead of size so they can have a size that includes the largest address
10:09:00 <mrvn> otherwise the largest GDT would have size 0 and they would have to syntesize the overflow 1 bit internally.
10:10:00 <mrvn> Saves 1 bit in the opcode. But using the number of slots would have saved 2 more.
10:10:00 <mrvn> s/opcode/descriptor.
11:03:00 <stephe> so if im understanding this right, i long jump to 0x8:protected_mode to set cs to 0x8 so the code uses the code descriptor, and then the other registers, ds, es, fs, ss, etc should be set to 0x10 so they use the data descriptor?
11:05:00 <\Test_User> as long as your second entry in the gdt is for code and the 3rd is for data, yes
11:07:00 <stephe> yea that's right... right now i have both descriptors set up with base 0 and limit 0xffff, is it possible to just have 1 descriptor and use it for both the code and data? since they are both overlapping i dont see the point really?
11:08:00 <stephe> i guess if they were separate areas of memory then you wouldnt want the data to be executable
11:11:00 <\Test_User> you cannot, they are two different types, for the code descriptor one specific flag is if it's readable, for data that same flag means if it is writable
11:11:00 <stephe> ahh
11:13:00 <\Test_User> also you may want to ensure you're using the full limit, there's a 2nd section of the limit (4 bits) for it in the gdt, along with a flag for granularity (in units of 1 byte if not set, 4k if set)
11:19:00 <stephe> ahh
11:50:00 <stephe> how does the size flag work, apparently you can have a 16 bit segment and a 32 bit segment, what would that be used for?
11:57:00 <Mutabah> iirc it changes the default address size for accesses
12:01:00 <stephe> hmmm
12:20:00 <mrvn> use 64bit mode, base and limit are ignored
12:21:00 <mrvn> in 64bit mode you still might want a 32bit CS/DS but 16bit is certainly dead.
12:21:00 <\Test_User> in 64-bit you also need to setup paging
12:21:00 <mrvn> you want a kernel without virtual memory?
12:23:00 <\Test_User> definitely doable, and probably simpler to start with and setup later
12:33:00 <mrvn> it's easy to set up a identity mapping if you really want no virtual memory
12:35:00 <Andrew> I personally feel like not having virtual memory so that programs could just pass things around (IPC-wise) as pointers
12:35:00 <Andrew> Though, memory protection would be *a bit* harder[tm]
12:36:00 <mrvn> Andrew: you can have a global address space and still have virtual memory.
12:36:00 <\Test_User> can't you use the gdt to protect ram... until you go to 64-bit mode where it becomes obsolete
12:36:00 <mrvn> and you definetly want 64bit for that. 32bit / 2GB gets kind of crowded if all programs share it.
12:36:00 <Andrew> mrvn: Having virtual memory already makes things more complicated, and I want better system integration, meh
12:37:00 <\Test_User> but also yes, you *can* have the kernel intervene and interpret the pointers through vertual memory
12:37:00 <\Test_User> mrvn: you've got 4GB in 32-bit mode, not 2GB
12:37:00 <Andrew> x86 sucks - Going to MMIX *sometime*
12:37:00 <mrvn> \Test_User: you can if you give every process it's own GDT/LDT entry.
12:37:00 <\Test_User> ye
12:37:00 <mrvn> \Test_User: not if you split between kernel space and user space
12:38:00 <\Test_User> why do you need to divide it in half to split it though
12:38:00 <mrvn> no reason
12:38:00 <\Test_User> surely you can split it at e.g. 3GB userspace and 1GB kernel
12:38:00 <mrvn> if you don't do virtual memory you wouldn't split.
12:41:00 <zid> You can, and linux does
12:51:00 <zid> and by does I mean, did, 30 years ago
12:51:00 <zid> when 32bit was relevent
12:52:00 <Andrew> I have 32-bit machines
12:52:00 <mrvn> recycle
12:52:00 <Andrew> I like them
12:52:00 <Andrew> And use them
12:52:00 <mrvn> update and save power and money
12:53:00 <Andrew> mrvn: Works fast enough for all my purposes, doesn't use much power either
12:53:00 <Andrew> Also most modern computers have nonfree stuff
12:53:00 <Andrew> And are harder to libre/os-boot
12:54:00 <zid> all computers from every era are non-free to begin with
12:55:00 <Andrew> Indeed, but the older ones are better
12:55:00 <Andrew> For example, no management engine or platform processor at all
12:55:00 <zid> less features is less features, not more free
12:56:00 <Andrew> Yes I know AMD exists, but still my current 32-bit machine totally works for me
12:56:00 <zid> I like wake on lan, kvm switching, etc
12:56:00 <zid> I've *never* controlled the firmware on my PC, ever, in any era, and neither has anybody else
12:56:00 <zid> that you happen to *know* the name of the firmware image now changes nothing
12:57:00 <Andrew> zid: You can control *more* of it
12:57:00 <Andrew> Have you looked at
12:57:00 <bslsk05> ​ Libreboot – Free your BIOS today!
12:57:00 <mrvn> Andrew: a little RPi would save power and be faster
12:57:00 <zid> You mean less of it, because there is less of it to control :P
12:57:00 <mrvn> Andrew: plus open firmware by clever
12:57:00 <Andrew> mrvn: Also requires nonfree firmware in the OS to get any sanity in graphics rendering
12:57:00 <psykose> save power except for all the power spent in manufacturing it in the first place :p
12:57:00 <Andrew> Open firmware, would check out
12:58:00 <Andrew> zid: A bigger proportion of the firmware
12:58:00 <zid> because it does less
12:58:00 <zid> I keep saying this and you keep saying that
12:58:00 <Andrew> zid: What exactly does 32-bit or coreboot miss?
12:58:00 <zid> The *reason* ME exists is because my board just.. does more shit
12:58:00 <Andrew> (libreboot exists for 64-bit, I know, just I don't need to switch now for that computer)
12:58:00 <zid> I can ssh into my mobo, that capability comes from somewhere
12:59:00 <\Test_User> I'd much prefer without intel's ME attached to my CPU
12:59:00 <gog`> got my new lappy woooo
12:59:00 <zid> nice, does it bell and whistle?
12:59:00 <j`ey> gog: finally!
12:59:00 <gog> it does
12:59:00 <Andrew> Though, what I wrote on would be nice
12:59:00 <bslsk05> ​ Front Page - Free Computing Movement - Working together for free computing
12:59:00 <zid> run ALL the benchmarks
12:59:00 <gog> can't really play with it today though, i gotta work in an hour :(
12:59:00 <Andrew> zid: What does ME do that you couldn't do with a ThinkPad x60/x200 otherwise?
13:00:00 <\Test_User> "it offers the NSA a nice backdoor"
13:00:00 <zid> Andrew: I'm not aware of what your thinkpad is lacking, can you ssh into the mobo and set the bios settings?
13:00:00 <\Test_User> why would you want ssh available for your bios config
13:00:00 <Andrew> Wha mobo?
13:00:00 <Andrew> *what
13:00:00 <zid> anything with ME
13:00:00 <Andrew> And I could do that I
13:01:00 <zid> that's one of the things it provides, a management interface
13:01:00 <Andrew> if I want to with linuxboot
13:01:00 <zid> You know, with it being.. a management engine
13:01:00 <zid> It's the thing wot powers the mobo
13:01:00 <Andrew> To manage seabios and/or payloaded grub
13:01:00 <Andrew> zid: Look up: libreboot, seabios, linuxboot
13:01:00 <\Test_User> zid: when was the last time you needed to manage your laptop's bios config with ssh
13:01:00 <zid> That wasn't the question
13:01:00 <Andrew> All of these are free software allowing for even more flexibility
13:02:00 <Andrew> Than what ME could provide
13:02:00 <\Test_User> but the ME is required on *every* intel CPU built nowadays
13:02:00 <zid> He said "what stuff can my laptop not do", when I said ME adds features
13:02:00 <Andrew> AND it's free software
13:02:00 <\Test_User> true
13:02:00 <Andrew> zid: I can *easily* implement that in linuxboot
13:02:00 <zid> go for it, no you can't
13:02:00 <zid> You need the ME
13:03:00 <\Test_User> you may want to look at libreboot before saying he can't
13:03:00 <zid> It's physically impossible not to use the ME
13:03:00 <\Test_User> may require the system to be running, sure
13:04:00 <Andrew> zid: I currently don't have a BIOS, but sure, I could change it
13:05:00 <zid> Nobody asked you to change anything, you were asked to ssh into your motherboard
13:06:00 <Andrew> zid: I am implementing this SSHing thing because it's not built in as the developers didn't see a need for it; I'm demonstrating that implementing and using this (and more features) is possible with (partially) free firmware with free BIOS
13:07:00 <zid> Great, but you can't, it's not physically possible.
13:07:00 <\Test_User> Andrew: "if it isn't running then you can't"
13:07:00 <Andrew> zid: You bet :)
13:07:00 <Andrew> Do you know what Libreboot it?
13:07:00 <Andrew> *is?
13:07:00 <mrvn> zid: I can ssh into my ARM
13:07:00 <zid> You'd need some kind of processor to run it on
13:07:00 <zid> some kind of.. management processor
13:08:00 <\Test_User> not saying it's smth you want, just saying you can't do it without this
13:08:00 <Andrew> zid: I have a CPU
13:08:00 <zid> That's not what was asked.
13:08:00 <\Test_User> Andrew: it needs to be running
13:08:00 <zid> I didn't say install linux
13:08:00 <zid> and ssh into your computer
13:08:00 <zid> I said ssh into your *motherboard*
13:09:00 <Andrew> zid: Linux *is* my firmware/BIOS, similar to how Minix is used in Intel ME
13:09:00 <mrvn> zid: upgrade your "motherboard" to fix the security bugs
13:09:00 <zid> It is not firmware.
13:10:00 <Andrew> Then what do you call the software running in the ME?
13:10:00 <mrvn> don't kid yourself. ssh isn't done in hardware
13:10:00 <zid> Firmware, you said you don't want ME and can do everything without it.
13:11:00 <Andrew> <zid> It is not firmware.
13:11:00 <zid> so either you've sneakily decided to use the ME purposefully to try win an argument that only you care about
13:11:00 <Andrew> What's "It"?
13:11:00 <zid> or no, that's exactly what you're doing
13:11:00 <zid> you just refuse to admit that the ME does *anything*
13:11:00 <\Test_User> what's the big difference between running ME with it and leaving your main CPU on a low power state for everything
13:11:00 <Andrew> I admit that ME does things :)
13:11:00 <Andrew> I just say that free things can do it, and allow for better flexibility and freedom
13:11:00 <zid> \Test_User: tbh, I 've reflashed my mobo like 10 times without the cpu even installed, super glad I could do that
13:12:00 <Andrew> Why avoid the CPU?
13:12:00 <\Test_User> zid: the ME is a CPU
13:12:00 <psykose> i would have simply installed a cpu
13:12:00 <zid> you mean, buy a second, older gen cpu
13:12:00 <zid> so that you can run DOS, to run the flasher util
13:12:00 <\Test_User> unless you can run your motherboard on the ME, it's kinda pointless to do things without a CPU attached
13:12:00 <zid> or I could just put a usb stick into my mobo and press a button on it
13:12:00 <zid> and the ME will walk the fs, look for bios images, and update it
13:13:00 <Andrew> zid: And you don't need to use DOS of tht stuff if you use Linuxboot or Libreboot or osboot or coreboot :)
13:13:00 <mrvn> zid: I rather just copy the file to the SD card
13:13:00 <zid> Andrew: on what cpu?
13:13:00 <zid> The one we just discussed *is not in the same room*?
13:13:00 <Andrew> And I have Linux, which is GPLv2 free software that does it, rather than something I am incapable and cannot legally view; Here we'r comparing your preferred situation and my preferred situation I suppos?
13:13:00 <Andrew> s/./e?/
13:14:00 <Andrew> s/\./.$/
13:14:00 <psykose> i think you misunderstood his point
13:14:00 <zid> Yes, that's precisely what's happening, I spent the last 30 minutes arguing closed software is worse. It 100% wasn't you arguing that ME does nothing.
13:14:00 <zid> err better*
13:15:00 <Andrew> You're arguing that closed software is better?
13:15:00 <zid> Clearly, it's easier to just agree with you
13:15:00 <mrvn> software is never closed. Someone will crack it open quickly.
13:15:00 <Andrew> In and of itself of the closed nature or because you think the ME can do important things that I wouldn't be able to?
13:15:00 <zid> Having a use-case that you don't is not tolerated
13:15:00 <mrvn> back box security is a joke.
13:15:00 <Andrew> mrvn: Totally legal
13:16:00 <Andrew> mrvn: Agreed with that
13:16:00 <mrvn> Andrew: hackers don't care about legal
13:16:00 <Andrew> zid: "that you don't" not sure what that means
13:16:00 <Andrew> mrvn: Users care, and using Libreboot you get the features having it still legal
13:17:00 <psykose> the usecase in this specific instance is he bought a motherboard and cpu that were not compatible at the current motherboard bios revision
13:17:00 <psykose> but the motherboard has a feature to update itself.. powered by the me
13:17:00 <Andrew> Ohh I get it now
13:17:00 <psykose> without it, the new cpu wouldn't work at all, you would need an old cpu to update to new bios first
13:18:00 <psykose> it's a thing on a bunch of the am4 amd boards because you need the new bios to run newer zen cpus, but you don't know what bios revision the boards really ship with
13:18:00 <\Test_User> I mean, the ME is the old CPU used to update to the new BIOS
13:18:00 <psykose> sure, if you want to see it that way
13:18:00 <zid> You're thinking about it very weirdly
13:18:00 <zid> the mobo is just a computer in itself
13:18:00 <zid> This is like the ECU on a car or something
13:18:00 <psykose> indeed so
13:18:00 <zid> the point of the car isn't the ecu, but you're pretty glad you have one
13:19:00 <Andrew> That is indeed one case where the ME would help where lb/ob/cb cannot - it boils down to what you think is more important, free sw/hw or using the thing on the motherboard (that has almost completely nonfre software)
13:19:00 <Andrew> leah, et al are trying to get osboot/libreboot working with more performant CPUs which I'm following
13:19:00 <zid> these anti-ECU people are weird, I like the extra engine management features and wouldn't cripple my car just because honda won't mail me the source
13:20:00 <Andrew> I would feel otherwise, difference in ideology
13:20:00 <mrvn> what does the ME do when you install libreboot?
13:21:00 <zid> Some people pine for the "good ol days" where cars didn't have their own electronics, but it just means you miss out on stuff
13:21:00 <mrvn> when the atom bomb drops so you will you
13:21:00 <Andrew> mrvn: Libreboot uses me-cleaner that disables the ME if it's present
13:21:00 <psykose> i pine for the good old days where the cars didn't exist
13:21:00 <zid> and none of it is 'free' anyway, you couldn't replicate a single part of it without their gigs of proprietary stuff
13:21:00 <zid> at least re computers
13:22:00 <Andrew> LB isn't compatible with boards where Me cannot be disabled, in those cases use osboot which cleans it as mych as possible
13:22:00 <zid> It isn't compatible with boards, is easier to say
13:22:00 <zid> considering they support 3 total boards
13:22:00 <psykose> 3 is pushing it
13:22:00 <Andrew> states my long-term ideals
13:22:00 <bslsk05> ​ Free Hardware Designs - Free Computing Movement - Working together for free computing
13:22:00 <Andrew> and is supporting more
13:22:00 <bslsk05> ​ osboot – osboot project
13:23:00 <zid> and those boards are basically pre-ME
13:23:00 <\Test_User> zid: there is nothing about proprietary that magically cannot be done at all with libre software
13:23:00 <zid> \Test_User: of course not, but reality is real
13:23:00 <zid> so good luck convincing asus and intel to tell you know how to operate an x399 mobo
13:23:00 <mrvn> \Test_User: hide NSA backdoors the russians can use?
13:23:00 <Andrew> zid: Yes, lb ports are pre modern ME
13:24:00 <\Test_User> yes, currently, most hardware is non-free
13:24:00 <Andrew> zid: Not caring about Intel :) I care about libresilicon and sam zeloof's work
13:24:00 <\Test_User> mrvn: lol, didn't mean it like that but yes
13:25:00 <\Test_User> zid: doesn't mean no one other than asus or intel can make motherboards
13:25:00 <zid> okay?
13:25:00 <Andrew> zid: mrvn: May I have permission to copy this conversation' logs to leah?
13:25:00 <zid> Why do you keep saying totally obvious things in a way that looks like you're replying to me having claimed them as true
13:25:00 <zid> No
13:25:00 <Andrew> Ok
13:25:00 <\Test_User> > zid | so good luck convincing asus and intel to tell you know how to operate an x399 mobo
13:26:00 <\Test_User> point is you don't need them to tell you, get a different motherboard or find someone who can make a libre one
13:26:00 <Andrew> zid: Why convince them or get them tell you?
13:26:00 <zid> Okay, great, but again, not responding to what I said at all
13:26:00 <zid> None of this conversation has been about designing and manufacturing motherboards
13:26:00 <Andrew> zid: Explain what you mean by reality is real
13:26:00 <zid> so I've weirdly not responded to any such claims with "no you can't, only intel can m ake mobos"
13:26:00 <Andrew> s/motherboards/libre hardware/?
13:27:00 <zid> so I responded to "zid: there is nothing about proprietary that magically cannot be done at all with libre software" instead, by saying "yes you can, but good luck, because as *you just noted*, it's proprietary"
13:28:00 <zid> Sorry for replying to what was said, not a to a conversation nobody was having
13:28:00 <Andrew> Uh, what do you mean by "reality is real"
13:28:00 <zid> You can claim you could just make a mobo with your own software on it just fine
13:29:00 <zid> but it doesn't let you escape the realities of reality, that mobos are complicated $500 pieces of kit, that you'd have to charge $20000 to recreate in a small volume, and by the time you did you'd be 10 years out of date
13:29:00 <mrvn> i am. geist is. lots of people are
13:29:00 <zid> and is thus, not really a valid "ah yes but"
13:30:00 <zid> it's just goalpost moving
13:30:00 <\Test_User> "10 years out of date", which is why you need to think ahead rather than taking a current one and using that
13:30:00 <Andrew> My point is that I'm optimistic that it could catch up, by some day, too
13:30:00 <zid> think ahead.. to standards that don't exist?
13:30:00 <Andrew> And yes, x86 also sucks
13:30:00 <zid> You're going to route pci-e 7.0 electrically how? That's what mobo designers do.
13:31:00 <Andrew> zid: create standards
13:31:00 <zid> Wow
13:31:00 <Andrew> PCIe, lmao that sucks
13:31:00 <mrvn> making an ARM mainboard is pretty much point and click nowadays and far below $20000
13:31:00 <zid> So your solution to the pcie group moving faster than you can
13:31:00 <zid> is to *compete with them*
13:31:00 <zid> now I know you're either insane or trolling, or both
13:31:00 <Andrew> mrvn: Sorry, ARM is quite nonfree
13:31:00 <zid> bye
13:31:00 <mrvn> Andrew: what part is non-free?
13:32:00 <Andrew> mrvn: Hardware nonfree, as in it doesn't really meet which is my definition
13:33:00 <Andrew> I think "compete with them" is an obvious solution, but it's okay if you think it's insane or if I'm trolling
13:33:00 <\Test_User> compete with them is likely to fail, as everyone is only listening to the "official" standards
13:34:00 <Andrew> \Test_User: s/everyone/most hardware manufacturers/
13:34:00 <zid> "Just replace a trillion dollars in market cap worth of companies"
13:34:00 <Andrew> I mean, competition is the way to break monopolies, really
13:34:00 <mrvn> Andrew: well, you have to buy a license and a millions of dollar chip fabricator.
13:35:00 <\Test_User> buy a *license* to make a motherboard/etc?
13:35:00 <\Test_User> what
13:35:00 <mrvn> no, just for the cpu to put on the MB
13:35:00 <Andrew> mrvn: You're missing out on things like libresilicon and sam zeloof, I still have a ton of homework so i'ma afk for a while, but I don't know what you mean by the license
13:35:00 <Andrew> mrvn: Miswrote, the CPU is also in the field of remaking
13:35:00 <mrvn> Andrew: all you need to make a MB is kicat.
13:35:00 <Andrew> RISC-V iscurrently the most feasible
13:36:00 <Andrew> Though, its instructions still seem a bit dirty technical wise and a practical MMIX speclementation would be nice
13:38:00 <Andrew> zid: Same as how all democratic revolutions did back then; the government (those companies) is (are) powerful (rich), doesn't exactly prevent people from competing and replacing
13:40:00 <Andrew> I will summarize and publish what zig said, removing personal identification, time, etc
13:42:00 <zid> I thought you were about freedom not piracy
13:43:00 <\Test_User> where did piracy come in there
13:43:00 <zid> He asked for permission to publish what I said and I said no
13:43:00 <zid> and he just announced he's doing it anyway
13:44:00 <Andrew> Paraphrasing
13:44:00 <Andrew> Legal in my juristiction
13:44:00 <Andrew> If you want attribution, sure
13:44:00 <\Test_User> ah
13:44:00 <zid> I want editorial control not attribution
13:44:00 <zid> I don't trust you
13:44:00 <zid> especially given you didn't seem to understand anything I said
13:44:00 <zid> and kept aruging against reality
13:45:00 <Andrew> Okay, then no attribution - this distribution is legal under my juristiction anyway
13:45:00 <\Test_User> Andrew: "legal" doesn't always mean "good idea"
13:45:00 <Andrew> \Test_User: I find strong reasons for me to do so
13:46:00 <zid> is it against libre's tos? it was against freenode's
13:46:00 <kingoffrance> it never does. it means letter, not idea/spirit/"Morals" etc.. it may occasionally overlap.
13:46:00 <kingoffrance> :)
13:46:00 <Andrew> kingoffrance: Correct
13:47:00 <kingoffrance> dont cross the streams :) that would be bad
13:47:00 <Andrew> I don't see it contridicting to Libera policy
13:48:00 <mrvn> kingoffrance: now you violated the IP of Ghostbusters.
14:56:00 <_73> Does every single thread in the linux kernel maintain two seperate stacks, one for when the processor runs in user mode and one for running in kernel mode?
14:57:00 <zid> I believe so
14:58:00 <zid>
14:58:00 <bslsk05> ​ 6. Kernel Stacks — The Linux Kernel documentation
14:58:00 <zid> "Like all other architectures, x86_64 has a kernel stack for every active thread."
14:58:00 <zid> and one per IRQ per core apparently
14:58:00 <zid> That'll be the one in the TSS RSP0 presumably
15:02:00 <_73> Ok. I dont understand why every single thread needs a kernel stack though. Why cant the kernel just have one stack that it uses for executing syscalls?
15:03:00 <zid> blocking syscalls, are one reason
15:03:00 <zid> so one thread is stuck in read() or whatever, with a bunch of args on its stack etc, and will eventually wake up and start running again
15:04:00 <zid> another thread is going to struggle to re-use that stack without a lot of accounting details about which bits of the stack are owned and active by which thread
15:05:00 <zid> and if the read()'r wakes up.. it can't push anything else it's going to shit on the other thread's data
15:06:00 <zid> It's fine if nothing ever blocks or pre-empts anything else I think though
15:06:00 <_73> Ahh so in the read() case the kernel tells the disk to read, and while that is happening can execute other syscalls. If there was only one stack it would have to figure out how to save the process state for the read call somewhere so it can be restored when the disk interrupts the kernel to tell its done.
15:06:00 <zid> and that 'save it somewhere' is called.. a per thread regsave area, aka a kernel stack
15:06:00 <zid> :P
15:06:00 <_73> Got it, now I understand.
15:07:00 <zid> your terminology a second ago worries me though
15:07:00 <zid> "can execute other syscalls" makes it sound like you think that there is only one 'the kernel'
15:08:00 <_73> I do view it as one 'the kernel'
15:09:00 <zid> Every thread has its own entirely isolated private kernel mapped into its address space, effectively.
15:09:00 <zid> (or rather, process)
15:09:00 <zid> there isn't a "the" kernel which runs processes
15:10:00 <zid> there are n processes, which are each some ring3 and some ring0 code in a bundle, which switch being being active
15:10:00 <zid> s/being //
15:10:00 <zid> and hopefully the ring0 code doesn't let the ring3 code jump to it in a way that it doesn't want
15:11:00 <_73> zid: Why does every thread need a private kernel instead of every process needing one? Why can't threads in the same process share a kernel?
15:11:00 <zid> they do, I corrected myself sorry
15:11:00 <_73> Oh ok
15:14:00 <zid> I find that a much cleaner way to look at it, than trying to wrap your head around some magic kernel mode
15:15:00 <zid> Your process just has some code mapped into it that expects to run at cpl=0, and there's a special jump instruction to do that, it's still your process running that code
15:15:00 <zid> There's no "the kernel" which is running your process
15:15:00 <_73> what is cpl=0 ?
15:15:00 <zid> ring 0
15:16:00 <_73> I see
15:16:00 <_73> It seems that it would cost a lot of memory for every process to have its own kernel
15:17:00 <zid> it's basically free
15:17:00 <zid> the physical memory is shared thanks to virtual memory
15:17:00 <j`ey> _73: it's just mapped the kernel, it's not a different copy
15:17:00 <zid> and the kernel is a couple of megs, which is a couple of 2MB page table entries
15:17:00 <_73> Ohh of course I forgot to consider VM
15:17:00 <zid> so a pml4 which you have anyway, and an extra pdpt and pde
15:17:00 <zid> so probably 8k to get the kernel .text mapped into a process
15:18:00 <zid> like, bare minimum, I'm sure linux has a whole bootload of complex structures it needs to keep mapped at all times though
15:19:00 <zid> It'd be somehwat interesting to dump a snapshot of a linux process and see what's in it tbh
15:20:00 <_73> How can I do that?
15:20:00 <zid> qemu?
15:21:00 <zid> I want a cool visualization tool for this now
15:21:00 <zid> work on that for me
15:21:00 <GeDaMo> Wouldn't you just keep the whole kernel mapped in all the time?
15:22:00 <zid> yes
15:22:00 <zid> but linux is kinda complex, so presumably it has a bunch of complex mappings, sadly
15:29:00 <_73> Is the FreeBSD kernel as complex?
15:29:00 <zid> mostly
15:29:00 <zid> it still does modern OSy things
15:30:00 <_73> I see. I am reading "The design and implementation of the FreeBSD kernel". It is quite good.
15:30:00 <zid> sounds nice
16:25:00 <heat> linux x86_64 doesn't have "complex" mappings
16:26:00 <heat> the kernel mappings are just a carbon copy of each other in every address space
16:26:00 <heat> page tables included AFAIK
16:26:00 <heat>
16:27:00 <zid> and that isn't complex?
16:27:00 <zid> we subscribe to different newsletters
16:28:00 <heat> define complex here
16:28:00 <zid> more than trivial
16:28:00 <zid> less than impossible
16:28:00 <psykose> define trivial
16:28:00 <\Test_User> > 0000000000000000 | 0 | 00007fffffffffff | 128 TB | user-space virtual memory, different per mm
16:28:00 <\Test_User> so nullptr is mapped to userspace
16:28:00 <heat> no
16:29:00 <heat> theoretically you can map it if you set your personality(2) correctly
16:30:00 <heat> MMAP_PAGE_ZERO maps 0x0 as a read-only zero page (like SVR4)
16:30:00 <\Test_User> interesting
16:30:00 <heat> yes
16:30:00 <heat> it's all weird SVR4 compat code
16:30:00 <heat> wouldn't be surprised if it doesn't work anymore
16:31:00 <heat> anyway, if you break it down, the memory map for x86_64 linux kernels is relatively simple
16:32:00 <\Test_User> agreed
16:32:00 <zid> vmalloc space is lazily synchronized into the different PML4/PML5 pages of
16:32:00 <zid> the processes using the page fault handler, with init_top_pgt as
16:32:00 <zid> reference.
16:32:00 <zid> That probably helps
16:32:00 <heat> how is that complicated?
16:32:00 <zid> how is it trivial
16:33:00 <heat> it's not trivial but it's in the middle of trivial and complex
16:33:00 <zid> truncating is for people who think shifts are rad
16:34:00 <heat> it's a relatively standard solution to lazily sync the top page table
16:34:00 <sbalmos> horribly brain-dense question, scrolling back and reading... say the kernel itself is a few megs, and some space for kernel stack per-thread... is it because the kernel has to map in user-space memory in order to copy back and forth that our VMM layout has the upper 1-2 *gigs* of address space reserved to the kernel?
16:35:00 <heat> sbalmos, yes
16:35:00 <zid> all your device memory also needs to be in the kernel half unless your drivers are in a different address space
16:35:00 <heat> the kernel also needs to allocate memory
16:35:00 <zid> which doesn't help
16:35:00 <heat> having the kernel in its own address space would work but it would be slow
16:36:00 <heat> (would work if you could have a miny kernel that just switched address spaces)
16:36:00 <sbalmos> heat: I'm coming from the starting point of microkernel design, so drivers etc would be in a different address space anyway
16:36:00 <zid> well, make it small and then make it bigger every time it isn't big enough :P
16:36:00 <heat> funnily enough, you can use something like this with PTI
16:36:00 <heat> s/miny/mini/g
16:37:00 <heat> PTI manages to make it fast because it uses ASID/PCID when available, which lets it avoid flushing the TLB every time it does the user <-> kernel transition
16:37:00 <sbalmos> just always bugged me at some visceral WTF level that each process's address space had over half of it reserved to the kernel, potentially many multi-gigs' worth
16:37:00 <heat> it's wayyyyy faster and more practical
16:37:00 <zid> well, feel free to use a bounce I guess
16:37:00 <zid> given spectre and all that it might not be that much slower
16:38:00 <sbalmos> ¯\_(ツ)_/¯
16:38:00 <heat> copy_from_user and copy_to_user will be super slow
16:38:00 <heat> (if you don't reserve the top address space)
16:38:00 <heat> right now it's an optimistic memcpy with a fallback exception handler that lets it -EFAULT
16:39:00 <heat> if you don't reserve the top of the address space, user and kernel addresses can collide, so that goes out the window
16:39:00 <sbalmos> then again I should probably just get over it. Look at the Linux MM layout like you linked. Upper-half is /petabytes/ of address space. So it realistically doesn't matter
16:40:00 <zid> 128TB in practice, but yea
16:40:00 <sbalmos> yeah sorry, was looking at the 5-level section
16:40:00 <heat> realistically, if you're running an address space hungry app in 32-bit, stahp it
16:40:00 <sbalmos> 4-level is 128TB. Still...
16:40:00 <sbalmos> yeah yeah yeah. This is the "shut up and get over it" point
16:40:00 <heat> oh yeah I forgot
16:41:00 <heat> 32-bit apps on top of 64-bit kernels *can* use the top 1GB
16:42:00 <sbalmos> interesting to see how much address space is "unused hole"
16:43:00 <heat> i would assume that the holes are there so the next address space region can be aligned to a PDPT entry address boundary
17:15:00 <clever> heat: what about the specter era exploit mitigation, where you swap the paging tables upon entry to kernel space, could that allow a 32bit userland to use nearly the full 4gig on a 32bit kernel?
17:15:00 <clever> baring just a 1 or 2 page handler to swap over
17:16:00 <mjg_> that's meltdown
17:16:00 <mjg_> and ye, that's what freebsd is doing
17:16:00 <mjg_> and i suspect linux as well
17:16:00 <clever> but would that then allow you to use the upper 1gig in a 32bit kernel?
17:16:00 <zid> yea it was mentioned
17:16:00 <clever> since its not actually mapped
17:16:00 <zid> the problem was copy_from_user etc
17:16:00 <mjg_> yes, that's the "benefit"
17:16:00 <zid> you can't have a huge kernel *and* a huge userspace mapped
17:16:00 <clever> ah, yeah, copy_from_user would need to know if its a kernel addr or a userland upper 1gig addr
17:16:00 <mjg_> albeit it's probably a bad idea to add it
17:17:00 <clever> so you have to be more strict, about copy_from_user only ever being given userland pointers
17:17:00 <zid> you'd need bounce buffers or clever remappings and a copy or whatever
17:17:00 <heat> right, every user <-> kernel access would become a lot slower
17:17:00 <clever> it would need to ensure the userland page is mapped somewhere
17:17:00 <heat> clever would need clever remappings hehehehehehehe
17:17:00 <clever> which you get for free, from a 3g/1gig split
17:17:00 <zid> well if I needed them they'd be zid remappings
17:17:00 <mjg_> it's too risky to think real world 32 bit userspace does not have dependencies of addresses always being below 3G though
17:18:00 <mjg_> i remember real world code breaking on a set up where there was 1G for the user and 3G for the kernel
17:18:00 <heat> mjg_, nah. 64-bit kernels map addresses above 4GB easy
17:18:00 <heat> erm
17:18:00 <clever> at least in the rpi firmware api's, it expects userland pointers to fit within a 32bit int
17:18:00 <heat> above 3GB
17:18:00 <clever> so the limit is 4g, not 3g
17:18:00 <mjg_> heat: oh? and that still works?
17:18:00 <heat> oh god the stockholm syndrome is kicking in again
17:18:00 <heat> mjg_, afaik yeah
17:19:00 <clever> heat: lol
17:19:00 <clever> just giving an example of some limits i know of
17:19:00 <mjg_> solid
17:19:00 <heat> you could've said like
17:19:00 <heat> most older DMA interfaces
17:19:00 <clever> in the past, i have ran into issues just LINKING firefox on a 32bit kernel
17:19:00 <heat> let me guess, LTO?
17:20:00 <clever> heat: but this isnt anything to do with dma, userland pointers are being passed to the firmware as opaque tokens, that just get bounced back to userland in a reply
17:20:00 <heat> the fuck
17:20:00 <clever> so the userland can find its own state and deal with the reply properly
17:20:00 <clever> a lot of api's do similar, like the arg to pthread_create
17:20:00 <clever> in this case, its just bouncing the pointer off a remote core
17:21:00 <clever> mqtt does similar, but expects that token to be treated more like a sequence#
17:22:00 <clever> if the remote core was potentially hostile, it would be far worse, you would be expecting an attacker to not modify a pointer your going to use
17:22:00 <heat> mjg_, <-- pmap of a steam 32-bit process
17:22:00 <clever> but using a pointer instead of a handle+lookuptable, just makes it faster, at the cost of some security
17:23:00 <mjg_> heat: ye, i think i "solved" it: see setarch
17:23:00 <mjg_> heat: -3, --3gb Specifies program should use a maximum of 3GB of address space. Supported on x86. Turns on ADDR_LIMIT_3GB.
17:23:00 <mjg_> heat: with this in place i believe the 4G claim without looking at the dump :)
17:23:00 <heat> wonderful
17:23:00 <heat> quirks on top of quirks
17:24:00 <mjg_> dude
17:24:00 <mjg_> you reminded me of a fuckton of old 32 bit binaries compiled without malloc declaration
17:24:00 <heat> that would still work
17:25:00 <clever> i also remember mmap having a flag to request that the addr be <4gig, even on a 64bit arch
17:25:00 <mjg_> unless the returned addr is high enough
17:25:00 <heat> clever, MAP_32BIT
17:25:00 <clever> yep
17:25:00 <heat> mjg_, but for <4GB addresses I mean
17:25:00 <clever> but its missing from my `man mmap` now
17:26:00 <heat> clever, wait haha it's not actually 32-bit
17:26:00 <heat> see
17:26:00 <bslsk05> ​ mmap(2) - Linux manual page
17:26:00 <mjg_> heat: erm, i meant old code recompiled to 64 bit and crashing due to truncating addresses
17:26:00 <mjg_> heat: sorry :)
17:26:00 <heat> brilliant naming
17:26:00 <heat> mjg_, oh yeah for sure
17:27:00 <clever> heat: ah, close enough, still suits mostly the same purpose
17:27:00 <heat> i've seen plenty of newbs get into trouble with malloc and implicit decls
17:28:00 <heat> or anything and implicit decls, really
17:28:00 <heat> if every argument is an int that will blow up on any pointer
17:29:00 <mjg_> loloprogs crashing like this were the standard ticket in red hat support for years
17:34:00 <heat> C is a crap language
17:34:00 <heat> reject language become monke
17:36:00 <Andrew> How is C a crap language?
17:36:00 <Andrew> I mean, yes it doesn't give you interger overflow detection as you could easily do in assembly or Zig but that's about it
17:39:00 <GeDaMo> Well, there's that whole 'buffer overflow' thing :P
17:39:00 <\Test_User> buffer overflow is purely the programmer's fault
17:39:00 <heat> buffer overflows, memory leaks, this whole implicit declaration footgun pointed at your feet
17:40:00 <heat> \Test_User, right. the language assumes competency. bad assumption
17:40:00 <GeDaMo> Yeah, programmers are idiots :P
17:40:00 <Andrew> GeDaMo: You could get that with any unsafe language that has implicit declarations and a faulty programmer
17:40:00 <Andrew> "faulty programmer" xD
17:40:00 <\Test_User> XD
17:40:00 <psykose> programmers fault indeed. except if we decided that 'faulty programmers' shouldnt write code, we would not have any software
17:40:00 <Andrew> Zig seems to not have implicit declarations
17:40:00 <Andrew> psykose: Of course, lol
17:40:00 <psykose> every piece of software you've ever touched has had a buffer overflow in it somewhere at some point :p
17:41:00 <GeDaMo> Probably still does :|
17:41:00 <Andrew> psykose: I have a simple program under Linux:
17:41:00 <Andrew> global _start
17:41:00 <Andrew> section .text
17:41:00 <psykose> here comes the hello world meme
17:41:00 <Andrew> yup
17:41:00 <Andrew> exactly
17:42:00 <Andrew> and how could you buffer overflow it...
17:42:00 <Andrew> _start:
17:42:00 <Andrew> (it's linux 32-bit so)
17:42:00 <heat> you can stop
17:42:00 <\Test_User> still though, languages that do that automatically are generally more inefficient
17:42:00 <Andrew> \Test_User: You mean languages that check?
17:42:00 <Andrew> Or languages that have explicit declarations?
17:42:00 <\Test_User> Andrew: languages that assume incompetent programmers
17:43:00 <Andrew> Ah
17:43:00 <heat> no
17:43:00 <heat> C++ is not measurably less efficient
17:43:00 <heat> so isn't rust
17:43:00 <\Test_User> C++ is terrible for enough other reason; and I did say "generally"
17:43:00 <heat> it might be a tiny tiny bit. but it's not measurable
17:43:00 <Andrew> s/inefficient/either inefficent or insane/
17:43:00 <heat> ok but it doesn't fail in the basic functions of a fucking language
17:43:00 <GeDaMo> Some inefficiency is preferable to a massive security hole
17:44:00 <Andrew> heat: class
17:44:00 <heat> struct
17:44:00 <j`ey> enum
17:44:00 <Andrew> struct is better
17:44:00 <\Test_User> GeDaMo: that's where it requires a good programmer
17:44:00 <Andrew> C enum is, bruh
17:44:00 <Andrew> GeDaMo: True, but leave those to checkers
17:44:00 <heat> \Test_User, name a good programmer
17:44:00 <Andrew> Well, it is harder to prove-correct/verify an imperative program
17:45:00 * \Test_User lacks names of enough programmers to do that
17:45:00 <Andrew> "Donald Knuth" - nah, still not a good enough programmer
17:45:00 <GeDaMo> Fabrice Bellard
17:45:00 <Andrew> Yeltsa Kcir (jk)
17:45:00 <\Test_User> but so far I have yet to make such a problem with C, so it's not all that hard to ensure you free everything you malloc, check malloc's return value, etc
17:46:00 <GeDaMo> How do you know you haven't made one?
17:46:00 <\Test_User> buffer overflow can be avoided by proper testing
17:46:00 <heat> the fact that immediately after you enable asan/ubsan (and optionally start fuzzing) you discover a crap ton of bugs makes you think that there's no such thing as a "good programmer"
17:46:00 <Andrew> \Test_User: s/testing/verification which is generally hard for imperative programs/
17:47:00 <Andrew> Even when
17:47:00 <\Test_User> ...proper testing and proper thought when writing*
17:47:00 <heat> right
17:47:00 <GeDaMo> "Program testing can be used to show the presence of bugs, but never to show their absence!" -- Dijkstra
17:47:00 <heat> ladies and gentlemen we've fixed security vulnerabilities
17:47:00 <heat> just think
17:47:00 <Andrew> ... * even when you assume that the cpu and compiler works perfectly
17:47:00 <heat> that's the solution
17:47:00 <Andrew> GeDaMo: Verification does, though
17:47:00 <Andrew> Formal proof
17:47:00 <\Test_User> Andrew: and that's why I prefer assembly
17:47:00 <_73> Ive been messing around with ATS which gives you the same control as C/C++ but with total safety due to dependent types. The downside is nobody uses it and its hard to learn.
17:47:00 <bslsk05> ​ ATS-PL-SYS
17:48:00 <Andrew> \Test_User: Still gotta deal with the CPU
17:48:00 <Andrew> Though now you got to deal with Kurt Godel
17:48:00 <\Test_User> yes the CPU isn't my fault though and there's nothing I can do about that
17:48:00 <GeDaMo> "Beware of this code. I have only proved it correct, not tested it." -- Knuth
17:48:00 <Andrew> xD
17:49:00 <Andrew> Be aware of Kurt Godel who will damage your brain with "a consistent system of mathematics with peano arithmetic cannot prove all true statements within utself"
17:49:00 <Andrew> *itself
17:49:00 <Andrew> And "A consistent shstem of mathematics with peano arithmetic cannot prove its own consistency"
17:50:00 <Andrew> And now you can't verify programs properly
17:50:00 <Andrew> Because what if you're dealing with an inconsistent proof system
17:51:00 <\Test_User> then don't use the CPU to prove itself, use your brain and the transistors behind it[tm]
17:51:00 <heat> oh sure because that always works
17:51:00 <\Test_User> yes that was intended as a joke
17:52:00 <\Test_User> anyways, back to it - "if you cannot make bug-free code, neither can the person who made the compiler that tries to make bug-free code for you"
17:52:00 <heat> well you seem to explicitly defend that C is a good language
17:52:00 <\Test_User> there's some things I find lacking in C, but overall yes
17:52:00 <\Test_User> already mentioned by andrew, overflow detection is the main thing I find lacking
17:53:00 <heat> do you not find the complete lack of memory safety lacking?
17:53:00 <\Test_User> though apparently there are patches to get gcc to work with that
17:53:00 <\Test_User> nope, I like to control what my programs do when
17:53:00 <Andrew> heat: Haxuser finds lack of memory safety completely okay
17:53:00 <\Test_User> *personally-made memory safety
17:54:00 <\Test_User> not total lack of
17:54:00 <heat> you don't lose control with memory safety
17:55:00 <Andrew> If it's the compiler checking at compile time, or the assembler doing some extra work without effecting its output I suppose hax is okay with it
17:55:00 <\Test_User> s/hax/Test_User/g, do be sure to use my nick when there is no context of the other to confuse everyone
17:56:00 <Andrew> k
17:56:00 <\Test_User> *to not confuse
17:56:00 * Andrew haxes \Test_User
17:56:00 <\Test_User> but yes sure, if the compiler can check that I didn't leave any memory leaks then I'm fine with that
17:56:00 <Andrew> * or assembler
17:56:00 <Andrew> or nah
17:56:00 <Andrew> probably an external program should do it
17:57:00 <\Test_User> assembler does what I tell it no matter what
17:57:00 <Andrew> not the assembler itself
17:57:00 <\Test_User> yes
17:57:00 <Andrew> but it shouldn't alter output or stuff
17:57:00 <\Test_User> *as long as it is valid, not no matter what
17:57:00 <Andrew> Well.. it's a bit hard to validate assembly stuff you know
17:57:00 <heat> why are you comparing C to assembler?
17:57:00 <Andrew> Because types don't exist
17:57:00 <heat> C is not a low level language
17:57:00 <Andrew> heat: How is this a comparison?
17:57:00 <\Test_User> we're talking about 2 at once
17:58:00 <Andrew> Well, they're similar in the case of memory management, both are unsafe
17:58:00 <\Test_User> not comparing directly, though there is comparison to the overflow/carry flag for what is possible
17:58:00 <Andrew> But, true C has types
17:58:00 <heat> assembly is barely a language
17:58:00 <heat> what's memory management in assembly? sub $8, %rsp?
17:58:00 * geist yawns
17:59:00 <geist> how is everyone
17:59:00 <Andrew> "mov"
17:59:00 <heat> geist, fine. how are you?
17:59:00 <\Test_User> memory management in assembly is what you write it to be
17:59:00 <Andrew> register management[tm]
17:59:00 <\Test_User> I'm doing fine
17:59:00 * Andrew fills \Test_User with null bytes
17:59:00 * \Test_User passes Andrew a nullptr
17:59:00 * psykose fills |Test_User with 0x4 bytes
17:59:00 <heat> nullptr?????
17:59:00 <heat> this is C homie
18:00:00 <heat> pass him NULL, or 0, nothing matters really
18:00:00 * geist tries to catch up with this conversation but guesses it's not worth it
18:00:00 <psykose> it isn't
18:00:00 * geist thumbs up
18:00:00 <Andrew> it's just chitchst
18:00:00 <\Test_User> yes but nullptr is more obvious when spoken
18:00:00 <Andrew> *chitchat
18:00:00 <geist> roger roger
18:00:00 <\Test_User> or rather, when typed in IRC :P
18:00:00 <heat> I said C is crap and they're saying it isn't
18:00:00 * Andrew passes \Test_User a derlict corvi
18:01:00 <heat> which it is, every language is crap
18:01:00 <heat> i'm yet to find a good one
18:01:00 <Andrew> heat: HeatLabg
18:01:00 <heat> it's exactly like build systems
18:01:00 <Andrew> *HeatLang
18:01:00 <heat> naw i'm good
18:01:00 <\Test_User> every language is crap - sure I'll agree to that, but *in comparison*, I find C to be one of the less crap ones
18:01:00 <Andrew> heat: I think MMIX Assembly is a good language is you ignore its CamelCase
18:02:00 <Andrew> Let's just use JavaScript for OS Dev
18:02:00 <\Test_User> Andrew: that's still assembly
18:02:00 <\Test_User> lol jsos
18:02:00 <Andrew> s/J.*t/HTML and CSS/
18:02:00 <\Test_User> jSOS
18:02:00 <heat> that's possible
18:02:00 <heat> OS on top of electron
18:02:00 <Andrew> \Test_User: Yes it is still assembly but mmix assembly is much better than x85 assembly
18:02:00 <heat> who says no?
18:02:00 <Andrew> AHHHAHHAHA
18:02:00 <Andrew> NOONIININNIAJSSS
18:02:00 <Andrew> HSHDH
18:03:00 <heat> you good?
18:03:00 <kingoffrance> he is being punished for the js statement
18:03:00 <kingoffrance> purified
18:03:00 <Andrew> xD
18:03:00 <\Test_User> XD
18:03:00 <kingoffrance> let us pray
18:03:00 <Andrew> That was a joke :D
18:03:00 <kingoffrance> speak of the js
18:03:00 <Andrew> And someone extended it to electron
18:04:00 <Andrew> No I will not learn Ajs
18:04:00 <Andrew> *JS
18:04:00 <Andrew> In fact my primary browser doesn't support JS
18:04:00 <Andrew> \Test_User: Big endian, thanks
18:05:00 * \Test_User passes Andrew his little-endian assembler and hd
18:05:00 <\Test_User> (still not yet created sadly)
18:06:00 <Andrew> if the rest of the language is written in hebrew or arabic or similar
18:06:00 <\Test_User> lol
18:06:00 <Andrew> I accept little-endian
18:06:00 <Andrew> If it's in english
18:06:00 <Andrew> I want big-endian
18:06:00 <\Test_User> little-endian in english ofc, I don't know little-endian languages nor can my keyboard easily type that rn
18:06:00 <Andrew> what the heck is middle-endian
18:06:00 <\Test_User> insanity
18:07:00 <\Test_User> probably something that never should have existed
18:08:00 <Andrew> little-endian is big-right small-left
18:08:00 <\Test_User> "small-left"?
18:08:00 <Andrew> fine
18:08:00 <Andrew> you get what i mean
18:08:00 <\Test_User> ahhh misreading things
18:08:00 <Andrew> and that confuses lefttoright readers
18:09:00 <\Test_User> but yes
18:09:00 <GeDaMo>
18:09:00 <bslsk05> ​ middle-endian
18:09:00 <merry> i've seen one arch with that
18:09:00 <merry> *modern
18:09:00 <\Test_User> idc, the point of such an assembler and hexdump is to get them used to looking at it for how it is when stored in ram
18:09:00 <\Test_User> (idc about confusing people initially looking at it)
18:20:00 <Matt|home> opinion : in general is there an advantage to running say openbsd to host my servers versus like fbsd or something, or are the security advantages negligible over convenience? or should it be paranoia at all times 100% since this is publicly accessible
18:21:00 <Matt|home> er
18:21:00 <Matt|home> wrong channel
18:21:00 <Matt|home> sry
18:22:00 <Andrew> Matt|home: Even though this is the wrong channel; I prefer OpenBSD not really because of its security but because there aren't nonfree drivers or nonfree blobs in the kernel to worry about; OpenBSD's code quality is really good which is also a factor for me to like OpenBSD better, though security-wise OpenBSD and FreeBSD_with_TrustBSD aren't really different
18:23:00 <Matt|home> i remember open being a pain in the ass to work with the last time.. but that was well over a decade ago
18:23:00 <Matt|home> and i know a lot of servers run fbsd now
18:24:00 <geist> yah my main concerns nowadays would be running openbsd on high end machines. i get the feeling it doesn't scale as well, etc
18:24:00 <geist> but for simple single tasked servers i bet it's fine
18:24:00 <Andrew> Open is easy to work with IMO; I'm using debian on my most-public server now for one reason: GNUnet, which hasn't been ported over yet
18:24:00 <Matt|home> my main concern is that im gonna be running these on my main desktop.. like.. i use banking and shit on here
18:24:00 <Andrew> geist: No SMP in the kernel isn't a big performance hit even fore quite performant machines in my experience
18:25:00 <Andrew> I use OpenBSD as my primary desktop
18:25:00 <heat> openbsd has a BKL?
18:25:00 <Andrew> Along with some other systems
18:25:00 <Matt|home> i suppose i can learn a bit about both. it's been a long time since i did any bsd sys admin stuff. i used to know a lot about it :D
18:25:00 <Andrew> Forgot what bkl meant
18:25:00 <j`ey> big kernel lock
18:25:00 <heat> big kernel lock
18:25:00 <Matt|home> the hell is that
18:26:00 <geist> yah ii just dont think open and netbsd have been able to keep up with that, netbsd in particular
18:26:00 <geist> but i am possibly just entirely wrong
18:26:00 <Andrew> Not sure if there's a bkl
18:26:00 <geist> ie, for simple 4-8 cpu machines they're probably fine for light load
18:26:00 <Andrew> But openbsd kernel has not as good multicre
18:26:00 <mrvn> Matt|home: There are basically 2 security scenarios you have to cover: Mossad and not Mossad.
18:26:00 <heat> As of July 2019, OpenBSD and NetBSD are still using the spl (Unix) family of primitives to facilitate synchronisation of critical sections within the kernel,[4][5][6] meaning that many system calls may inhibit SMP capabilities of the system, and, according to Matthew Dillon, the SMP capabilities of these two systems cannot be considered modern.[7]
18:26:00 <Andrew> but performance wise it's totally fine, *for me*
18:26:00 <Matt|home> ah. that's a neat idea
18:26:00 <Matt|home> only 1 thread in kernel space at a time
18:26:00 <Matt|home> i like that
18:26:00 <heat> neat?
18:26:00 <geist> oh sure
18:27:00 <Andrew> but for your usecases, trustbsd on freebsd is enough
18:27:00 <geist> it's the standard first step of taking a non SMP kernel into the SMP world: keep one thread in the kernel at a time
18:27:00 <Andrew> in fact, selinux on a linux-based system would be enough
18:27:00 <geist> then you start breaking that up. lots of older kernels went through that path
18:27:00 <Matt|home> ... i dont supose anyone knows where i put my phone
18:28:00 <mrvn> Matt|home: why don't you call yourself. :)
18:28:00 <Andrew> I know where my phone is because it's in a lead cage all the time except when the government wants a dynamic qr code health code from it
18:28:00 <heat> Andrew, linux is relatively secure
18:28:00 * Andrew looks at Linux CVEs
18:28:00 <heat> plenty of eyes, plenty of very compentent, experienced devs and maintainers
18:29:00 <Andrew> Though, Linux with SELinux is pretty secure
18:29:00 <heat> openbsd has a much lower usage
18:29:00 <mrvn> Andrew: If the Mossad wants your password they just get your to tell them. And if it's not the mossad attacking you they aren't going to hack your server.
18:29:00 <heat> a lot fewer eyes
18:29:00 <Andrew> Indeed
18:29:00 <Andrew> mrvn: Mossad?
18:29:00 <mrvn> Andrew: Mossad is the
18:29:00 <mrvn> national intelligence agency of Israel, really badass
18:30:00 <Andrew> Ah
18:30:00 <mrvn> i.e. professionals
18:30:00 <Andrew> Well
18:30:00 <Andrew> (1) My classmates attack my server all the time
18:30:00 <Andrew> though their attacks are really rudimentry
18:30:00 <mrvn> It's more likely you get triuckerd into some scam via email or web pages than someone hacking your desktop.
18:30:00 <Andrew> Any sane setup, even eithout zMac will do
18:31:00 <\Test_User> "or accidentally pasting your passwords..."
18:31:00 <Andrew> (2) I don't use modern Web browsers and stuff, a little harder to scam me
18:31:00 <Andrew> \Test_User: Alright fair enough - but I had a sane allowmask
18:31:00 <Andrew> And I don't do online payment
18:31:00 <\Test_User> mostly fair enough
18:32:00 <\Test_User> ~~add some filter to block you from pasting passwords where they shouldn't go~~
18:32:00 <Andrew> (Sometimes when I'm tired (like now) I might do something like paste passwords into the inspircd help channel when configuring inspircd)
18:32:00 <mrvn> The best way to not get hacked by your friends: To given them any service to hack.
18:33:00 <mrvn> +not
18:33:00 <Andrew> I cracked my school's stuff once
18:33:00 <heat> update yer shit
18:33:00 <bslsk05> ​xkcd - Exploits of a Mom
18:33:00 <Andrew> And I discovered a there
18:33:00 <heat> "hackers" are usually just script kiddies
18:34:00 * geist hacks gibsons all the time
18:34:00 <heat> take away their ability to pwn you with scripts and you're safe
18:36:00 <Andrew> heat: if the crackers are os developers that's another story
18:37:00 <Andrew> (assembly is quite critical to real cracking)
18:37:00 <GeDaMo> osdevs break their own systems :P
18:37:00 <Andrew> trur lol
18:38:00 <Andrew> \Test_User: suffering from spectre and meltdown?
18:38:00 <\Test_User> no
18:38:00 <\Test_User> just wanting to ensure it can't happen
18:38:00 <heat> im too busy trying to figure out why processes sometimes crash under heavy load to write csgo best hack aim wall bhop 2022 updated see link in the description
18:38:00 <\Test_User> well, at least, not that I know of :P
18:40:00 <\Test_User> will get around to reading all of the other major ones as well eventually
18:41:00 <Andrew> \Test_User: Plate your CPU with regenerating plastanium to fix it
21:10:00 <zid> heat: Did you finish my wallhack yet
21:10:00 <zid> I want to finally get to silver 2
21:12:00 <zid> He's done a runner!
21:12:00 <zid> oh he's back already nevermind
21:24:00 <heat> zid, no im busy
21:24:00 <heat> maybe next month
21:25:00 <heat> hopefully I wont postpone it enough that I need to change the name to "csgo best hack aim wall bhop 2023 updated see link in the description"