|
in this instance a funny exchange between two people who have done actually interesting things (ebpf to me remains the most interesting development in linux in the last 15 years, i think the potential is largely underrated)
|
# ? Apr 22, 2024 20:13 |
|
|
# ? May 4, 2024 11:50 |
|
I never understood that response. That description of Linux performance tricks is pretty straightforward. Nothing that is mentioned is particularly arcane or would take long to debug, except maybe the trick about using multiple page sizes concurrently. Should leave plenty of time for kissing.
|
# ? Apr 22, 2024 23:22 |
|
he does come across a little dickish when he's describing anything that's not linux or gcc as broken poo poo on the, ahh, comp.sys.sun.hardware newsgroup presumably both of these nerds have chilled out a bit since their early 20's
|
# ? Apr 23, 2024 01:05 |
|
that description of the sparc linux optimization under Linux is really fascinating, to be honest
|
# ? Apr 23, 2024 02:44 |
|
Athas posted:I never understood that response. he's calling him a huge nerd sb hermit posted:that description of the sparc linux optimization under Linux is really fascinating, to be honest it is, and it's well written, it's just an extremely nerdy thing to be interested in
|
# ? Apr 23, 2024 03:39 |
|
like, if they were in college then yeah maybe 20s, maybe late teens. you don't remember trolling message boards or usenet (depending on your age group) at that age? i sure as poo poo do lol an appropriate response would have been like, "why, do you want to know what it's like?" or something idk. shame if it just dropped, that's not what usenet was for
|
# ? Apr 23, 2024 03:41 |
|
well i mean cantrill infamously signed that post with his sun.com email address, that's what makes it so funny, he was posting at work. miller was at rutgers at the time so this is interesting as well, looks like they did a USENIX presentation based on the usenet post: https://www.usenix.org/legacy/publications/library/proceedings/ana97/summaries/miller_invite.html quote:Questions/Answers. This was, arguably, the most fun part of this talk. David came up with a number of questions that "opponents" of SPARCLinux typically throw at him, and then he responded to them. One of the questions he posted dealt with having a single kernel to support all of the various SPARC architectures (as opposed to the way that SunSoft has different kernel architectures requiring different kernels and different compiled routines). David's response: "Oh Really? Ask the users if they want to remember the difference [moving a kernel to a new architecture is not as simple as an rcp]. Besides, it is still faster than Solaris!" lol also lol that whoever wrote the summary for USENIX was scandalized at the idea of a kernel that requires a specific C compiler optimization instead of being written in pure portable ANSI Standard C
|
# ? Apr 23, 2024 06:08 |
|
shackleford posted:presumably both of these nerds have chilled out a bit since their early 20's I have it on good authority that Cantrill is pretty lovely and that response is just the tip of the iceberg can’t say more (not my story to tell) but regardless of his technical chops, he’s persona non grata to some folks I know and trust
|
# ? Apr 23, 2024 06:58 |
|
keep in mind that davem was 22 and bryan cantrill was 23 so there's a decent change the answer was "no" for both of them and also that bryan was genuinely curious
|
# ? Apr 23, 2024 06:58 |
|
Beeftweeter posted:he's calling him a huge nerd They were both kernel programmers, so they were both nerds. One of them was just better at his job. I remember reading that post when I was new to Linux, and not really understanding the technical details. I now understand them all and even think it's a very nice piece of technical writing. This is called personal growth.
|
# ? Apr 23, 2024 08:49 |
|
Athas posted:They were both kernel programmers, so they were both nerds. One of them was just better at his job. i presume you mean cantrill was better at his job? because while the thread is real impressed with the post it is linux 1.3, which is a point where even terming anything about it a "job" is kind of ridiculous. a lot of the tech argument also boils down to "look at all this historical cruft, my 4 year old kernel has *no bullshit*!" i can easily imagine it doing one tiny benchmark or another well, but, like, that era of linux basically bears no relation to the e.g. 2.2-2.4 era when it started being a legitimately deployable thing
|
# ? Apr 23, 2024 09:05 |
|
but now with a ton of baggage, linux is still faster, yeah?
|
# ? Apr 23, 2024 09:52 |
|
ryanrs posted:but now with a ton of baggage, linux is still faster, yeah? pretty sure linux 6.8 would be crushed by linux 1.3 on a sun4m box in these micro-measurements. otoh linux 6.8 would likely also be crushed by e.g. contiki if you're going to get into fitting featureless network stacks into caches and counting cycles in schedulers that basically blindly fifo. (but, i mean, point is not that solaris was so great and should have stuck around, just that the read of that argument as miller and linux 1.3 dunking on sun with all the 50 instructions saved on critical op exit() is a bit dubious) Cybernetic Vermin fucked around with this message at 11:03 on Apr 23, 2024 |
# ? Apr 23, 2024 10:23 |
|
makes sense now that NetBSD 8 was within 10% of SunOS 4.1.4 performance on a SPARCstation 2 though, that’s a hell of a lot of overhead I wonder if it’s some sort of artifact of how the Sun-3 MMU worked that they preserved in SPARC to make porting easier unlike HP and Tektronix but like Apollo, Sun didn’t use the 68851 in their 68020 systems, they used a discrete MMU of their own design descended from the Sun-2 MMU; I should compare SunOS 4.1.1U1 and NetBSD 10 performance on my Sun-3/60 and Sun-3/80 and see how they fare
|
# ? Apr 23, 2024 10:31 |
|
ryanrs posted:but now with a ton of baggage, linux is still faster, yeah? than sunOS? considering the hardware that supports, probably
|
# ? Apr 23, 2024 19:42 |
|
Athas posted:They were both kernel programmers, so they were both nerds. One of them was just better at his job. yeah, but it's a personal dig. presumably cantrill was trolling, but eschaton posted:I have it on good authority that Cantrill is pretty lovely and that response is just the tip of the iceberg apparently some people just don't grow
|
# ? Apr 23, 2024 19:43 |
|
Fedora 40 is out. Time to upgrade HBag!
|
# ? Apr 23, 2024 22:04 |
|
hbag is fine as is they dont need to be upgraded
|
# ? Apr 23, 2024 22:04 |
|
I’m using kubuntu
|
# ? Apr 23, 2024 22:04 |
|
Athas posted:They were both kernel programmers, so they were both nerds. One of them was just better at his job. Sorry now you're bragging
|
# ? Apr 23, 2024 22:38 |
|
FlapYoJacks posted:Fedora 40 is out. Time to upgrade HBag! fedora 40 is pretty solid. I like KDE 6 quite a bit. the hdr support is nice too
|
# ? Apr 23, 2024 22:55 |
|
Silver Alicorn posted:I’m using kubuntu same
|
# ? Apr 23, 2024 23:02 |
|
I am waiting for Bazzite to update to Fedora 40
|
# ? Apr 24, 2024 02:56 |
|
I switched to F40 a few days after plasma 6 was merged in and it’s been very needs suiting.
|
# ? Apr 24, 2024 03:48 |
|
code:
|
# ? Apr 24, 2024 04:22 |
|
ryanrs posted:
this reminds me of when I tried to build world on a 486 in 2001 or so and it took a week
|
# ? Apr 24, 2024 04:28 |
|
anyways, any arm machine that doesn’t have like a superscalar architecture (like the apple m1 and successors, or other similarly powerful processors) will be absolute rear end in compilation by the way
|
# ? Apr 24, 2024 04:30 |
|
ryanrs posted:
make menuconfig -> developer options -> enable ccache. It won’t speed up initial builds but subsequent builds will be faster.
|
# ? Apr 24, 2024 04:31 |
|
this is why when I usually develop code on my pi400, I either make small binaries or I use a scripting language like python, keeps the momentum going
|
# ? Apr 24, 2024 04:31 |
|
sb hermit posted:this is why when I usually develop code on my pi400, I either make small binaries or I use a scripting language like python, keeps the momentum going That’s a build log for openwrt which builds an entire embedded Linux file system.
|
# ? Apr 24, 2024 04:34 |
|
Yeah I can't unfuck this SoC's USB phy in python.
|
# ? Apr 24, 2024 04:36 |
|
FlapYoJacks posted:That’s a build log for openwrt which builds an entire embedded Linux file system. My response was actually to respond to what I wrote before: sb hermit posted:anyways, any arm machine that doesn’t have like a superscalar architecture (like the apple m1 and successors, or other similarly powerful processors) will be absolute rear end in compilation by the way
|
# ? Apr 24, 2024 04:37 |
|
ryanrs posted:Yeah I can't unfuck this SoC's USB phy in python.
|
# ? Apr 24, 2024 04:38 |
|
“Please re-run make with -j1” On the one hand, I can’t blame them, but on the other hand,
|
# ? Apr 24, 2024 04:39 |
|
sb hermit posted:“Please re-run make with -j1” “make -j$(nproc) V=sc” works fine.
|
# ? Apr 24, 2024 04:41 |
|
FlapYoJacks posted:“make -j$(nproc) V=sc” works fine. I mean, I’m sure it does, but also I think it is a catch-all of “some of these jobs are not comfortable with being run simultaneously or we haven’t gotten around to addressing some dependency issues just yet” kind of deal that I saw a lot in my older embedded linux builds (like from 20 years ago) that didn’t like the idea of modern processors having more than one core. We have certainly advanced a good deal since then, but every once in awhile there’s a concurrency issue that rears its head. And it’s those issues that are some of the hardest to figure out, particularly if it’s in code that’s not your own.
|
# ? Apr 24, 2024 04:49 |
|
code:
running make -j7 again
|
# ? Apr 24, 2024 04:50 |
|
Nah, it’s because running j1 makes the logs easier to parse as everything is sequential.
|
# ? Apr 24, 2024 04:51 |
|
ryanrs posted:
huh, I’m pretty sure I submitted a patch for that and it was merged upstream on the master branch.
|
# ? Apr 24, 2024 04:51 |
|
|
# ? May 4, 2024 11:50 |
|
ryanrs posted:
|
# ? Apr 24, 2024 04:54 |