SoylentNews is people
SoylentNews
from the 640k-is-more-memory-than-anyone-will-ever-need dept.
Linux x86/x86_64 Will Now Always Reserve The First 1MB Of RAM - Phoronix:
The Linux x86/x86_64 kernel code already had logic in place for reserving portions of the first 1MB of RAM to avoid the BIOS or kernel potentially clobbering that space among other reasons while now Linux 5.13 is doing away with that "wankery" and will just unconditionally always reserve the first 1MB of RAM.
[...] The motivation now for Linux 5.13 in getting that 1MB unconditional reservation in place for Linux x86/x86_64 stems from a bug report around an AMD Ryzen system being unbootable on Linux 5.13 since the change to consolidate their early memory reservations handling. Just unconditionally doing the first 1MB makes things much simpler to handle.
The change was sent in this morning as part of x86/urgent. "Do away with all the wankery of reserving X amount of memory in the first megabyte to prevent BIOS corrupting it and simply and unconditionally reserve the whole first megabyte."
no more wankery
(Score: 3, Informative) by SomeGuy on Sunday June 06 2021, @07:46PM (8 children)
It was also the Unix/Linux folks who kept complaining that a GUI would waste "too much memory", even though the original Mac did it in 128k, and Windows 95 could do it in as little as 4MB.
(Score: 0) by Anonymous Coward on Sunday June 06 2021, @08:31PM (5 children)
I remember when the Linux people were complaining that X was "slow" and used too many resources. A friend of mine asked one of the original X developer about it, and he said that X was designed to run on 1 MIPS machines. People were worried that because it was a network protocol that somehow it would be very slow. It isn't, and particularly not when you're running it on the local machine.
(Score: 2) by tangomargarine on Monday June 07 2021, @06:24AM (4 children)
Notice the sudden shift in tenses during your post...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Monday June 07 2021, @02:27PM (3 children)
No kidding. X's fundamental design is wrong in the one should build a graphics system with fast local performance and built a network layer (IF this is even to be done!) on top of that. Experience has long shown that drawing primitives sent across the network are a failed idea. Way too low-level way to implement GUIs across a network.
The Smalltalk-72 programming language made the same mistake and implemented message passing in a network transparent manner. Method calls were terribly slow, and later versions of Smalltalk were implemented using virtual methods for message passing, same as in Java or C++. Objective-C, which is an amalgamation of Smalltalk and C, implemented the original Smalltalk-72 message passing technique of network transparent method calls. As a result, it is slow. Objective-C has been in the process of being phased out for a long time by Apple in favor of other languages.
(Score: 0) by Anonymous Coward on Monday June 07 2021, @02:56PM (1 child)
If the client and server are the same machine, that is if you are running the application locally, the data isn't sent across the network. I love the flexibility that X gives for running GUI apps on a LAN. It means I can have one monitor and one keyboard and several machines without a KVM.
(Score: 0) by Anonymous Coward on Monday June 07 2021, @03:52PM
Modern X doesn't send drawing primitives across the network. The X extension used updates the remote framebuffer. MIT guessed wrong when they came up with the design of X.
(Score: 0) by Anonymous Coward on Monday June 07 2021, @05:23PM
Correction: I need to correct my programming language post: the programming languages I mentioned did not, I believe implement NETWORK TRANSPARENT message processing, but they did do dynamic message lookup based on an intermediate method lookup broker. This is one step below network transparency, but is similar in some ways.
(Score: 0) by Anonymous Coward on Monday June 07 2021, @01:29AM (1 child)
128K was not enough. A mere year later, Apple released the "Fat Mac" with 512K of RAM.
(Score: 3, Informative) by mechanicjay on Monday June 07 2021, @06:43PM
Yep, though the OG 128K release model didn't even make it a full year.
Sept '84: 512k machines released.
I have an actual FEb '84 128k mac -- it is possibly the most useless computer I've ever used. It's fine for like a demo of a sneak peak of what the platform might be capable of, but not really usable. Adding an external floppy drive helps quite a bit, which lets you keep the internal disk as the "system disk" so you don't have keep swapping it back it at random times. It's neat as an artifact, but I have far old and more capable machines that I use on a regular basis.
My VMS box beat up your Windows box.