KDE Plasma Login Manager Won’t Support Systemd-Free Linux or BSD Systems

LoganGreystone said:
Yes, for now, but it seems they are having trouble adapting to GTK4. Hopefully they will overcome it.
Click to expand...
I come to think following Gtk major versions is not a good thing, as Gnome is going to dispose X11.
Forking Gtk3 and maintaining (by someone possible, but unfortunately, not me) it seems to be way to go.
Or fork upcoming Gtk5 to adapt again with X11?
In my humble opinion, dropping X11 is simply silly. Disposing Wayland and reconsidering what should be done and what should not may be far more constructive.
 
AlfredoLlaquet said:
What do you mean? I'm not sure I'm following you.
Click to expand...
Exactly what you quote.
At least for me, Wayland broke Japanese inputs, which is working OK on X11 (which needed a decade+ to be stabilized and usable). Modifying this part looks crazy for me. Should be re-designed to use what's working on X11 as-is.

Yes, there would be complaints with X11, maybe on its "thickness" and resource consumptions (if I recall correctly, for example, X11 didn't work fine without FPU). So part of Wayland could be (hopefully) reused for redesign. But if I understand correctly, Wayland requires each apps to have too duplicated things with other apps (like Rust wants to do). It seems way back.

Some X11 lovers wants X11 clients (which wants X11 server to draw anything) to display on remote (from the point of view the X11 client is running) X11 server at the user's location, but it seems that this is one of which Wayland wants to dispose. Would need a plenty of discussions within quite wide range of stake holders (not only IT companies like RedHat/IBM, but end users and developers) which is really correct.

And would be far, far more to be reconsidered.
 
T-Aoki said:
Interesting!
But unfortunately, as far as I know, no compilers available (and not hard to find where they're sold) supported the mode at least in Japan, especially outside Tokyo.
Click to expand...

I think historically the mode wasn't known until proliferation of Windows 2 and DOS 5, coming with HIMEM driver for 286 in late 80s.
386 was already a thing.

Also it is merely an extension of real mode as far as segmentation is concerned. The normal 16-bit real mode code just works under it. So the modification to usual C program would be inlined asm to kick into the mode, and some asm functions to repoint or copy segments above to segments below. You don't have to actually change your programs memory model to use extra memory.

So for these two reasons I think no major compiler existed at all...
 
Zare said:
I think historically the mode wasn't known until proliferation of Windows 2 and DOS 5, coming with HIMEM driver for 286 in late 80s.
386 was already a thing.

Also it is merely an extension of real mode as far as segmentation is concerned. The normal 16-bit real mode code just works under it. So the modification to usual C program would be inlined asm to kick into the mode, and some asm functions to repoint or copy segments above to segments below. You don't have to actually change your programs memory model to use extra memory.

So for these two reasons I think no major compiler existed at all...
Click to expand...
Annoyingly, pre-32bit era compilers (at least, proprietary ones) had "memory models", usually "S" for single 64kiB segs for each segregs, "M" for multiple 64kiB CS and single per others, "L" allowing all (but SS, maybe) segregs multiple 64kiB. Some had "T" for so-called "com" that shared single 64kiB segment with all segregs (for *.com on DOS) and "L" for multiple 64kiB segs of DS and single for others (and "H" stands for huge, that I cannot recall).

The restriction was reasonable for "real mode only" pre-286 processors that needed to allow porting from i8008, i8080 and i8085 (or any other licensed ones lile Z80) 8bit processors easier and simpler. But not at all good limitation for protected mode introduced at i80286.

If i80286 had vm86 mode and allowing to "context switch" to it, applying the 64kiB limitations just to real mode (before entering protected mode) and vm86, things could be different.
 
T-Aoki said:
Interesting!
But unfortunately, as far as I know, no compilers available (and not hard to find where they're sold) supported the mode at least in Japan, especially outside Tokyo. More, if I recall correctly, no Japanese computer magazines focused on the feature at the moment .

And segments in "protected mode" should have the same kind of "full address space segment".
Click to expand...
I wonder if it's possible to use Unreal Mode at all today? It'd be interesting to see Unreal Tournament using it :cool:
 
Yeah. Because they needed to assist the developer in working around seg:offset model. So they made few of those 'T-shirt' size presets, of which compact was IMO mostly used, as it was uncommon to have more than 64kb of code.

And yep this thing is 8080 heritage as it was a 64kB CPU. The segment register was a cheap solution. I think worse problem for early PC was DMA from 8080 chipset, that also lost a channel for DRAM refresh. The 8 bit memory bus of PC and XT is able to do over 1 megabyte per second, but there were no device to device transfers, and no standard ISA bus mastering methods.

Btw on 286 and vm86, check here - https://en.wikipedia.org/wiki/LOADALL#Usage , second paragraph. This is very early on, first year of development for 286, and it isn't clear whether this was a 'trick' Intel knew about, but didn't put their money on because it was inoptimal, but was perfected for 386, or it is the OS vendors usage pattern that made Intel realize they need vm86 mode.
 
Zare said:
Btw on 286 and vm86, check here - https://en.wikipedia.org/wiki/LOADALL#Usage , second paragraph.
Click to expand...
Off topic here, but there were EMS that allowed pre-i286 CPUs to use >1MB of memory in tricky way (bank switching on configured i.e., 64kiB, memory window).

Maybe young persons wouldn't be able to believe, but PC-9801Vm2 (its CPU was V30) I've used before had only 384kiB (not GiB nor TiB, even not MiB!) and I had 2MiB of "Bank Memory" technically alike hardware EMS (used 128kiB memory window) to expand memory to the maximum 640kiB that is supported by pre-i286 PC-9801 series and used remainders as ramdisk. Putting dics there, this ramdisk allowed Japanese inputs "still slow but not fully unusable" speeds, which cannot live without it. The main memory and computational power was too insufficient for satisfactory Japanese inputs.
Japanese edition of the EMS page describes a bit about the "bank memory".
 
You must log in or register to reply here.
Back
Top