<kof123>
eh, its like special compiler flags. the spots that would hurt are 1) speed hit to generate (or background this when idle, and keep caches) 2) larger code 3) cost of keeping such artifacts around, and keeping source around
<kof123>
i.e. i would call it ricing lol
<kof123>
it is a poor version of "profiler-guided optimizations" in a way
<mjg>
wut
<mjg>
that's some weird idea mate
<mjg>
key observartion being that piping already loses a lot of perf
<mjg>
if the win was trivial i would have no comment, but it is not
<mjg>
i mean rivial to obtain
<mjg>
i would argue this is the case where you have to abandon the one liner and write a prog doing the work
<mjg>
interestingly with RUST this is supposed to be reasonably painless
<zid>
program -> output { pls }
<heat>
is that PESSIMAL
<kof123>
you guys take me too serious. it would be nice to have such infrastructure/toggle switch. the question is what can be done "automatically" (assuming you have source to everything) and to not write a program ^^^ mel dictates it must be an option
<kof123>
this only works if everything is c89, other lang should use other lang tools
<kof123>
i mean, other langs surely have similar things, or built-in
<kof123>
it is such a simple optimization, a generic tool for multiple langs would be feasible for someone into languages/parsing/etc.
<zid>
which number base is that
<heat>
you know I don't understand what you're talking about
<zid>
heat should stick to dark soul
<kof123>
its really no different than int foo(int a, int b). then changing a call foo(3, ...) to instead call: foo_3(int b) { int a = 3; ... } from what i understand that is the basics or perhaps the entire thing, just it can propagate through whatever you have source for. aka synthesis os lol
<epony>
^ great fun supporting these on your OS projects
<epony>
making sure your system operates correctly in the wrong way they require since 1991
bgs has joined #osdev
pg12 has quit [Ping timeout: 252 seconds]
pg12 has joined #osdev
bradd has quit [Ping timeout: 246 seconds]
demindiro has joined #osdev
joe9 has quit [Quit: Lost terminal]
craigo has joined #osdev
joe9 has joined #osdev
demindiro has quit [Quit: Client closed]
unimplemented has joined #osdev
janemba has quit [Ping timeout: 248 seconds]
janemba has joined #osdev
janemba has quit [Ping timeout: 248 seconds]
heat has quit [Ping timeout: 248 seconds]
janemba has joined #osdev
<dinkelhacker>
Yesterday I found out that qemu loads my dtb that will be overwritten by the initial clearing of the bss section. Is that a common problem one has to deal with?
<dinkelhacker>
>>to an address<<
<zid>
why did you let it do that
<dinkelhacker>
I mean I kinda have to? Doesn't that mean that the dtb unfortunately got loaded to a location where I actually have zero initialized data?
<zid>
do you have any control over where the dtb ends up? do you have any control about where your bss ends up?
<dinkelhacker>
no? I have no control about where the dtb ends up and I think I don't want to bc. it should always work, right? And the bss has to be at the end, doesn't it?
<zid>
well no you can put it literally anywhere
<zid>
but either the dtb is fixed, and you can move everything away from it
<zid>
or the dtb goes 'at the end' and qemu is misdetecting your 'end'
<zid>
is your bss a real bss, or a made up one where you just treat memory after your kernel as bss?
<dinkelhacker>
I mean can the loader know where the end is since the bss won't be in the image itself?
<zid>
it will be 'in the image' if it's an ELF
<zid>
idk what you end up giving to qemu to load
<mrvn>
dinkelhacker: is your kernel an elf file or raw image?
<dinkelhacker>
raw image... ok that is the problem
<mrvn>
bingo. no bss in raw images.
<dinkelhacker>
Hmm... soo how would a device like the pi do it? There I will have to provide a raw image.
<dinkelhacker>
Put it before the kernel?
<mrvn>
Now you have to parse the DTB to see how big it is and then copy it to after the .bss. And all that without stack.
<mrvn>
PI uses elf images
<zid>
or place the dtb first
<zid>
because it's just.. in the rom somewhere presumably
<mrvn>
I would just go with an elf image. qemu / multiboot will load that just fine.
<zid>
and either it's at a fixed addr in rom, or it's copying it to ram along with the kernel
<mrvn>
zid: DTB can't be in rom as it gets modified by the config.
<zid>
but either way, there's some "agreement" in place between how it loads both, given it's a physical device with real characteristics
<zid>
the people who made the original images (not the homebrew ones) knew what the bootloader was going to do
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
so could design it for it
<dinkelhacker>
mrvn: I've always just run the same raw image on the pi I am currently passing to qemu. What do you mean with elf images?
small_ has quit [Ping timeout: 252 seconds]
<zid>
pi has like, 18 stages of bootloaders and I have no idea what the differences are, and which one you're being loaded by
<zid>
there's like three binary blobs that the normal system uses, before it starts loading an elf
<mrvn>
dinkelhacker: sorry, PI uses a raw image. But I believe there the DTB is before the kernel.
<mrvn>
firmware loads at 0 and the kernel.img loads to 0x8000 or 0x80000.
<dinkelhacker>
Ok. That makes sense!
<dinkelhacker>
Thx
<mrvn>
But for qemu try just using the elf file that gcc outputs. Don't objcopy to binary.
<mrvn>
or use the raspi2/3 target in qemu.
<dinkelhacker>
will do! anyway I am generating both
<dinkelhacker>
I'm currently trying to make it work for the virt target
gildasio1 has quit [Ping timeout: 255 seconds]
<dinkelhacker>
Hm when I pass the elf file and attach with gdb i just have a bunch of `udf`s at the load address. Is there a trick?
<mrvn>
ahh, right. You may have to set the LMA for that to work for a higher half kernel.
<dinkelhacker>
I mean the phys addr is not where qemu will load the code but if I objcopy that is no problem
<mrvn>
set the virtual address to the actually physical address to test
<dinkelhacker>
it's not higher half?
<mrvn>
0x40_0008_0000 is pretty high. I'm guessing you don't have phyiscal ram there
<dinkelhacker>
what do you mean with LMA?
<mrvn>
load memory address
janemba has quit [Ping timeout: 252 seconds]
<mrvn>
basically the phyiscal address the bytes should be loaded too
<zid>
was it not you I went over this with recently
<zid>
deja vu
<dinkelhacker>
It was but that was when I was trying to link for big gaps and din't want the image to get large :)
k0valski18891 has quit [Quit: Peace out !]
xenos1984 has joined #osdev
<dinkelhacker>
Sine I am now only linking for virtual addresses I didn't bother about the LMA. And also wouldn't that mean that if you use elf images you would have to recompile for every target you want to run the kernel? The load addresses will be different on them?
<zid>
LMA and VMA and what your final image *should* look like were definitely went over
<zid>
normal machines always have the MMU enabled so LMA is basically ignored
<mrvn>
dinkelhacker: yes. but you have to do that anyway unless you design your pre MMU stage very carefully.
<dinkelhacker>
that is what I am trying to achieve
<zid>
If the loader cares, the loader cares
<zid>
and you have to make it right
<zid>
if it doesn't, it doesn't, and you don't
<zid>
the question is what situation are you in
<mrvn>
dinkelhacker: I would really recommend making a separate pre-mmu stage that maps the actual kernel into virtual memory.
<dinkelhacker>
mrvn I have that. I currently map the kernel from pic assembly right at the beginning.
<mrvn>
that stage should not map the DTB to where .bss is
<mrvn>
you also have to skip the initrd when you have one
<dinkelhacker>
Hmm.. yeah I mean you could just map the bss to somewhere completely different. But sound kinda complicated. If I fix the elf file it will probably just work with qemu. But I was hoping to get a set of generic images/elfs that will work independent of the target...
<zid>
well -kernel is a bit of a hack
<dinkelhacker>
I mean otherwise you could also just skip the whole dtb parsing if you anyway have to recompile
<mrvn>
if you really have a separate loader then qemu wouldn't see your kernel.elf, only your loader.
<zid>
if you want that, make an SD card image and emulate the actual bootloaders the pi uses etc
<zid>
and you can reuse the same binary no problem
<mrvn>
and the loader should be fully physicall and PIC
<mrvn>
zid: nope. you have to recompile for rpi 1/2/3 and rpi4.
<dinkelhacker>
Hm.. I'll have to think about that.
<mrvn>
0x8000 vs. 0x80000 load address
<dinkelhacker>
I mean you could just make the bss show up in the image, right?
janemba has joined #osdev
<mrvn>
dinkelhacker: if you like a ton of zeroes in your image
<mrvn>
but again: separate loader + kernel. problem solved.
<dinkelhacker>
you mean write your own loader who won't care about the LMA?
<mrvn>
yes
<dinkelhacker>
Hm.. wanted to avoid that.
<mrvn>
then you have to recompile for every load address
<dinkelhacker>
Like how does linux do it? they also don't recompile for different load addresses?
<mrvn>
I believe they do
<clever>
dinkelhacker: i believe the pre-mmu code in linux is fully PIC, hand written to not care where it was loaded, and the post-mmu code just uses the mmu to load it to the expected addr
<clever>
i have no idea how linux does ASLR
x8dcc has joined #osdev
gog has quit [Quit: Konversation terminated!]
<dinkelhacker>
clever: yeah but if they really whould have to correctly set the LMA for each load address they'd need to recompile a bunch right? Also is linux usually shipped as an elf or a raw binary?
<clever>
linux is generally shipped as a raw binary, with its own loader at offset 0 in the file
<dinkelhacker>
and that loader does what?
<mrvn>
loads the kernel with ASLR into virtual space
<dinkelhacker>
I mean that's not really loading anything? just setting up the mmu?
<mrvn>
yes
<dinkelhacker>
So since somehow they have to deal with the fact that the dtb could potentially be in the bss
<mrvn>
the bss is in virtual space, the dtb in physical
<clever>
but you need to take care to not map bss over the dtb
<mrvn>
yep. scan it to get the size right.
<clever>
but you can scan the dtb in the post-mmu code, without having a bss setup yet
<clever>
you only need a small-ish stack
<clever>
and then setup bss and everything else
<mrvn>
I would do it pre-mmu and without stack.
<mrvn>
You need to do it before setting up the page tables so you don't overwrite the DTB when writing those.
<clever>
yeah
<clever>
i would just search for the first /memory entry, and then exclude .text and dtb from it
<mrvn>
You only have to count the number of open and close tags to get the DTB size.
<dinkelhacker>
true... really fun doing that in asm^^. That sounds like a major pain.. why is there no rule like 'dtbs go before the kernel'
<clever>
and use the rest to get the mmu up
<mrvn>
dinkelhacker: because there is no memory before the kernel when the kernel is loaded at 0
<clever>
on rpi, the dtb and kernel are loaded to some fixed addr, creating a fairly large hole
<clever>
another trick you can do, just create a 10kb hole of nulls, inside your final kernel binary
<dinkelhacker>
mrvn: well then u just don't load to 0?
<clever>
then you know the pc-relative offset to that hole, and its "used" by your binary, so dtb cant be there
<mrvn>
dinkelhacker: that's the firmware doing it, not yours to controll
<dinkelhacker>
I know. That is what I'm saying the rule should be for firmware vendors >D
<mrvn>
The RPi actually starts executing at 0. That's where the SMP stub resides.
<clever>
the tricky part there, is that none of the arm setup has been done, and all 4 cores execute at 0 at once
<clever>
linux crashes if you skip some of that setup, and the entry-point isnt meant to run concurrently like that
<mrvn>
clever: is there a way to make the default firmware load your kernel.img at 0 and skip that part?
<clever>
yeah, just set kernel_old=1 in config.txt
<clever>
originally, thats what the firmware did
<mrvn>
for 64bit too?
<clever>
and you had to manually prepend a 0x8000 byte stub to the kernel
<clever>
i believe so
<clever>
just keep in mind, all of the stuff like allowing non-secure access to the L2 cache, turning SMP on, setting the timer freq, are skipped
<clever>
and you wind up in secure-monitor/EL3
<mrvn>
hmm, wait. How does that even work in 64bit mode? Does it then start everything in hypervisor mode?
<clever>
it starts in EL3, one level above the hypervisor
<mrvn>
nice
xenos1984 has quit [Ping timeout: 248 seconds]
<clever>
mrvn: on pi2, there is a bit in ACTLR, that enables smp support
<clever>
without that the L1 coherency is disabled, and the load/store exclusive opcodes just jump to the undefined opcode vector
<clever>
i wasnt aware of that at first, and my linux was built with SMP support, so it tried to grab a mutex in printk()
<clever>
and it tries to print before it sets up the exception vectors
<clever>
so attempting to print anything, causes it to just jump to undefined code
<clever>
building linux without SMP support is one fix, then it can get locks by just turning irq's off, and can skip the faulting opcodes
<clever>
mrvn: by complete random chance, that same bit in ACTLR on the pi3, is instead used to allow non-secure mode to flush the L2 cache
<clever>
and if you dont set that, then linux rapidly goes non-coherent, and segfaults like mad once it starts to multi-task
<mrvn>
the pi2 was pretty hacked together to allow SMP.
<clever>
yeah, but that SMP enable bit, is an officialy documented bit, in the arm docs
<clever>
so its less of something rpi did, and more what arm allowed
<clever>
there it is, cortex-a7, ACTLR, bit 6, SMP
xenos1984 has joined #osdev
<geist>
to be clear the ACTLR bits are core specific, that's why it's in the A version of the CTLR
<geist>
later armv8 standardized SMP as just being there, so no v8 cores require that
<geist>
and only the v7 cores that had SMP support had something ike that bit
<geist>
ie cortex-a7, a9, etc
<clever>
yep
<clever>
thats part of the armstub's job, to deal with all of those core-specific things
<geist>
yah. in general over time i think most of the modern v8 cores dont really use ACTLR for anything but chicken bits, if that
<mjg>
do you know what i love abut arm? nothing
[itchyjunk] has joined #osdev
<geist>
that's a shame
smeso has quit [Quit: smeso]
<mjg>
:]
<mjg>
i'm just venting, not specifically arm's fault
<sham1>
It costs an ARM and a LEG
mctpyt has joined #osdev
dude12312414 has joined #osdev
smeso has joined #osdev
mctpyt has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Ping timeout: 248 seconds]
<mrvn>
Anyone watched The Arc yet? Notice how they have rotational gravity except in storage bay 3 they magically have gravity some other way?
xenos1984 has joined #osdev
<geist>
oh The Ark? dunno never heard of it until now
<mjg>
imdb url
<geist>
in general i give shows a pass for pretending that there's artificial gravity somehow
<geist>
sicne it otherwise is a pain to film
<mjg>
to my undestanding expanse did a good job there
<mjg>
or at least physicists claim that
<geist>
it's possible it was also plot critical, etc
<geist>
but yeah you can say 'the people wear magnetic shoes' in which case then someone will just complain that their bodies dont flop around oddly
<mjg>
the ark is 3.5 on imdb, i'm gonna pass
<geist>
but yeah in the case of expanse it also had to deal with strapping in because you're going on a 2g burn for an hour, etc. so you can't ignore gravity or lack of in that case
<mjg>
ye i love that in the expanse the space is a charactre of its own
<geist>
yah
<mjg>
no travel through a wormhole or warp speed or whatever teh fuck
<mjg>
rendering distance meaningless
<mjg>
you even get communication lag talking to the belt 'n shit
<mjg>
A+
<geist>
and iirc not really hitting you over the head about it, just it being a thing
<mjg>
ye
<mjg>
fact of life
<mjg>
they never explained if this is all written in RUST though
<mrvn>
geist: They are building a farm in there and the dirt isn't floating around. So no magnetic boots.
<mrvn>
And if the show has artifical gravity then why rotate the living spaces?
<GeDaMo>
Obviously it's magnetic dirt :P
<mjg>
it is artificial dirt!
<geist>
yep, makes sense
<mrvn>
The timeline also didn't make sense right up till the preview of future episodes, and kind of still doesn't. They are 4 years into a 5 year trip to centauri, so >85% the speed of light. right. But apparently they have FTL. So why does it take 5 years?
<mjg>
maybe it is not much faster? :]
<mjg>
BFTL, as in Barely
<GeDaMo>
Acceleration time?
<geist>
it's a pretty standard 'show first, science later' sort of thing
<geist>
invent enough magic tech to make sure it's filmable and relatively cheap to make
<mrvn>
GeDaMo: If they manage to activate FTL inside one episode then it can't take long to accelerate.
<geist>
just have to build some sets and then have a bunch of actors act out being petty assholes to each other
<geist>
may be a fairly standard sci fi trope: FTL really means 'accelerates you to near c very quickly'
<geist>
and yes i know, F is not faster than in that case
<mrvn>
Obviously, that's why they have only a minimum of weightless scenes. Too expensive.
<geist>
ATL
<mrvn>
Never seen that. FTL is always >c
<geist>
i've seen it from time to time, when some sci fi writer wants things to still take a lot of time, but otherwise not be instant
<geist>
like, i dunno, i think the Ender stuff has a drive like that
<geist>
still takes 30 years or so to get somewhere, but that's better than taking a million
<mrvn>
I've seen writers ignore time dilation and other relativistic effects. but if they call it FTL it's Faster that light.
<mjg>
stargate dudez would fly to the pegasus galaxy in 2 weeks
<mrvn>
SG has Hyperspace.
<mjg>
oh right, that's even better
<geist>
yah the ender stuff was more like 'it took you 2 weeks on the ship but it took you 30 years in real time' because the drive accellerates you almost instantly to .9c or so
* mjg
haas not seen the show in quite some time
<mrvn>
Ender has light speed. Totaly einsteinian physics.
<mrvn>
(except for the acceleration I guess)
<geist>
yep, but thats my point it may be kinda what this show you're talking about is doing
<geist>
though i guess they're ignoring relativistic time
<GeDaMo>
There's a book called Tau Zero where they can't go FTL but can get ever closer by continually accelerating
<zid>
There's a novel that's about a guy's struggle to adapt to life back on earth having gone to war via time dilation
<zid>
gender's all fluidy etc
<zid>
he ends up just going back and getting to the end of humanity instead :P
<mrvn>
The visual effect looked more like a warp bubble, albercurcy drive thing. Have to wait and see how they explain it.
<zid>
back to war*
<GeDaMo>
The Forever War?
<zid>
that's the one thanks
<GeDaMo>
I haven't read it but I've read about it :P
<zid>
There's also erm, man wakes up and goes to galactic core and back in a huge hydrogen ramscoop ship as a sort of prisoner, gets back and earth has melted
<zid>
has to navigate pheonix arizona but actually norway or whatever
<zid>
and battle weird indigenous children
<mrvn>
Near the end of the episode one sees star through a window going by really fast. Fun thing too. They are going to the closest star bypassing several others?
<mrvn>
zid: old story but good.
craigo has quit [Ping timeout: 252 seconds]
heat has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat>
hai
<mrvn>
Tau Zero costs 46EUR as paperback, used. Why don't they have those old books as print-on-demand from amazon?
<GeDaMo>
Yeah, I was just looking at another book, £67 as a paperback :/
<mrvn>
Oh, it's also available as "Tau Zero (S.F. MASTERWORKS Book 33) (English Edition)", 9.99EUR paperback
<GeDaMo>
Most likely the expensive used version is someone thinking they're going to make a killing
<mrvn>
it's a rare book because it's no longer printed. My question is more: Why isn't it printed anymore? Has amazon stopped their print-on-demand service or are the terms so unfavourable that there is no money in it?
<mrvn>
There is a kindle version so they have the book digitally. Why isn't the publishing company throwing all their old books that are out of print at amazon as print-on-demand?
<bslsk05>
'What was the most expensive book ever?' by Stand-up Maths (00:17:53)
<GeDaMo>
I think I remember reading about this
<mrvn>
Offering a book on amazon just a bit higher than the next cheaper so you can buy the second offer and resell it is kind of evil.
<GeDaMo>
"Make me some paperclips" :P
<zid>
Click here to turn this message into trace amounts of paperclips.
gorgonical has joined #osdev
<gorgonical>
I have figured out that I can use screen to feed my forth code directly over the serial port
<gorgonical>
Now I need to construct some kind of test suite so that I can actually suss out bugs
<mrvn>
quite a few people prefer that over minicom
<gorgonical>
while I prefer tmux for actual terminal muxing screen works very well as a serial port application
torresjrjr has quit [Ping timeout: 252 seconds]
<klys>
how does the screen command look?
torresjrjr has joined #osdev
<gorgonical>
Basically all I have to do is C-a : readbuf and then I can paste it into the serial output with C-a ]
<gorgonical>
At this point my forth has some limitations like requiring lines to end with a space, but otherwise I can just have a file called "source.f" with all the defines on separate lines and this way I can shove them all in
clever has quit [Ping timeout: 248 seconds]
clever has joined #osdev
<mrvn>
gorgonical: have computed Pi, e and drawn a Mandebrot fractal?
<mrvn>
+you
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
fedorafan has quit [Ping timeout: 256 seconds]
fedorafan has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
elastic_dog has quit [Ping timeout: 248 seconds]
<heat>
PaidBSD
elastic_dog has joined #osdev
<Ermine>
Sounds lucrative for some reason
<mrvn>
sounds expensive
<heat>
oh, no, not at all
<heat>
it's a new program where they pay you to use BSD
<Ermine>
negatively expense
<Ermine>
er, expensive
<heat>
the hard part is finding willing participants
<mrvn>
does it pay more than the power to keep the system on?
<heat>
"Do you like linux and want to struggle even more to do really basic things? Are you not a fan of antelopes? Do you enjoy the devil? Use BSD!"
<epony>
s/ like / leak /g
<Ermine>
heat: you won all satanists in your area
<epony>
we call these Stallmanists
<Ermine>
hm?
<mrvn>
Why are you using BSD? -- The devil made me do it.
<heat>
it is the only actual reason to do so
gog has joined #osdev
<heat>
geist, from our good old libfdt: #define EXTRACT_BYTE(x, n) ((unsigned long long) ((uint8_t *) &x)[n])
<Ermine>
hi gog
<mrvn>
uint8_t? How modern
<geist>
noice
<mrvn>
What is the (unsigned long long) supposed to do?
<heat>
this should be replaced
<heat>
nothing. it's a helper for endian reversing
<heat>
this is a blatant aliasing violation
<heat>
for little reason
<epony>
you know Linux is not an OS..
<mrvn>
Ahh, so you can do EXTRACT_BYTE(x, n) << 56; without it overflowing
<heat>
ye
<mrvn>
heat: no. uint8_t aliases just like char iirc
<epony>
it's an experimental kernel mostly full of drivers and failure to apply 1 tool, but has 5 variants that don't mix and match and each is uniquely incomplete
<epony>
Linux can't do file systems
<epony>
and it's really fucked up on graphics
<Ermine>
Yet I'm trying to debug a file system on BSD system, not in Linux
<epony>
what's there to debug?
<heat>
hmm
<epony>
UFS/FFS works for 40 years
<mrvn>
heat: I believe that is actually the best way to extract bytes
<heat>
Ermine, hi what's wrong and how did zfs fuck you
<Ermine>
something that's not working
<epony>
you
<geist>
heat: i guess it is, but i've seen far worse to be honest
<geist>
i'd prefer it be a const pointer if nothing else
<Ermine>
heat: not zfs
<mrvn>
heat: The only thing wrong with the above is the "#define"
<heat>
hmmm const-correct geist eh
<heat>
it's rubbing off on you
<epony>
zfs has nothing to do with BSD
<geist>
heh yeah. i mean inside a macro like that where the scope doesn't go anywhere it doesn' matter
<mrvn>
Does it give a warning when you pass it a const pointer?
<geist>
C++ might, i doubt C does
<gog>
hi
<heat>
i saw a talk by the cppweekly guy that said raw loops are a code smell
<epony>
debug it on Linux where it's being developed after it was thrown out the fence by Sun defunded ex-employees
<Ermine>
On linux, it works.
<heat>
gog gog gog gog ogg
<mrvn>
heat: clickbait
<gog>
gog.ogg
<epony>
yeah, it's made for Linux, and Linux specific
<heat>
ogg.ggo
<Ermine>
But it works
<epony>
like SysD
<heat>
have you noticed gog reversed is gog
<epony>
the shit it works
<heat>
mrvn, nope, was in the middle of the talk too
<heat>
actual cppcon thing
<Ermine>
I don't need to debug it
<epony>
yes, use it where it works
<Ermine>
I do
<epony>
it's not a BSD problem, it's a ZFS problem
<heat>
I assume he wants you to use std::accumulate and shit
<Ermine>
I'm not talking about ZFS
<epony>
Linux is a non-standard pseudo-UNIX
<heat>
Ermine, hi what fs are you talking about and why is it zfs
<mrvn>
heat: pretty sure he was talking about loops that should use ranges though.
<heat>
even if it's not
<epony>
it originally had a failed MINIX FS clone
<heat>
>ranges
<heat>
even worse!
<epony>
was called ext
<epony>
later it was rewritten to be more like the BSD FFS and was renamed to ext2
<Ermine>
heat: actually I felt like hacking minix and i want ext2 to work there
<epony>
so, Linux learns, slowly and with pains
<epony>
in ext3 Linux adds journalling
<heat>
wait huh
<heat>
so is this minix or ext2?
<heat>
s/ext2/bsd/
<epony>
that is not supported outside Linux, but FreeBSD got journalling added to their UFS/FFS
<Ermine>
heat: I didn't figure out yet where the issue is
<epony>
so the advantage of using ext3 is not tehre
<heat>
but is this minix?
<epony>
meaning BSD already had that before Linux
<epony>
same as SMP unlocking
<Ermine>
heat: technically minix is bsd, because it adopted netbsd userspace
<epony>
before Linux
<epony>
ZFS was also hosted briefly in FreeBSD and bailed out
<heat>
but it's the minix kernel
<epony>
it's after the Linux enterprise hype
<heat>
so it's minix
<epony>
there is also ext4, and xfs and btrfs
<epony>
and now zfs
<mrvn>
heat: When you can use straight up std::accumulate and shit it's real great. Much more readable and less to type than writing your own loop. But not if you have to shoot yourself in the heat through your knee to get there.
<epony>
so 4 choices to.. not get a working one main version
<Ermine>
zfs came from solaris, my wikipedia lover
<epony>
and Solaris is what?
<heat>
little known fact: zfs came from zed, the league of legends champion
<mrvn>
heat: range for [ for (auto x : v) ] stuff is great too
<epony>
but the droppings of a couple of Sun fired ex-employees
<samis>
coherence is unusual for epony anyways
<epony>
you have no idea
<Ermine>
heat: :D
<epony>
must read a book someday, but not the books of failed ZFS porting
<epony>
read a book on BSd
<epony>
might discover what Linux will be doing in the near future
<epony>
like losing pseudo file systems etc
<Ermine>
I know it without a book. It will be working actually.
<epony>
so you're claiming it works, but gets a new version weekly..
<epony>
that looks like perpetual not working
<heat>
Ermine, anyway did you write the ext2 driver or is it included with minix?
<Ermine>
heat: it is included with minix
<heat>
:(
<heat>
why does no one do the osdev here
<Ermine>
?
<heat>
write drivers, write kernel code
<heat>
enjoy writing the unix yourself
<epony>
and disver standards after that..
<epony>
when you've written 20 years of it
<epony>
we'll call you GNU
<heat>
sorry, got hit with a cease-and-desist from SCO. Enjoy writing the UNIX(-like) yourself
<heat>
UNIX(tm)
<Ermine>
heat: Actually there may be some kernel issue. Somewhy it fails to get physical address for a given virtual
<epony>
Moonix/LINIX
<Ermine>
heat: or Unix? I've heard there's a difference between Unix and UNIX
<heat>
the trademark is probably UNIX
<epony>
yeah, it's like between MINIX and NetBSD
<heat>
and IANAL so I dunno if Unix isn't covered too
<epony>
MINIX has no relation to UNIX
<Ermine>
Also I speak Unix with normal tone and scream UNIX
<heat>
if you do not scream when reading UNIX that's on you
<heat>
likewise, bread()
<epony>
Linux has none relation ot UNIX too, but it has relation to MINIX only it did not do a micro-but-a-mono kernel
<epony>
the system interfaces in Linux are non-standard and not from UNIX, but from MINIX and look like a Windows hybrid
<Ermine>
for example?
<epony>
it's non portable and non standard
<epony>
for example system calls
<Ermine>
which linux system call is from minix?
wootehfoot has joined #osdev
<epony>
which isn't?
<Ermine>
I asked you to provide a single example of linux syscall which came from linux
<mrvn>
Ermine: eventfd
<heat>
>linux syscall which came from linux
<heat>
all of them
<Ermine>
lol
<Ermine>
from minix, actually
<mrvn>
lseek64?
<epony>
it's you who reads the LPI book, so you provide your examples
<Ermine>
So you fail to prove your point?
<epony>
which point? that Linux has no relation to UNIX
<epony>
you have to be absurd to claim the opposite
<Ermine>
"the system interfaces in Linux are non-standard and not from UNIX, but from MINIX..."
<heat>
Ermine, actual answer: none
<heat>
the OG i386 syscalls were ""stolen"" from sysv
<heat>
like they were on most/all the traditional UNIX-and-UNIX-likes
<epony>
minus the file system
<Ermine>
heat: you're goddamn right
xenos1984 has quit [Read error: Connection reset by peer]
<heat>
SVR4 was the best operating system ever and this is a fact
<epony>
did that have the runlevels or not?
<Ermine>
If svr4 is so good where are its X11 floppies
<epony>
(have to trip on stairs frequently to claim that)
<Ermine>
heat: also no tcp/ip stack floppies
<epony>
can't find my SysV runlevels, tripped into SysD ladder of faults
<heat>
i do have a unixware iso with motif
<heat>
unixware 1
<epony>
was that the novell crapware?
<Ermine>
noise
<epony>
the one that disappeared
bgs has quit [Remote host closed the connection]
<samis>
novell had their own crapware
<heat>
samis, unixware is also novell
<samis>
isn't it more SCO than novell?
<epony>
the NT NOVELL or the NetBEUI/NetBIOS and IPX me harder mr.POSIXman
<epony>
"can I have some applicatiosn too" --MINIX's Tanenbaum at BSD conferences pleading for help getting the FreeBSD ports tree which he gave up on and moved to plead about the NetBSD's pkgsrc ports tree.. apparently Linux is full of portage shitware which does not work