zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 260 seconds]
bradd has quit [Ping timeout: 260 seconds]
bradd has joined #osdev
agent314 has quit [Ping timeout: 272 seconds]
<kof213>
re: jazelle, the documentation provided with Sun's HotSpot Java Virtual Machine goes as far as to state: "For the avoidance of doubt, distribution of products containing software code to exercise the BXJ instruction and enable the use of the ARM Jazelle architecture extension without [..] agreement from ARM is expressly forbidden."
<kof213>
> thumbEE (erroneously called Thumb-2EE in some ARM documentation), which was marketed as Jazelle RCT^[125] (Runtime Compilation Target), was announced in 2005 and deprecated in 2011
<kof213>
and wikipedia implies qemu does a "trivial" jazelle implementation that doesn't really do anything
<kof213>
the thumbEE sounded interesting but :/
heat has quit [Quit: Client closed]
[itchyjunk] has quit [Remote host closed the connection]
agent314 has joined #osdev
pg12 has quit [Ping timeout: 248 seconds]
sikkiladho has quit [Quit: Connection closed for inactivity]
pg12 has joined #osdev
Ameisen has quit [Quit: Quitting]
Ameisen has joined #osdev
pg12 has quit [Ping timeout: 255 seconds]
Ameisen has quit [Client Quit]
Ameisen has joined #osdev
pg12 has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
gabi-250 has quit [Remote host closed the connection]
Vercas has quit [Remote host closed the connection]
gxt_ has quit [Remote host closed the connection]
blop_ has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
gabi-250 has joined #osdev
gxt_ has joined #osdev
Vercas has joined #osdev
gildasio has joined #osdev
Osmten has joined #osdev
blop_ has joined #osdev
sbalmos has quit [Ping timeout: 258 seconds]
sbalmos has joined #osdev
SGautam has joined #osdev
mdaadoun has joined #osdev
agent314 has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
Osmten has quit [Quit: Client closed]
leitao has joined #osdev
leitao_ has joined #osdev
GreaseMonkey has quit [Remote host closed the connection]
leitao_ has quit [Client Quit]
leitao has quit [Ping timeout: 248 seconds]
goliath has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
<bslsk05>
marc.info: 'any work on port of rtw89? (realtek 8852 AE/BE/CE)' - MARC
<heat>
theo is the bitterest motherfucker ever
<ChavGPT>
i was going to say it is pretty lame to respond like that to begin with
<ChavGPT>
but then again, wtf am i doing even readin that exchange
<heat>
i was looking for the patchen but instead found these messagen
<ChavGPT>
the patchen are old and already in the repo, i was poking around
<heat>
i wonder if he's this insufferable IRL
<ChavGPT>
maybe someone should ask theo how performance is going
<ChavGPT>
did you know they claimed openbsd pf is gonna overtake freebsd
<ChavGPT>
about a decade ago
<pog>
PERFORMANT
<zid>
PERGANANTE
<pog>
performance is performative anyway
<heat>
OPTIMATES
<pog>
virtualization signalling
* ChavGPT
increases performance by 10%
<heat>
pog what's your favourite roman republic politician
<ChavGPT>
done
<pog>
heat: elagabalus
<heat>
THATS NOT THE ROMAN REPUBLIC
<pog>
i don't think about rome
<heat>
fuck
<Ermine>
heat: I meant 'kernal'
<heat>
k*rn*l
<Ermine>
ntoskrnl
<ChavGPT>
ntos kernal
<ChavGPT>
my favurite
<heat>
pog, mine is clodius btw
<heat>
>Clodius managed to gain entry to the rites, disguised as a woman, apparently with the intention of seducing Pompeia, but was discovered in the course of the evening
<heat>
fucking genius
<ChavGPT>
probably taking a piss in the middle of the room gave him away
<kof213>
> The Ancients adored the Sun, under the form of a black Stone, called Elagabalus, or Heliogabalus. The faithful are promised, in the Apocalypse, a white Stone gog already won alchemy chat
* kof213
awards gog magical stone
<ChavGPT>
marcus theoius
<ChavGPT>
pioneer of openbsdoicism
<heat>
you're just jealous theo invented security before you did
<bslsk05>
aprendiendo.pasosdejesus.org: AdJ - Aprendiendo de Jesús
<netbsduser>
the distribution of openbsd for fomenting the construction of the Kingdom of God and for the education and the respect for the human dignity, i can only presume the spanish means
<zid>
>open bsd >human dignity
<zid>
how can we reconcile the unreconcileable though?
<mcrod>
i’m hungry
<kof213>
> how can we reconcile the unreconcileable though? the hercules answer is you strangle them both
<sbalmos>
"Feed the birds... tuppence a day... Tuppence... Tuppence... Tuppence a day..."
muffin has quit [Quit: WeeChat 4.0.5]
<gorgonical>
You ever get that feeling when designing some mechanism or abstraction that you're doing it wrong and the right choice will be so obvious once you know it, but you can't imagine what you're doing wrong?
<GeDaMo>
You don't know how to write a program until you've already written it
<gorgonical>
I guess not. But when making so many choices all at once it's hard to shake the feeling that at least some of them are not the right ones
admiral_frost has joined #osdev
gildasio has quit [Ping timeout: 252 seconds]
gildasio has joined #osdev
flom84 has quit [Remote host closed the connection]
<geist>
gorgonical: yep, that's how you learn
<geist>
much better than not caring and never looking back. you dont learn that way
<heat>
yeah i think the organic way of developing an abstraction is to actually need it
<heat>
like, current kernels' vm systems are designed the way they are for a need, if you go back hard enough you just programmed the MMU directly, no abstraction
<zid>
<GeDaMo> You don't know how to write a program until you've already written it
<zid>
agreed
<zid>
First attempt is "how the fuck does this even work?" second attempt is "Okay that's way better"
<zid>
third attempt is the alpha release
<heat>
same thing for e.g filesystems. early UNIX's read()/write() directly touched the filesystem's stuff, no "VFS" or anything of sorts
<zid>
fourth attempt is someone tells you this is a solved problem with a proof and you're an idiot
<heat>
lol
<heat>
yeah this is all pretty iterative
<heat>
reading theory on $subject is just a way to shortcut a bunch
<zid>
I did that exact thing with like, linked lists
<zid>
I had heard what one was, wrote a janky one
<ChavGPT>
early unix literally did not have reboot
<ChavGPT>
and i think shutdown
<zid>
wrote a significantly less janky one, then found out that linus thought I was dumb and I should be using *(&p)->next
<zid>
and he was right
<ChavGPT>
also i remind you of 'sync;' bro
<heat>
sync; sync; reboot
<ChavGPT>
that's the wrong way on 2 accounts
<ChavGPT>
1. it is 3 syncs
<heat>
3 syncs?
<ChavGPT>
2. you are not supposed to do them like that
<heat>
i remember reading about sync; sync; reboot
<ChavGPT>
the idea was the fastest typist they got managed to cram in sync 3 times back to back
<heat>
tony curtis there thinks it's sync sync sync manually to fucking artificially delay rebooting until the caches were flushed
<ChavGPT>
... in the time the kernel needed to flush
<ChavGPT>
this is the story
<ChavGPT>
random usenet group is not a source
<heat>
you're not a source either
<heat>
you're as legit as a random usenet group
<ChavGPT>
i'm trying to find the source
<ChavGPT>
i don\'t remember wher it was, probably tuhs
<heat>
but these boomers wrote this 23 years ago so it's probably close-ish to the truth
<heat>
yeah tuhs may have this somewhere
<heat>
>Yours in the glory that is our Lord Jesus Christ,
<heat>
what's wrong with usenet people?
<ChavGPT>
i got nothin'
<heat>
reverend don kool here spitting the facts about linux and freebsd AND blessing us
<heat>
i feel like all of these posts were written in the far past where everyone was slightly-very nuts
Terlisimo has quit [Quit: Connection reset by beer]
<netbsduser>
the first vmm of the modern sort i can think of is that of Mach
<netbsduser>
it's hard to understate what a revolutionary force that kernel was in the Unix world
bauen1 has joined #osdev
gildasio has quit [Remote host closed the connection]
<netbsduser>
VMS and others had advanced ones but not yet abstracted
<ChavGPT>
the name of the game is mind-boggling primitivism
<ChavGPT>
of early unix
<heat>
gnu hurd
<ChavGPT>
the kenrel exported nothing, you got all the info by perusing its memory (lol)
<heat>
ChavGPT, you mean pragmatism ;)
Terlisimo has joined #osdev
<netbsduser>
yeah, mach had to march unix kicking and screaming into modernity
<netbsduser>
and what a legacy it left
<ChavGPT>
yes very pragmatic to have userspace tooling read kernel memory
<ChavGPT>
for basic usage
<heat>
very pragmatic to export kernel memory so userspace can read whatever the fuck it wants
<netbsduser>
the SunOS VM cites the Mach as prior art
<ChavGPT>
mofer
<heat>
mach left us the great legacy of crippling vm subsystem deficiencies and gnu hurd
<heat>
thank mr mach
<netbsduser>
linux did their own thing but converged on Mach like concepts (until very recently, i think linux 2.4 or 2.6, they used to iterate through all page tables when they decided to swap out a page of memory, to unmap it across all)
<heat>
>very recently
<heat>
are you a time traveler from 2005?
gildasio has joined #osdev
frkzoid has quit [Ping timeout: 258 seconds]
<netbsduser>
i first dabbled in linux when i was quite young, a Mandrake CD came with Computer Shopper Magazine
<netbsduser>
and that must've been 2004 or 2005
<ChavGPT>
define young
<netbsduser>
when i was around 10
<ChavGPT>
you are less than 30
<ChavGPT>
and are into solaris?
<ChavGPT>
wtf
<netbsduser>
a lot of people tend to experiment with things like Linux around that age
<heat>
i'm also less than 30 and into solaris
<heat>
is there a problem ChavGPT
<ChavGPT>
heat: you are special
<zid>
Why do you have to bring up your fetishes so often heat
<ChavGPT>
me and Jeff B know
<netbsduser>
ChavGPT: i got OpenSolaris 2008.05 sent to me by Sun
<netbsduser>
they did it for free if you were scottish since they had a branch in Linlithgow
<ChavGPT>
i get it, you were touched young and it left an imprint
<heat>
WHAT
<netbsduser>
you just filled in a short form and got sent it
<ChavGPT>
don't let random circumstances dictate your life tho
<netbsduser>
a live CD, or it might've been DVD, whatever it was, it was great
<heat>
so this linux thing i installed like 8 years ago, dual booted
<heat>
just for osdev
<heat>
turns out it
<heat>
kinda sucks ass
<netbsduser>
i had a terrible time with linux in that era
<heat>
huge waste of time
<netbsduser>
especially because i tried to dual boot
<heat>
meh dual booting works fine these days
<netbsduser>
you couldn't even open a door without the install breaking and getting that "GRUB 0.97 \ Minimal BASH-like line editing is supported. For blah blah blah, do blah blah blah"
<ChavGPT>
mon linux would fail to reboot if you looked at it funny
<ChavGPT>
as ext2 would go to sht
<ChavGPT>
it has come a long way
<heat>
the only annoying bit is that windows and linux can't decide on what the hwclock is, UTC vs local
<netbsduser>
i think ext3 was around in my day
<heat>
but windows actually grew UTC hwclock time
<netbsduser>
and i never had much issue there
<heat>
journaling is pog
<netbsduser>
but even ext2, though it wasn't log-enhanced like ext3, i would struggle to figure out how you could cock it up so badly that fuck.ext2 couldn't restore it to usability
<CompanionCube>
isn't windows UTC hwclock unsupported still
<heat>
no
<heat>
since some build of windows 10 there's a register setting for it
<bslsk05>
techcommunity.microsoft.com: Unresponsive Servers due to DST and an unsupported registry key - Microsoft Community Hub
<heat>
CompanionCube, works fine here
<netbsduser>
yeah, it is not an incredible gain with ext2 since you have at most to go through a few indirections to map a file to a disk block, but i'm hoping to do it anyway for the sake of efficiency in i/o, even if i never get around to ext4
<netbsduser>
i'm undecided on what strategy i want to take
<CompanionCube>
heat: yeah i mean in the sense of 'officially' i guess
<netbsduser>
a buddy would be fun but the overhead might be forbidding for big disks
<netbsduser>
linear search is pessimal but might not really matter much with delayed allocation
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<immibis>
heat: I read that on the PlayStation 4 the hardware clock isn't even writable. The OS has to update its own offset instead
<netbsduser>
i suppose i am a little concerned that the bitmap-based buddy caches that paper discusses may be large, but sometimes you just need to remind people that small main memory + big disk = stupid
<netbsduser>
immibis: it is quite new, i think it only came out in 2004 or thereabouts
<heat>
immibis, ugh, sounds like a borked RTC
<netbsduser>
and since then they have had version number inflation in linux land, though to their credit not nearly to the absurd and unreasonable degree that the likes of firefox and chrome do
<heat>
netbsduser, i mean, as long as you're smart and can swap those bitmaps out
<immibis>
heat: deliberate decision
<immibis>
they've done it since the PS2. Might be something to do with downgrade prevention
<netbsduser>
heat: i took a bit of umbrage with how FastFAT maintains its cluster bitmap
<immibis>
every version number inflates - that's the purpose of a version number. The only question is which number you want to inflate.
<netbsduser>
they make the cluster bitmap pageable anonymous memory
<heat>
netbsduser, if you do a 1TiB/4KiB block size that's going to cost you if you can't discard them
<immibis>
when your software has a lot of versions, it's inevitable to have a lot of version numbers.
eddof13 has joined #osdev
<immibis>
you can do 1.0-1.999 like Minecraft; 1-999 like Firefox; a mixture of both like Linux; or make up something each time like Windows.
<immibis>
Open source has even more version numbers because it doesn't tend to do big bang releases, too
<netbsduser>
and i just think it would be more elegant if it were disposable (subject to replacement and demand-loaded whenever someone needs to look at a particular area of the said bitmap) instead, rather than pageable anonymous memory
<heat>
oh yeah for sure
<immibis>
like there's a clear delineation between windows XP and Vista, but Linux 4 to Linux 5 is a continuum
<netbsduser>
there's just something i don't like about making filesystem driver metadata into anonymous memory
<heat>
i wouldn't swap any kind of kernel memory anyway
<heat>
like as long as you can flush the buddy data to disk, you're golden
<immibis>
that's why your kernel requires 4GB
<heat>
oh and swapping FS driver stuff sounds like a particularly hellish corner of hell
<netbsduser>
i have full and comprehensive support for pageable anonymous memory in the kernel but i haven't found any good uses for it yet
<immibis>
unless it's a microkernel so all the big data isn't in the kernel
<immibis>
well I suppose that's actually a nanokernel which doesn't allocate any memory ever
<heat>
like imagine you're cleaning some pages, deep into LRU page replacement code, you fault some FS data structure in... lock fuckyness ensues
<netbsduser>
actually i will probably put tmpfs' tmpnodes and tmpdirents into pageable memory, that seems like a good use of it
<immibis>
Like I read about KeyKOS - a userspace process allocates pages to other processes, and you even have to gift pages to the kernel for it to hold data structures for you
<immibis>
you want to open a file, well you tell the kernel which slot in which page to store the metadata for that (actually the kernel doesn't open files, but it still has metadata to track which open-file process you're connected to)
<immibis>
so the kernel never has to allocate file descriptors or pipe descriptors or whatever
<immibis>
I assume this is a common nano kernel design by now - keykos is a really old paper
<netbsduser>
keykos is of a wonderful structure
<netbsduser>
i read the paper on how they implemented unix with it
<netbsduser>
inodes and dirents are just objects like any other in the single-level store
<immibis>
they're PROCESSES
<immibis>
they have code associated with them
<immibis>
although with the amount of code sharing, i suppose they are more analogous to OOP objects
<immibis>
i suppose most processes are analogous to OOP objects although they have a very heavy per-object overhead so you generally only have a few
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
danilogondolfo has quit [Remote host closed the connection]
netbsduser has quit [Ping timeout: 255 seconds]
wblue has joined #osdev
netbsduser has joined #osdev
wblue has quit [Client Quit]
DanielNechtan is now known as bombuzal
heat has quit [Ping timeout: 240 seconds]
gbowne1 has joined #osdev
gxt_ has quit [Ping timeout: 252 seconds]
gbowne1 has quit [Remote host closed the connection]
gxt_ has joined #osdev
gbowne1 has joined #osdev
<netbsduser>
immibis: they are directly equivalent
gorgonical has quit [Ping timeout: 260 seconds]
<netbsduser>
stephen kell, the great defender of the Unix and C tradition, explains it in a delightful talk
Turn_Left has joined #osdev
<immibis>
a lot of things are equivalent in theory but not in practice
Left_Turn has quit [Ping timeout: 240 seconds]
<immibis>
docker containers are just processes
<immibis>
people talk about needing docker to isolate things - processes do that
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
<Bitweasil>
Eh...
<Bitweasil>
I don't trust processes, nor any sort of kernel separation, for anything but "utility separation" - I don't trust either against any hostile workloads that try to get that which they're not granted.
<targetdisk>
so imagine making a programming language that builds a program that hangs when you declare and initialize a local struct in a single statement with some members missing
<targetdisk>
no compile errors, just a program that hangs your UEFI
<targetdisk>
noice
<targetdisk>
fucking love C
<immibis>
Bitweasil: that's because your kernel is full of holes
<immibis>
or (since spectre) your CPU is, but containers don't solve that either
<immibis>
targetdisk: that doesn't hang C programs, and it doesn't even leave the missing members uninitialized - if you have any initializer at all, the whole struct is initialized, by default to 0
Turn_Left has joined #osdev
<targetdisk>
apparently it might sometimes with GNU extensions
<immibis>
however... since this is #osdev, you may encounter something like that if the compiler decides to initialize them with memset, and your memset function isn't hooked up properly
<targetdisk>
:/
<targetdisk>
Yeah I'm not fixing that, just making a mental note of this caveat for next time
Left_Turn has quit [Ping timeout: 258 seconds]
FreeFull has quit []
<mcrod>
hi
gxt_ has quit [Remote host closed the connection]
gxt_ has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Bitweasil>
immibis, yes, that's the problem. The Docker isolation (or any namespace separation) assumes the kernel can hold up to a malicious bit of code, and it seemingly can't anymore, or probably ever.
<immibis>
so write one that can
<immibis>
I take it you have multiple computers
<Bitweasil>
I just use hardware virtualization separation for desktop computing. I'm one of the nutty Qubes users.
<immibis>
possibly more than one running tails
<Bitweasil>
And am trying to get computing out of my personal life.
<immibis>
Bitweasil: that assumes your hypervisor can hold up to a malicious bit of code
<immibis>
VMs are directly equivalent to processes
<immibis>
hypervisors are directly equivalent to kernels
<Bitweasil>
Don't trust Tails. If it's not the Whonix style separation of workstation and gateway, it's of almost no value.
<Bitweasil>
Yes. I'm aware. I consider a stripped Xen more trustworthy than the Linux kernel.
<immibis>
you should consider neither trustworthy, surely? run a tor proxy on a *separate device*
<Bitweasil>
(Xen without a lot of the legacy hardware emulation bits and pieces that can allow you move laterally into Dom0)
<Bitweasil>
Sure, you can do that too, but if someone can move laterally between VMs, I'm not sure a separate device gains you much.
<immibis>
you could say the same about docker containers
<Bitweasil>
At some point, against a suitably high level adversary, you simply can't trust any digital device.
eddof13 has joined #osdev
<Bitweasil>
I don't trust the kernel at all. I trust hypervisors "somewhat more."
<Bitweasil>
Not entirely, but enough to make it worth the minor inconveniences of Qubes.
<Bitweasil>
Most of which are things I never cared about anyway, like graphical rendering performance and video decoding.
<mcrod>
i find most security concerns to be a game of relativity
<mcrod>
who are you protecting yourself from, what data do you need to protect from an adversary
<immibis>
the linux kernel is better than you think, and the xen hypervisor is not as good as you think
<immibis>
especially if you are passing hardware through - this applies to any hypervisor
<mcrod>
if you’re at a level where you’re *this* concerned
<mcrod>
you should live in faraday cage
<mcrod>
i’m not even being funny either
<immibis>
mcrod: a lot of people ask "is this secure?" and then it's important to figure out "secure against what?" but there are also people who have fun trying to build maximally secure systems and i think threat modeling is not so important for the latter group
<immibis>
because their threat model is "everything"
<mcrod>
right
<Bitweasil>
Sure, if you're doing hardware passthrough, you're concerned with performance. I'm not. :)
<immibis>
Bitweasil has decided to try and build a maximally secure system under the assumption that hypervisors are foolproof and physical access (even wireless from nearby) isn't a threat
<Bitweasil>
I... what?
Burgundy has quit [Ping timeout: 255 seconds]
<immibis>
Bitweasil: do you live in a faraday cage to defend yourself from TEMPEST? no you don't because TEMPEST is outside your threat model
<mcrod>
to your point though, a high enough level actor will eventually fuck you over
<Bitweasil>
No, I decided that for my needs, Qubes provides more practical isolation from web based network threats than not using it, and I assume that anyone with physical access wins entirely.
<Bitweasil>
Sure.
<mcrod>
sooner or later, you will make a mistake
<immibis>
and you don't use device isolation because you assume hypervisors can't be escaped
<Bitweasil>
I'm not particularly worried about nationstates, though I would like to avoid watering hole attacks doing any sort of lateral spread.
<Bitweasil>
I never said that. I said they're a harder boundary than the kernel.
<immibis>
how come they are hard enough but the kernel isn't? actually, i know why: extra devices cost extra money
<Bitweasil>
I assume your typical well funded three letter agency can *probably* pass through hypervisors. However, I also expect that a range of browser based attacks won't include that sort of thing.
<Bitweasil>
(see WebP for a recent browser level attack)
<Bitweasil>
I'm swimming in hardware.
<Bitweasil>
I actually want to get rid of a bunch of it.
<mcrod>
virtualization isn’t a big shield
<immibis>
i assume that you'd isolate your hypervisors from each other inside a compuglobalhypermegavisor if such a thing existed
<Bitweasil>
I'm sorry, are we having a conversation, or are you just painting me with this fictional "paranoid person" brush? If the second, there's no point here.
<immibis>
is your hypervisor secure against MDS?
<immibis>
the CPU has more holes than any kernel
<immibis>
more holes than windows 95
<mcrod>
it’s a little paranoid
<mcrod>
but for all we know
<mcrod>
you may be a target for someone
<immibis>
we are trying to understand the use case that leads you to consider hypervisors are secure enough but kernel isolation isn't
<mcrod>
honestly i don’t care enough about security more than i should
<Bitweasil>
It adds an additional layer of substantial thickness between "network activity being rendered locally" and "things I consider important, like my SSH keys or password store."
<Bitweasil>
On a typical single system image, if you can exploit the kernel, you have everything on that system.
<mcrod>
do you use yubikeys
<immibis>
of all the defcon talks i've litsened to, the linux kernel never seems to be involved in an exploit chain
<Bitweasil>
Adding a hypervisor, you now need to chain an additional high value exploit (hypervisor escape/transition) to get out of the sandbox VM you're initially in.
<Bitweasil>
Qubes makes that sort of flow fairly easy.
<Bitweasil>
Counterpoint: Local root/kernel exploits aren't sexy enough to make it to Defcon.
<bslsk05>
www.cvedetails.com: Linux Linux Kernel : Security vulnerabilities, CVEs
<immibis>
i think it's just because qubes predates docker. I think qubes would use docker if it was made today
<mcrod>
unrelated: fuck docker
<Ermine>
why
<immibis>
docker is namespaces put together in a confusing way. I find myself using network namespaces a lot. Other ones not so much.
<mcrod>
i just don’t see the exact point of it
<Bitweasil>
I don't think so. Invisible Things Labs is properly paranoid about the kernel and even hardware - they've done a lot of work on hypervisor escape, the old Follow the White Rabbit paper on a Xen escape was a good one.
<immibis>
i used docker to work around an embedded toolchain being very pedantic about the paths it was installed in. It was more annoying than if it could be installed normally, though.
<Bitweasil>
So given their background working with hypervisor escapes and security, they've made what I agree are a sane set of choices in how Qubes is architected.
<Bitweasil>
Sure, Docker is perfectly for the "bring your own weird library set" stuff. A bit nicer than chroot jails, for sure.
<mcrod>
one of the reasons i’m bothering admittedly with a somewhat large toolchain_build script
<mcrod>
clone the repo, run toolchain_fetch
<mcrod>
there, no docker and shit just works
<Ermine>
gns3 can into docker containers => docker is useful for testing networking stuff
<mcrod>
well that’s not my use case :p
<mcrod>
my use case is “provide compilers and the libraries the project uses into a folder called assets”
<mcrod>
delete? rm -rf
<Bitweasil>
Oh, I run my browsers without the Javascript JIT engines, too. :) Just interpreted. Removes another whole swath of attack paths.
<mcrod>
i don’t understand what kind of threat you’re under to go that far
<immibis>
Ermine: don't know if GNS3 is different but Docker generally sucks for that. You can do networking stuff with raw netns's and veth's and don't need each one to have its own filesystem
<immibis>
docker tries to impose its own networking model on you
<immibis>
you might want to use one to emulate an end device, maybe
<mcrod>
i just in general don’t believe in the “spin up a whole VM to do x” model
<Ermine>
I'd go with lxc, but it's not supported :(
<mcrod>
seems like pure shit to me
<immibis>
unless the thing you are trying to do is to emulate a particular device, of course.
<immibis>
if you want to test how ubuntu x.y does something, install it in a VM and find out
<mcrod>
i think the problem is right up there with the rust attitude: it will solve ALL of your problems
<mcrod>
and… that’s *not* true
<immibis>
a very common attitude. see: blockchain
<immibis>
see also: AI
<Ermine>
In my case I need to simulate 2 machines with software I'm testing
<Ermine>
Also some kind of drop-in dns server would be useful. Maybe VM with unbound on it will do
<immibis>
if your software's networking requirements are normal, you can even just run two instances on the same machine and connect to localhost
<immibis>
this may not apply if the point of the software is to mess with the network itself
<immibis>
but it does apply if you just make a normal connection
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
<mcrod>
i dunno. i'm not innocent of this by any stretch as I've fallen down the rabbit hole a dozen times, but people like to complicate things
<immibis>
if you are testing software that just makes a TCP connection to a server, you are overcomplicating it by using VMs at all
nyah has quit [Quit: leaving]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]