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, 4 January 2023

00:22:00 <vdamewood> epony: Not true. I went to a four-year college.
00:22:00 <vdamewood> And my college did offer a post-graduate program.
00:32:00 <kaichiuchi> something I do want to stress
00:32:00 <kaichiuchi> i am not at all saying that all college people are morons, because if I don't say that it gets me into trouble
00:32:00 <kaichiuchi> my point is the degree doesn't prove much of anything to me
00:38:00 <kof123> unity of opposites, moron-ness is possible everywhere, the possibilities are infinite .
00:38:00 * kof123 nite all zzzzzzzzzzzzzzzz
00:41:00 * kof123 points to pinky and brain as evidence, or mice and men, or ...
00:45:00 <heat>
00:46:00 <heat> riscv64 build running third party packages
00:46:00 <heat> plus G N U n a n o
00:48:00 <jimbzy> I read that as G U A no. XD
00:53:00 <zid> everything is running on a temporary filesystem and YOU
01:52:00 <epony> vdamewood, in some parts of the world, college is a secondary education form (pun intended too)
02:19:00 <klange> heat: oh nice
02:34:00 <kaichiuchi> heat: hexchat >:(
04:22:00 <heat> klange, thanks :) yeah it's pretty neat, even though its just TCG
04:22:00 <heat> i've been seriously thinking in getting an rpi400 and starting work on that
05:55:00 <klange> Hm, my baked Deja Vu Sans Mono is a perfectly suitable VGA text mode font...
05:56:00 <zid> looks a bit wimpy
05:56:00 <zid> needs a bit more heft for my liking
06:00:00 <moon-child> is that not antialiased?
06:01:00 <moon-child> hard to tell because of my browser's rendering but it appears not to be antialiased :\
06:01:00 <kazinsal> considering it's being rendered by the VGA character generator, it would not be anti-aliased
06:01:00 <klange> Well it's a baked bitmap of Deja Vu, so yes, it's not anti-aliased.
06:03:00 <klange> I use it for kernel debug output, it's an option in the terminal (though with caching, the truetype rasterizer is just as fast now), and it was in a suitable format to throw at VGA so I did that just to see how it looks, and it looks fine!
06:03:00 <klange> You can compare my boot menu:
06:04:00 <klange> With the graphical version using the same font but a smaller width:
06:04:00 * moon-child dunno vga
06:04:00 <moon-child> for bitmap fonts, I like proggy
06:04:00 <zid> fixedsys is life
06:04:00 <moon-child> wer computer modern typewriter
06:05:00 <klange> I baked deja vu for consistency with my GUI that uses the normal truetype (and formerly SDF, and formerly truetype again) version everywhere.
06:06:00 <klange> I was previously using a larger font for a while (visible here:
06:06:00 <moon-child> make an efi bootloader, and render the aa version with gop :)
06:06:00 <klange> And a long time ago I had this one:
06:07:00 <klange> I could port my truetype rasterizer to the bootloader and use it in the video modes (the BIOS loader also supports video mode and defaults to it, but can be toggled to text mode if the video isn't working right)
06:07:00 <moon-child> I mean, don't have to rasterise at boot--lots to go wrong there--just bake an aa version
06:08:00 <klange> but that's so boring (and I'm not going to do it because here I'm using the same representation for both the graphical text rendering and what I throw at VGA text mode, which is neat)
06:09:00 <zid> I use a pirated copy of that gnu font in reality, not fixedsys
06:09:00 <klange> unifont?
06:09:00 <zid> that's the one
06:09:00 <kazinsal> pirated?! rms is having a sad : (
08:33:00 <epony> when people type truetype and typewriter, I always read teletype
08:41:00 <klange> a modern terminal emulator is just a truetype teletypewriter
08:41:00 <kazinsal> teletruetypewriter
08:42:00 <kazinsal> ttty(4)
08:43:00 <epony> don't know what you're doing to your fonts, but.. it's pretty easy to get crisp and readable fonts in X ;-) it was working on 8bit and 16bit computers pre-hires graphics too
08:44:00 <epony> things seem to go wrong when people get "moved" to higher resolutions and implementations get mixed up with that "handling"
08:44:00 <klange> truetype was originally designed purely for aliased monochrome rendering!
08:46:00 <epony> it's a pretty dramatic to get the overhead of vector fonts and get these wrong with anti-aliasing at the same resulting in worse performance and visuals than bitmap / raster fonts ;-)
08:48:00 <epony> text that moves when you scroll and redraws pixels with artefacts and changes the shape of symbols and characters on movement and selection → classic misery of overdesigns gone awful (gnome's rendering libs are horrible)
08:49:00 <epony> dejavu seems a nice font family indeed, I'm using these too
08:49:00 <klange> TrueType and other vector font formats were designed for scaling, because having a two dozen versions of every bitmap font you want to display is infeasible
08:51:00 <epony> but redrawing in terminals like XTerm is faster with raster fonts (the defaults in X are pretty decent)
08:52:00 <epony> and rasterisation of vector fonts is not that bad overal, can result in significant improvements in performance and consistent layout / correct rendering
08:53:00 <epony> what's bad is smudging and smearing of contours and moving shapes that leave artefacts and bad visuals in general from redrawing failures
08:53:00 <moon-child> hmmm. It all originates in postscript, right? I guess printers have variable resolution too, heh
08:53:00 <epony> postscript is a language
08:53:00 <kazinsal> it was apple's competitor to postscript's Type 1 system
08:55:00 <kazinsal> they originally were using it as a way to negotiate a slick deal on postscript in their printers and ended up accidentally just inventing a better vector font format
08:56:00 <epony> I used this one instead
08:56:00 <bslsk05> ​ Printer Command Language - Wikipedia
08:56:00 <klange> all the bonkers hinting stuff in truetype was purely to get downscaled glyphs to still spit out pixels, and a lot of modern text rendering "improvement" is "just stop doing the hinting
08:56:00 <kazinsal> tl;dr Microsoft had a postscript-compatible PDL that they licensed to Apple in exchange for a TrueType license, and then Adobe went "oh no" and renegotiated its PostScript license with Apple as well as licensing TrueType for all their printer boards
08:58:00 <epony> hinting was in the starting years of the LCD epoch ;-)
08:58:00 <epony> such fun
08:59:00 <CosmicBitch> what is this "hinting"
08:59:00 <kazinsal> OpenType came from Apple coming up with an enhanced version of TrueType that only worked with QuickDraw GX and Microsoft going "well, I guess we'll come up with our own variant" and it being good enough for both Apple and Adobe to go "might as well join 'em" and leaving both TTGX and Type 1 to rot
08:59:00 <klange> Hinting is aligning vertices in glyphs to grid coordinates, so that they produce full pixels.
08:59:00 <epony>
08:59:00 <bslsk05> ​ Subpixel rendering - Wikipedia
08:59:00 <klange> It has nothing to do with subpixel rendering.
09:00:00 <epony> it has
09:00:00 <klange> It does not.
09:00:00 <epony> since hinting is used to improve legibility
09:00:00 <klange> That's a side effect.
09:01:00 <epony> on fonts that don't align to the pixels it improves the alignment to pixels
09:01:00 <klange> That is true, but it has nothing to do with why hinting was developed.
09:02:00 <epony> "At low screen resolutions, hinting is critical for producing clear, legible text. It can be accompanied by antialiasing and (on liquid crystal displays) subpixel rendering for further clarity."
09:02:00 <bslsk05> ​ Font hinting - Wikipedia
09:03:00 <klange> Yes, but hinting was developed before any sort of antialiasing was happening with text.
09:03:00 <epony> when using vector fonts at 90-120 ppi, that's low resolution for smaller font sizes
09:04:00 <epony> maybe the Apple side of these technical details always had a different view on the implementation and terminology for aesthetics and rendering detail
09:05:00 <klange> TrueType makes no specifications about antialiasing, it was all designed around monochromatic aliased rasterization, and the spec says that if the middle point of a pixel isn't within a glyph the pixel isn't drawn, which means without hinting you can easily lose entire lines because they were just a bit off at a smaller size.
09:05:00 <klange> Hinting pushes things around specifically to avoid that problem - and is a complicated mess of a bytecode format to allow very detailed control over the process.
09:06:00 <klange> It's an added bonus that this process also produces more legible rendering with antialiasing and avoids fuzz, but it wasn't designed for it.
09:07:00 <klange> It also helps with non-subpixel antialiasing just as much - fuzz is a bit less noticable without the colorfringing of subpixel rendering, but still there especially when you start getting differeing misalignments between different glyphs.
09:09:00 <epony> so, in graphical applications with vector fonts you benefit from antialiasing and hinting added on top of subpixel rendering on smaller resolutions, in textual applications raster fonts make much more sense and produce fast and legible results but less granular font scaling
09:09:00 <klange> I dislike subpixel antialiasing, it's too prone to problems - and for a long time it was icky with patents! One of the last things my team at Apple did before I departed a decade ago was get rid of it - grayscale antialiasing only!
09:10:00 <epony> and in some legibility cases people prefer to turn off anti-aliasing and subpixled rendering so hinting is not needed then either
09:10:00 <klange> (of course, Apple could pretty handily rely on the one thing that makes subpixel antialiasing superfluous: higher DPI displays!)
09:10:00 <klange> No, hinting is absolutely needed for non-antialiased text.
09:12:00 <klange> (at small sizes)
09:12:00 <klange>
09:13:00 <epony> since 200 ppi monitors in desktop sizes are not yet the massively popular models, it's all 100 ppi land and the artefacts of vector fonts are pretty pronounced on smaller font sizes.. which requires the smootihing techniques and it's less legible, so raster fonts are still a way to "solid" text
09:13:00 <klange> This is what hinting exists for.
09:13:00 <epony> it's a bit premature for gnome to drop raster fonts and they did that a couple of years ago, and turned on by default ligatures and what not (kerning like)
09:14:00 <klange> Without hinting, the downscaled glyph has significant dropout - entire parts of the glyph do not fall in the middle of pixels that TrueType specifies as the sample point for non-anti-aliased rendering. Hinting widens the glyph to account for this. Egregious examples can be entire vertical strokes from letters like I or L going missing.
09:16:00 <klange> (why is this one separated from its hinted counterpart, damn you Microsoft OpenType specification document!)
09:19:00 <FireFly> somewhat higher ppi seems to be fairly popular nowadays, no?
09:19:00 <FireFly> like, more than the ~90-100 from like 12 years ago at least
09:19:00 <epony> no, it's 100-120 ppi on desktops still
09:19:00 <klange> Actual PPI of displays has increased greatly, but we still pretend they are 90.
09:19:00 <epony> only on small size panels
09:20:00 <FireFly> I thought at least 2560x1600 is pretty much the norm for like, 24", compared to 1920x1200 being the high end a decade ago
09:20:00 <epony> in the 20"-30" it's around 100 ppi, not around 200 ppi
09:20:00 <Mutabah> 1080p is still VERY common
09:20:00 <FireFly> fair
09:20:00 <epony> QHD in 27" is typically about 100-110 ppi
09:21:00 <klange> My 2560×1440 displays are ~125ppi
09:21:00 <epony> that's 24"
09:21:00 <klange> My Cintiq is a dense boi at 170 - 1920x1080 at 13"!
09:22:00 <FireFly> my lappy's 13" is 3456x2160 but I kinda wish it was a bit lower :p
09:22:00 <epony> so is similar to the 17" on 1280x1024 or 10" on 1024x600 ;-)
09:23:00 <epony> yes, laptops and small devices like tablets and phones now have higher resolution (density) at smaller screens but mainstream laptops are not even QHD yet
09:23:00 <FireFly> what's QHD again? i keep forgetting the name->resolution mappings, they get so arbitrary after a point
09:23:00 <epony> 2560x1440
09:23:00 <FireFly> ah
09:24:00 <epony> it's WQHD technically but, is easier to type liks SD, HD, FHD, QHD..
09:24:00 <FireFly> sure, but still 1080p or 1200p or a 13" lappy is very different pixel pitch to a 24" monitor of 10 years ago :p
09:24:00 <klange> One of the first commonly available LCD displays was the ViewSonic VP140 - 1024×768 at 14.1" for around 91ppi.
09:25:00 <epony> it's just now that 24" monitors are getting the QHD res as a standard (mainstream) it piloted on 27" in 2010
09:25:00 <epony> viewsonic were never a popular brand here, it was all LG and Samsung flatrons after the Sony CPD series
09:25:00 <epony> kind of does not exist in the low end mass market in the CRT epoch
09:26:00 <epony> and some people were getting insanely absurd monitors like AOC ;-)
09:27:00 <epony> CPD 100/200 series from Sony were 14" and 15" at 1024 and 1280 respectively
09:27:00 <klange> For something a bit more high-end, SGI's 1600SW did 1600×1024 @ 17.3" for a ppi of 110.
09:28:00 <klange> But it also cost $2500 in 1998 - that's north of $4k inflation adjusted, and it was not at all a common consumer item.
09:28:00 <epony> at the peak of the CRT technology the VGA resolutions of 2048 x 1560 were achievable (maxed) in 21" and larger for previous models
09:28:00 <epony> yep
09:28:00 <FireFly> no way 2048x1560 was common for household CRTs though :p
09:28:00 * FireFly remembers 1280x1024 CRTs (and 1600x1200 I guess on the higher end)
09:28:00 <klange> It was much more common to see people running 1280×1024 on a 19" CRT.
09:29:00 <epony> it was common for second hand monitors after some years
09:29:00 <FireFly> really? o.o
09:29:00 <klange> You'd try it at 1600×1200 and be amazed that it worked but it would be a bit fuzzy and Windows 98 would slow to a crawl :)
09:29:00 <FireFly> I def remember only heraing about up to 1600x1200 in forums at the time around the turn of the millennium
09:29:00 <epony> as soon as the LCD monitors were 1280x1024.. things swung rapidly towards LCDs
09:30:00 <epony> the first generations of TFT were not very popular, but the TN panels made them really accessible
09:30:00 <epony> and about 2005 it was game over for the CRTs
09:30:00 <klange> very late model CRTs, like in the 2000s when LCDs were available on the consumer market, things got a lot higher-res, but the form factor of LCDs won out even with lower resolutions.
09:30:00 <FireFly> makes sense
09:30:00 <FireFly> consumers probably value the smaller size and lighter weight and other things
09:30:00 <epony> it's better geometry and cheaper to produce
09:31:00 <klange> A lot of it was also just that while those CRTs existed and supported those resolutions, your video card probably shat itself trying to produce them.
09:31:00 <FireFly> oh point
09:31:00 <epony> the next generations were IPS panels which improved colours and it's just NOW entering the mainstream laptops (second hands don't yet have QHD or IPS)
09:32:00 <epony> well graphics cards rapidly improved in the 1998-2002 period
09:32:00 <epony> so went from VGA to DVI
09:32:00 <epony> and that peaked with maxing the DVI with dual link at 2010 for about 300 MHz bandwidth (maxed) WQHD
09:33:00 <klange> I don't think I've ever owned a CRT with DVI - since VGA was carrying the analog signals to drive the tube anyway it was still common, and that was a limiting factor as well (and why your 1600×1200 was going to be blurry even if the shadow mask had the dots for it)
09:33:00 <klange> (And I think CRTs that _did_ do DVI just used the analog pins anyway?)
09:33:00 <epony> so VGA peaked in 2000-2002, DVI 10 years later, yet to see the DP peak (maxed at about 8K)
09:33:00 * moon-child awaits eagerly the day when resolutions are high enough that we can just skip aa
09:34:00 <epony> yes
09:34:00 <epony> that's about the 200 ppi density
09:34:00 <\Test_User> take a bunch of phone screens and line them up
09:34:00 <epony> if you use a lense for your small screen device, you will be seing the artefacts :-)
09:34:00 <klange> 200 isn't enough, 300 probably is but you'll not see anyone do it in a phone even when those are already exceeding 300ppi
09:35:00 <FireFly> not even apple?
09:35:00 <epony> desktop need to jump from 100-120 to 200-240 first
09:35:00 <klange> Apple just abandoned subpixel and only does grayscale.
09:35:00 <FireFly> ah fair
09:35:00 <kazinsal> I'm a terrible person who bought a 32" 1440p display so I could have BIG SCREEN and still be at the same PPI as my 1080p monitors
09:35:00 <FireFly> I mean I guess it isn't really so expensive to do greyscale AA
09:35:00 <epony> we're still in the 100 ppi epoch on mainstream desktop monitors
09:35:00 <FireFly> so kinda makes sense to just keep it around?
09:35:00 <moon-child> you kidding?
09:36:00 <FireFly> or maybe it is, hm
09:36:00 <moon-child> really good greyscale aa is super expensive
09:36:00 <FireFly> ok fair
09:36:00 <kazinsal> mind you I also bought it for 144 Hz gaming but the fact that it gives me a metric buttload of monitor real estate was a major factor
09:36:00 <klange> It's also super useful if you ever want to cheat and do raster effects with your rendered text.
09:36:00 <FireFly> but like, cheap AA based on just looking at one location within the pixel or so
09:37:00 <FireFly> I figure it makes sense to keep cheap greyscale AA around even post-hidpi, but I guess it makes sense to not do costly polishing
09:37:00 <moon-child> sort of
09:37:00 <epony> cheating is how it always happens ;-) until the pixels are there, they are shared responsibility between adjacent pixel-buddies
09:37:00 <moon-child> there is somewhat serious complexity to dealing with overlapping shapes
09:37:00 <klange> (It's the only thing that will look good - non-aa text will look blocky no matter what scaling technique you use, and subpixel will have massive color smearing, but grayscale AA raster scales acceptably! - that's the real reason Apple did it, those compositing effects when you close an app or whatever need it)
09:38:00 <moon-child> because eg you don't want to double-count the overlapping bits
09:38:00 <FireFly> klange: makes sense
09:38:00 <moon-child> klange: the proper solution is to let the app render itself under whatever weird transform
09:38:00 <moon-child> have a protocol where the wm can tell the app how it's being transformed
09:38:00 <klange> moon-child: that's more expensive than having a GPU scale a texture!
09:39:00 <FireFly> also a lot more burden on the app developer that they probably don't want or care enough about (when the one who really cares about nice looks is the platform, kinda)
09:39:00 <moon-child> only because software patents
09:39:00 <moon-child>
09:39:00 <bslsk05> ​ How I still use Flash in 2022 | Lobsters
09:39:00 <klange> Also if you want to have difficulty with overlapping bits, ooh boy... try rendering a semi-transparent window with a command list without rasterizing it first!
09:39:00 <epony> and now for the maniacs, you can NEVER have fine colour representation in this generation of technology for text, because the adjacent pixels get side effects, and the colours look different when it's just 1 pixel next to another colour area
09:39:00 <moon-child> FireFly: app developer is gonna use whatever ui toolkit, and the ui toolkit will deal with it
09:40:00 <FireFly> mmm mabye
09:40:00 <moon-child> and in the case of apple/ms/redhat ... the developer of the ui toolkit is also the developer of the wm
09:40:00 <FireFly> people don't use those though :v (well, generalising, but having worked at a webdev place that did a lot of react native apps too)
09:40:00 <klange> Anyway, I had a lot of fun with my truetype rasterizer, and I think my text looks quite acceptable.
09:40:00 <moon-child> klange: that is hard, I will grant you :P
09:42:00 <epony> so you get to pick lower contrast background at equal distance to your colours first, and then deal with your display inability to render accurate colours in adjacent pixels with "corrections" in the same way (but different algorithm) that are needed for subpixel rendering
09:42:00 <moon-child> (and I will note: whereas compiz is out of style, and apple kind of stands alone w/its 'genie animation', rendering under transform is more important than ever now, given vr)
09:43:00 <epony> so it still has a distance to go, after getting the high-pixel density next-generation resolutions on the desktop
09:43:00 <epony> compositing effects are kind of cool
09:44:00 <epony> and given the fact that modern graphics cards do 2D in their 3D shaders and rendering directly in hardware primitives, for about 20+ years already
09:44:00 <epony> it's kind of stupid to not use the 3D for rendering and compositing in the software
09:44:00 <klange> I do scaling effects on window open/close, I support rotation, transparency... all in software, because I don't have drivers.
09:45:00 <klange> I also support blur-behind but that's a really expensive one I reserve for special cases.
09:45:00 <epony> there are no unaccelerated graphics any more except on specialised 2D rasterisation hardware and video processing graphics like the Matrox series that have standalone high-performance 2D and video layering
09:46:00 <moon-child> scaling is somewhat easier because, per, a screenspace square is also a curve-space square
09:46:00 <bslsk05> ​ Curves should be rendered in curve space
09:46:00 <moon-child> (rotation, ok, you're probably not axis-aligned anymore, but who cares~)
09:47:00 <klange> rotation, bad downscaling, and some blur-behind
09:47:00 <moon-child> what kinda sampling do you use for the rotation/scale? Bilinear
09:47:00 <moon-child> ?
09:48:00 <klange> yeah, it's all bilinear
09:49:00 <moon-child> simd? Seems like it should be parallelisable, but also kinda pita
09:49:00 <klange> I don't use any SIMD directly for the sampling, but I do have some SIMD stuff for blitting.
09:49:00 <moon-child> (vs gpu where you get hardware sampling and fast gather)
09:49:00 <klange> I can build with nearest-neighbor for demo purposes:
09:50:00 <moon-child> might be able to do a higher-quality sample if you simd
09:50:00 <klange> (it looks even worse with the bitmap font!)
09:50:00 <moon-child> omg that's bad
09:52:00 <klange> (I'll note in the other screenshot the left terminal is TrueType with grayscale AA, and the right terminal is the bitmap font; I don't support non-AA truetype rasterizing due to the aforementioned requirement for hinting to not get dropouts - the bitmap font wasn't even baked with my rasterizer, I used FreeType to do it before I even started working on mine.)
10:02:00 <ddevault> ayy firefox opens ARMARM today
10:04:00 * Ermine waves his ARMs
10:06:00 <FireFly> (ARM)²
10:07:00 <FireFly> I do appreciate ARMs punnery
10:07:00 <FireFly> or Arm now ig
10:08:00 <Ermine> It was advanced risc machine
10:08:00 <Ermine> or acorn risc machine
10:10:00 <Ermine> ddevault: did you try running Helios on your Pinebook?
10:13:00 <ddevault> not yet, someday
10:13:00 <ddevault> current target is rpi4
10:13:00 <ddevault> will attempt pinephone at some point
10:13:00 <ddevault> I bet I can make it send/receive SMS pretty easily
10:14:00 <ddevault> does anyone have a readily copy/pastable example of using tlbi on aarch64 to invalidate a specific page in a specific ASID
10:14:00 <klange> The web version of the ARMARM is one of the worst-designed websites it has ever been my displeasure to use, and I live in Japan where the local web design is infamously horrible.
10:14:00 <ddevault> reading the ARM manual and it has too many words
10:14:00 <epony> you mean firefox will now target UNIX instead of WIN/DOS ?
10:14:00 <Ermine> and too many letters
10:15:00 <epony> when FF gets to run well on LIN/DOS, then it would be targeting UNIX
10:16:00 <epony> for now it runs well on JVM and on WIN/DOS
10:17:00 <ddevault> >Register bits[45:44] are the SCALE field that is the exponent element of the calculation that produces the upper range
10:17:00 <ddevault> kill me
10:18:00 <klange> Don't worry, your upcoming seizure as you continue to read the ARMARM will take care of that.
10:18:00 <ddevault> tempted to just invalidate the whole TLB and move on with my life
10:19:00 <Ermine> out of context it is even more obscure
10:20:00 <klange> Looking at all my tlbis... they're all vmalle1is :D
10:20:00 <klange> which I think is cargoculted from something in m1n1
10:22:00 <Ermine> okular hits 100% of CPU consumption while looking for this phrase, but Linux moves to different kernels somewhy
10:23:00 <ddevault> I think this is what I want
10:23:00 <bslsk05> ​ paste.txt —
10:23:00 <ddevault> latter is a bonus but it was easy enough to understand and easy enough to implement so I might as well go for it
10:26:00 <epony> the goal to have a fat application like that run on your newfang kernel.. is a long process
10:26:00 <FireFly> Ermine: yeah, but also ARM Thumb, and IIRC "LEG" was a thing too
10:26:00 <FireFly> they like their puns on limbs :p
10:26:00 <epony> body parts for robots
10:26:00 <klange> good luck googling that
10:26:00 <FireFly> (and the ARM ARM of course)
10:27:00 <Ermine> FireFly: my favourite puns in this channel involve warmth.
10:27:00 <klange> Do you like it when we... turn up the heat?
10:28:00 <klange> (heat is currently offline, so no ping)
10:28:00 <Ermine> yeaaah
10:28:00 <ddevault>
10:28:00 <bslsk05> ​ ~sircmpwn/helios: +aarch64: implement arch_page, TLB invalidation - sourcehut git
10:28:00 <ddevault> ¯\_(ツ)_/¯
10:28:00 <ddevault> good enough
10:28:00 <ddevault> assuming it works, who knows
10:28:00 <epony> in general, these are microcontroller designs which have been outgrown to be microprocessors and systems-on-chip
10:29:00 <epony> the complexity is serious, comparable to the entire x86 machine standards in one hubrid ASIC+
10:29:00 <Ermine> ddevault: I guess hare translates "tlbi_vae1" function names to "arch.tlbi_vae1" ?
10:29:00 <epony> hybridisation is happening on chipsets on generic PCs for a long time too
10:30:00 <ddevault> yeah
10:30:00 <ddevault> adds namespace
10:30:00 <klange> aarch64 is pretty clean-slate
10:30:00 <epony> the northern and southern bridges and their fused chipset are moving towards the CPU, it's only high performance and waste heat limit than integration
10:31:00 <epony> but the central processor has now a memory controller and an input-output controller and multiple cores and separate dies (semiconductor cross connects)
10:32:00 <epony> waste heat is a serious problem for SoCs
10:33:00 <epony> so much as to mandate the separation in remote areas of blocks that share functionality and complex power management on each functional block with dynamic scaling (rapid)
10:34:00 <epony> the drawings that are shown on "product presentations" are very simplified and non-technically accurate
10:35:00 <Ermine> ARMARM TLDR version when
10:35:00 <ddevault> ARMARM split into volumes when
10:36:00 <Ermine> good question actually
10:36:00 <epony> ingsoc wasteheat
10:36:00 <bslsk05> ​ System on a chip - Wikipedia
10:36:00 <ddevault> at the very least split up the aarch64 and aarch32 parts
10:36:00 <ddevault> maybe another one for extensions
10:36:00 <epony> models are released yearly
10:36:00 <epony> expect changes all the time
10:37:00 <ddevault> and instruction encoding
10:37:00 <Ermine> intel technicians managed to cut pdf in 4 parts
10:37:00 <epony> the books for an architercture are split in print too
10:37:00 <klange> Intel used to sell physical books.
10:37:00 <epony> yep
10:38:00 <ddevault> I should probably improve my memory map at some point
10:38:00 <GeDaMo> Intel used to send you physical copies of their manual for free
10:38:00 <ddevault> ¯\_(ツ)_/¯
10:38:00 <klange> Not anymore, sadly.
10:38:00 <Ermine> physical ARMARM book in its current form will be dangerous mechanically
10:38:00 <ddevault> I want to be able to keep EFI runtime services around someday
10:38:00 <klange> They'll offer to send you a print-on-demand copy through Lulu now...
10:38:00 <klange> For a fee.
10:38:00 <Ermine> ddevault: what these runtime services are good for?
10:39:00 <ddevault> basically only useful if you want to implement efibootmgr(1) equivalent for your system
10:39:00 <ddevault> i.e. configure boot entries or set up the bootloader during an installer
10:39:00 <epony>
10:39:00 <Ermine> ddevault: ah, thank you.
10:39:00 <klange> There's some timer stuff in there that's kinda useless, there's a reset vector, but the bulk of it is the efivars.
10:39:00 <ddevault> bad look if your install process involves "after install, boot linux and run this efibootmgr command to configure the bootloader"
10:40:00 <klange> just install your bootloader to boot${arch}.efi and be the only one :D
10:40:00 <Ermine> There might be other entries still
10:41:00 <klange> just nuke everything else and the fallback behavior will take care of it :)
10:42:00 <Ermine> take care to not nuke nvram so your device doesn't brick accidentally
10:42:00 <ddevault> well, you need to edit variables if you want to set a kernel command line
10:43:00 <klange> that's why I have an efi loader that has a little text editor in it
10:44:00 <ddevault> hard pass
10:44:00 <ddevault> thanks
10:44:00 <klange> You could also do something like read them from a file in your EFI stub.
10:44:00 <Ermine> I mean, there was a story, where guy rm -rf'ed their linux and that wiped nvram, because efivarfs was mounted rw, and that laptop died because of broken firmware that couldn't reinitialise nvram
10:45:00 <epony> don't forget, you're treating ARM like a 16bit epoch CPU in its capabiltiies, these now support virtualisation and extensions for data processing and cryptography too, and have integrated graphics, low precision and high precision maths, and periphery
10:45:00 <epony> and the memory is in there too
10:47:00 <klange> Hm, my rpi stub is still hardcoding command line options... I should switch that to getting them from the dtb... there's a lot I've hardcoded for the rpi400.
10:49:00 <GeDaMo> ddevault: I just looked at the ARM in Firefox and it looks like it works but only displays up to page 8050 :/
10:49:00 <ddevault> sometimes I have to refresh to get to the register index
10:50:00 <ddevault> try clicking register index in the ToC and hitting refresh until it works, or until you give up
10:50:00 <GeDaMo> I'm going to try and split it into smaller files
10:50:00 <ddevault> breaks references
10:50:00 <ddevault> but good luck
10:50:00 <GeDaMo> Yeah, I know
10:50:00 <ddevault> I depend heavily on references
10:59:00 <GeDaMo> pdfseparate segfaults :/
10:59:00 <epony> you're using a scripting language ;-)
10:59:00 <moon-child> lol
10:59:00 <epony> that inflates memory use 2x
11:00:00 <epony> (compared to the data processed)
11:00:00 <ddevault> just implement a PDF encoder/decoder in Hare
11:00:00 <ddevault> see you in 3 months
11:00:00 <epony> years
11:01:00 <epony> the place and time is here
11:02:00 <epony> hare there, achilles runs with lead sandals
11:02:00 <Ermine> GeDaMo: maybe malloc fails due to the size of the file?
11:03:00 <GeDaMo> I have memory! :P
11:03:00 <ddevault> I sure hope it doesn't malloc the whole file
11:04:00 <ddevault> though it's only 70M so
11:04:00 <kaichiuchi> hi
11:04:00 <Ermine> Ah, this is poppler, which is glib based
11:04:00 <Ermine> hi kaichiuchi
11:06:00 <Ermine> GeDaMo: valgrind says this is a stack overflow
11:06:00 <epony> the pdf format supports internal compression
11:06:00 <GeDaMo> :/
11:06:00 <epony> and vector graphics drawings are killing even reasonable machines
11:07:00 <epony> (on complex layouts and larger schematics)
11:07:00 <Ermine> HEAP SUMMARY: in use at exit: 89,698,879 bytes in 171,006 blocks
11:07:00 <Ermine> total heap usage: 1,933,738 allocs, 1,762,732 frees, 263,852,941 bytes allocated
11:10:00 <epony> vs
11:10:00 <bslsk05> ​ Talaria - Wikipedia
11:10:00 <bslsk05> ​ Flyboard - Wikipedia
11:11:00 <epony> ^ compiled vs interpreted
11:11:00 <GeDaMo> I tried a different program called pdfexplode which produced a lot of apparently blank pages
11:11:00 <Ermine> At least it didn't exlode your machine
11:12:00 <GeDaMo> ... yet :|
11:13:00 <epony> you know compilation and other processing can happen on a larger machine targetting the smaller
11:13:00 <ddevault> look at you with your fancy "larger machines"
11:13:00 <epony> it's not really intended to work on the small machine interactively even on such "capable" modern variants
11:13:00 <ddevault> damn bourgeois kernel hackers
11:14:00 <epony> the luxury is in the hands of people creating 10K page documents
11:30:00 <moon-child> ulimit?
11:33:00 <Ermine> moon-child: unlimited
12:26:00 * kof123 mumbles about ancient lectern can pre-render things for known resolutions...not unlike bitmap fonts versus scalable...
12:54:00 <epony> in view of modern times, the single greatest mistake is not using the hardware accelerators and built-in CPU extensions for fast and assisted processing of data
12:55:00 <epony> it's like 22 years since graphics are 3D capable and suitable for use of that in applications, and the graphics servers provide that functionality
12:56:00 <epony> they were usable since 1996-1998 but 2000 in general is when most graphics progressed to useful 3D rendering in place of the 2D/3D separation
12:57:00 <epony>
12:57:00 <bslsk05> ​ Hardware acceleration - Wikipedia
13:00:00 <kaichiuchi> god i forgot how nice i3 can be
13:20:00 <kaichiuchi> and vim
13:20:00 <kaichiuchi> i think i’m getting old now
14:07:00 <ddevault> one thing I'm unclear of about the ARM system timer is how the interrupts from it actually happen
14:07:00 <ddevault> do they raise an IRQ? can it be programmed?
14:16:00 <ddevault> okay yeah
14:16:00 <ddevault> raises IRQ 27 via the GIC
15:02:00 <jafarlihi> In FreeBSD ext2 FS, ext2_root calls VFS_VGET where one of the arguments is `ino`, which is defined as "unique number assigned by fs when vnodes are first created" in manual. Does anyone know where these vnodes are "first" created?
15:03:00 <epony> check that symbol in the BSD cross reference
15:03:00 <epony> ext2 is not part of FreeBSD
15:04:00 <epony> as in, not designed there, and is either an import from Linux or a minimal reimplementation (the second option more likely)
15:04:00 <epony> you'll see ext2 support in all of the three BSDs
15:04:00 <jafarlihi> I'm trying to implement FS, just trying to understand where these vnodes are first created
15:05:00 <epony> bascially ext2 is a "clone / descendant" late re-implementation of UFS/FFS in the Linux kernel space with changes betwee ext (early experimental designs) and ext2 (with ideas from BSD)
15:06:00 <epony> yes OK
15:06:00 <epony> now get the "design and implementation of the 4.4BSD system" by McKusick et all
15:06:00 <jafarlihi> I already have FreeBSD design and impl, it doesn't say much about fses, is it different for 4.4 book?
15:07:00 <epony> not much
15:07:00 <epony> it should because that's the book on the OS and the FS is integral part of it
15:07:00 <epony> so check again in the book
15:07:00 <jafarlihi> It just generally covers what fs is, not much helpful for implementer
15:07:00 <epony> can't have an OS that gave UNIX the UFS and its FFS rework withou it
15:08:00 <epony> you're mistaken
15:08:00 <epony> it has code snippets too and data structures
15:08:00 <epony> and logic how it operates
15:08:00 <epony> read the earlier book if you like
15:09:00 <jafarlihi> Why did you recommend the earlier book? Anything better about it?
15:09:00 <epony> there is also important detail on the buffer cache, don't skip that
15:09:00 <epony> I don't know what's in the later edition books ;-)
15:09:00 <jafarlihi> ok thanks
15:11:00 <epony> the 2nd edition of the book (FreeBSD) is from 2014 and has 1152 pages..
15:11:00 <epony> FreeBSD has extra details like GEOM that you probably will not be implementing
15:13:00 <epony> so, chapter 9 pages 506 to 615 is about the Fast Filesystem
15:13:00 <epony> that's what you need, the first short description in pages 70-75 are just "general details"
15:14:00 <epony> go further in the book
15:14:00 <epony> 9.2 Structure of an Inode p508
15:16:00 <epony> let me check the older books too
15:16:00 <jafarlihi> ok i see thanks
15:16:00 <jafarlihi> what other books are there?
15:17:00 <epony> Linux kernel documentation on the ext2
15:17:00 <epony> and LPI (linux programming interface)
15:18:00 <jafarlihi> I'm not interested in ext2 besides how it interfaces with FreeBSD
15:19:00 <epony>
15:19:00 <bslsk05> ​ Ext2fs - FreeBSD Wiki
15:20:00 <epony> there are 2 links in the first section
15:20:00 <epony>
15:20:00 <bslsk05> ​ [base] Index of /head/sys/fs/ext2fs
15:33:00 <epony> obviously this VFS_ is for virtual file system
15:33:00 <bslsk05> ​ identifier "VFS_VGET"
15:35:00 <epony> vget is an object read and write operator
15:36:00 <epony> in that list vget, blkatoff, read, write, fsync
15:37:00 <jafarlihi> i gotta go
17:49:00 <gog> hi
17:49:00 <GeDaMo> Hi gog :)
17:52:00 <gog> what's shakin
17:54:00 <Ermine> hi gog
17:54:00 <gog> hi Ermine
17:54:00 <kaichiuchi> hi goggles
17:54:00 <kaichiuchi> gog*
17:54:00 <kaichiuchi> .
17:55:00 <gog> goggies
17:55:00 <gog> poggies
17:56:00 <Ermine> poggles
17:59:00 <Ermine> heatles
18:02:00 <GeDaMo>
18:02:00 <bslsk05> ​ Was Jim Carrey Trained by a CIA Torture Expert on Surviving Grinch’s Makeup? |
18:11:00 <gog> nice
18:46:00 <gog> i chomped fishy again
18:54:00 <heat> henl
18:54:00 <heat> 2day i went 2 dentisk and i am in 🅱️ain
18:56:00 <FireFly> oh no
18:58:00 <zid> Have you considered not having teeth
18:58:00 <zid> it's way simpler
18:58:00 <zid> beeth
18:58:00 <gog> heat: bazel
18:58:00 <zid> toothn't
18:58:00 <heat> i have 🅱️not
18:59:00 <heat> oops, 🅱️ot*
18:59:00 <mjg> what's up with this 🅱️ thing
18:59:00 * mjg == out of the loop
18:59:00 <zid> It's some meme
18:59:00 <heat> gen z humor
18:59:00 <mjg> ok, in that case it is pretty funny
19:04:00 <heat> gog, bazooms
19:13:00 <FireFly> reminds me of seeing a [B] sticker over the H in a sign to "Exhibition Halls" at congress
19:20:00 <epony> isn't genz genderless, so technically not a gen but just a ""
19:24:00 <epony> at least the makeup is like kindergarden children that found their moms cosmetics and experimented a bit to immitate grandma
19:25:00 <kaichiuchi> heat: give me the drugs
19:25:00 <epony> (that may be leftovers from grandma anyway, since parents emmigrated in another state / dimension / hospital)
19:25:00 <heat> mjg has them
19:26:00 <mjg> already snorted my last dope
19:26:00 <mjg> admittedly upon reading this message
19:27:00 <epony> at least you have some moonshine to wash down the tide pods
19:30:00 <kaichiuchi> explains BSD
19:30:00 <epony> you've come to do programming on the rpi and chew bubblegum, and you're all out of bubbles
19:31:00 <gog> 🅱️ysergic acid diethylamide
19:31:00 <epony> more like solo-BSDM for the uninitiated
19:31:00 <heat> if anyone wants free drama
19:31:00 <bslsk05> ​ 4234 – UefiCpuPkg reaches a new low by BLATANTLY ignoring 32-bit Intel processors in commit 73ccde8f6d04
19:32:00 <epony> or BSMD.. whatever works for you
19:34:00 <kaichiuchi> hah
19:34:00 <epony> once you compile your liloinux into lilnucks.. it's not very interesting
19:35:00 <Ermine> "BSD and LSD were invented in the same place..."
19:35:00 <epony> that's about the funniest most important "scarification" to get on LeanUX
19:36:00 <epony> a couple of sessions tweaking and recompiling the kernel, and then redo that monthly to keep the hardening shit tougher during the rainy season
19:36:00 <epony> maybe LSD is invented somewhere else, but was practiced mostly in the English and new-England youths
19:38:00 <epony> DDT / LSD.. experimental spraying of young shoots
19:38:00 <epony> seems to have stuck with Donny the agent O'Range
19:38:00 <epony> anyway
19:39:00 <epony> I heard you like HURD
19:39:00 <epony> the GNU HURD
19:39:00 <epony> (use capitals like it's 1969 LISP AGAIN)
19:40:00 <epony> at least the Rpi is large enough to run Object Oriented Programming.. techniques of mastery and amazement in COMMON LISP
19:41:00 <epony> it's only 40 years late to save the Lisp Machines, Inc.
19:42:00 <epony> video killed the radio star
19:42:00 <bslsk05> ​ Lisp machine - Wikipedia
19:44:00 <epony> Apple product line goes here »
19:44:00 <bslsk05> ​ Orphaned technology - Wikipedia
19:58:00 <heat> "Ignoring proper error handling is lazy and dangerous. It's the kind of attitude for which I would instantly fail any candidate at the interview stage. It's slightly worrying to see it exhibited in someone with push access to the EDK2 repository. On the plus side, this suggests that Intel-authored EDK2 code is likely to be a very productive place to search for Secure Boot exploits. :)"
19:58:00 <heat> holy shit i love the fucking drama
19:58:00 <zid> heat what is wrong with my cat
19:58:00 <heat> is it barking
19:58:00 <zid> she's hiding in the spare bedroom and hissed at me when I went to check on her
19:59:00 <kazinsal> the part where they realize they actually found a QEMU TCG bug in the process is amazing
20:02:00 <epony> emulator bugs, unheard of
20:02:00 <epony> virtualisation is like that too
20:03:00 <epony> if you combine the two you get double whammy
20:03:00 <epony> the only thing you'd dearly miss are bugs in the host kernel, and in the compiler.. the CPU has them just fine™
20:04:00 <epony> oh, and that language you're using.. it's not working
20:07:00 <epony> the only good thing.. the standard library ;-)
20:07:00 <epony> (or much more, the standard which it tries to work with0
20:10:00 <gog> zid: is she lethargic
20:10:00 <gog> and is she getting enough water
20:10:00 <gog> cats tend to do that kind of thing when they're ill
20:12:00 <Ermine> poor kitty :(
20:12:00 <gog> or something startled her and she's feeling ways about it
20:13:00 <gog> but yeah keep an eye on her and see what she does if she keeps doing this and doesn't eat or drink anything then a vet visit might be in order
20:24:00 <zid> she seems totally fine, just in a total mood
20:25:00 <zid> I think heat kicked her
20:25:00 <zid> he's like that
20:25:00 <gog> :o
20:25:00 <gog> no kick kitty
20:25:00 <gog> 3:<
20:26:00 <zid> she's been bored or something for a couple of weeks though
20:27:00 <zid> usually she sleeps on the sofa on a certain cushion but she's been all over the place
20:27:00 <zid> she sometimes does this though, re-trials all the sleeping spots
20:27:00 <kazinsal> you should get her a fort warms
20:27:00 <kazinsal>
20:27:00 <bslsk05> ​ K&H Pet Products Thermo-Kitty Heated Pet Bed Small Mocha 16" 4W : Pet Supplies
20:27:00 <kaichiuchi> i want a cat
20:28:00 <gog> mew
20:28:00 <kaichiuchi> also I can’t write makefiles
20:28:00 <kaichiuchi> people are wizards
20:28:00 <kazinsal> I got my mom's cat a fort warms for christmas and he is absolutely in love with it
20:28:00 <zid> or type apostrophes
20:28:00 <gog> nobody can sometimes we just get lucky
20:28:00 <zid> makefiles are dead easy as long as your project is dead easy
20:28:00 <zid> thing: dep\n\tcommand
20:29:00 <zid> Behold the most complex makefile I ever wrote
20:29:00 <bslsk05> ​ bootstrap/Makefile at master · zid/bootstrap · GitHub
20:30:00 <gog> $🅱️OBJ
20:34:00 <zid> for C++ you probably wanna do the autogenerated dep graphs from headers think though
20:34:00 <kaichiuchi> i’m not doing C++
20:34:00 <zid> thing*
20:43:00 <heat> i dont kicc catz
20:43:00 <heat> do u?
20:43:00 <zid> That's what someone who didn't wanna get bullied for kicking cats would say
20:43:00 <heat> i have 2 cat
20:44:00 <kazinsal> hug the cats
20:44:00 <heat> u have 1 cat? ur statistically more likely to kicc cat
20:48:00 <kaichiuchi> no
20:49:00 <kaichiuchi> i want cats :(
20:49:00 <kaichiuchi> as long as they don’t cut my jugular in my sleep
20:50:00 <zid> two cat
20:50:00 <kaichiuchi> unfortunately where i live pets are forbidden
20:51:00 <zid> from being found out about*
20:51:00 <kaichiuchi> but usually i end up holding them like a fucking fetus
20:51:00 <kaichiuchi> zid: allergies with other people
21:14:00 <heat>
21:14:00 <bslsk05> ​ Google announces official Android RISC-V support
21:14:00 <heat> trashy architecture taking strides
21:28:00 <zid> ah yes but it's *intentionally* trashy!
21:28:00 <zid> so it's okay
23:22:00 <mats2> why do my farts smell so good
23:48:00 <geist> yeah if it owns the trash that's okay
23:58:00 * mjg burps