Many other clickbait articles claimed that M1 is better than the best desktop class CPUs. I only tested the water and found otherwise. The 5900HX is planned and should be within 90% performance of my 5800X within 45W TDP. Not close to the power consumption, but then zen 3 is only on 7nm, while M1 is on 5nm.
The Mac Mini is $699 with only 8GB RAM, that runs out after a few browser tabs. So, for a work machine, you would need at least the 16GB model and add $200 to that. Though the build quality and the panel is excellent.
You could opt for the 5600X. The core count is not relevant in the article, as the benchmarks are mainly single-threaded.
This is comparing the M1 which a mobile focused chip in a tiny power envelope to the pinnacle of AMD cpu design in a giant (relatively) power envelope. My point was that the article could have stood on its own without even benching against the M1. Just show the performance of the 5800X in tasks the M1 and the 5800X are not in the same league.
I don't know what you are talking about. The problem with fake information is that you have to spend more resources debunking it than it takes to create fake information in the first place.
Anecdotal, of course, but I currently have 42 tabs open in Firefox 84 (native M1 build) on an 8gb M1 Mac Mini, as well as two VS Code windows and a bunch of other things like Mail, Calendar, Authy, Bitwarden, etc. As far as memory management is concerned, user experience is indistinguishable from my 32gb Ryzen 3700X desktop with a Samsung NVMe.
8GB is plenty for most people right now. A browser won’t eat that much memory for normal sites and reasonable tab counts.
An interesting thing about the M1’s RAM limit, though, is that it literally can’t get any bigger. 16GB is pushing it, but fitting 32GB into a package-on-package simply can’t be done with our current tech. Apple is solely relying on Moore’s law for future advances because, with the way these processors are designed, external infrastructure would wreck performance.
The unified memory does go to great lengths to make memory not such an issue. It also pages a ton. I’ve read that people can throw up hundreds of tabs in safari on the 8GB model and be just fine.
The claims were fastest per-core performance, not fastest absolute performance in a single system. Heck, there are desktops out there with hundreds of cores in them, drawing hundreds of watts of power. I haven't had time to delve into most of these benchmarks, but they look multithreaded to me.
Well, the "programmers" in operating system and embedded domains are usually electrical engineers who learned how to write code, just enough to apply their domain knowledge. A programmer in the usual sense, that is someone graduated from pure software school, will have a hard time competing with those people.
I am sorry. English is not my mother tongue so it came off wrong. I didnt think the sentence was bizarre. It just resonated with me so much , maybe because currently I am involved as a programmer in a project where if I had more domain knowledge, my life would be so much better and I would be able to take initiatives a lot more. And I just got a feeling of a need to support your work. I called it bizarre, because at the moment it seemed too sudden. Looking forward to the complete text. Nice work :)
Hi, I would love to hear your feedback. It is the style or the correctness? I am really appreciate if you can show me the few incorrect usages of the grammar.
Yes, I'm not native. For that reason I tried to use simple grammar and sentences, and did go through paragraph by paragraph through a grammar checker until the end of chapter 4. I will try to improve it gradually.
It is better to proof read for correctness. I myself want to point out few grammatical stuffs and looking for the source in Github. You can simple create a repo or add the source text to the current repo, so that people can easily fix these issues for you by giving pull requests.
You don't want people judging this excellent book based on few language quirks here and there.
Thanks. I will upload the source soon. As it is written in Lyx, not sure everyone will find it comfortable though. You can always open an issue in the meantime though.
Great. I just created an issue. You might want to create few guidelines in the repo for creating patches regarding typo/grammatical issues so that you can focus on the actual content of the book. Nice job with the book.
Just curious why you chose Lyx and not Org, for example. I still have your "emacs mini manual" open in my browser all the time, so I'm sure you feel natural in org-mode too.
Well, Org is suitable for small notes. But for the scope of this book, it's difficult to make Org work for such a complex layout (largely because I don't want to mess with the CSS).
I used Lyx because it enabled me to focus on the content without all the markup text. Writing Latex in Emacs can reduce the distraction, but not enough. I just wanted to focus on the content at the time. Learning Latex is difficult enough, learning how to use the major mode at the same time doubles the difficulty.
Obviously, I still use Emacs daily for writing code and other things. Just not for writing book.
Regular spellchecker can correct mistyped words, but not, for example, words miused in a particular context, missing the/a, etc. Try some of those more advanced contextual spellcheckers and proofreaders like Grammarly or LanguageTool.
Why not hire someone in Fiverr to proofread this? Not sure if that is too expensive. Also, have a donate button for someone to donate. Then you can use that money to improve the book. GL!
I feel like it focuses on a lot of linux specific details that a OS agnostic book would when using linux as a 'development environment' definitely wouldn't.
There are many topics other OSes like Windows and Solaris do differently and talking about them even for a little bit would be beneficial, but I haven't seen any trace of it.
Search for Windows, Solaris, shows up nothing, and search for unix shows a single page about unix signals.
It is complete, if you finish the first 2 parts, which consists of 8 chapters. Then you can work on your own by reading the Intel manual volume 3 "System Programming Guide", or learning from OSDev wiki. The first two parts provide a foundation to use such resources, which I think is more important than a step by step guiding how to write an OS.
The problem is that the guide is out of date in terms of toolchain, and you need to figure out many things by yourself, especially if you want to develop on Linux. My book helps you to understand how to learn and write x86 with Intel manuals (this is really important!), understand how to craft a custom ELF binary that is debuggable on bare metal, which in turn requires you to understand a bit of how debugger works.
Once you get gdb working, it is much easier to learn how to write an operating system.
Oh, good to know! I'll keep that in mind and keep a bookmark of your book and your implementation.
Actually, I wanted to start writing an OS by following the BrokenThorn tutorial and was quite naive. After reading some pages it came to me that I don't know much assembly and so I started learning from Jeff Duntemanns Assembly book [1]. As far as I can see, your book also teaches the basics of assembly, it seems more friendly to beginners. Maybe it will be a better start for me. Thanks for putting in the hard work!
Author here. Yes, it's a x86 operating system. However, rather than getting around A20, it focused on protected mode instead.
The book not only teaches x86, but how to use the official resources from the hardware manufacturer to write the OS. In sum, a reader when reaching part 3 for writing the OS, he will need to use the official document, in this case, the "System Programming Guide" manual from Intel to write C code that complies with the documents. Once he learned how to do so, learning other platforms will be much easier given how complex x86 is.
> Author here. Yes, it's a x86 operating system. However, rather than getting around A20, it focused on protected mode instead.
You still have to open the A20 gate in the bootloader if you want to access a memory adress that has bit 20 (counting from 0) be set to 1 (you probably want) - even if you switch to protected mode. The only exception is if you boot from UEFI instead of BIOS - in this case the A20 gate is already set. But the book uses BIOS as far as I see it.
"In protected mode, the IA-32 architecture provides a normal physical address space of 4 GBytes (2 32 bytes). This
is the address space that the processor can address on its address bus. This address space is flat (unsegmented),
with addresses ranging continuously from 0 to FFFFFFFFH. This physical address space can be mapped to read-
write memory, read-only memory, and memory mapped I/O. The memory mapping facilities described in this
chapter can be used to divide this physical memory up into segments and/or pages."
It correlates to my experience of developing in protected mode in QEMU. Once entered protected mode, I can access to any address above 0x10000 without being wrapped around. When I was writing my first kernel (https://github.com/tuhdo/os-study) in real-mode, indeed A20 must be enabled.
The A20 gate would affect both real and protected mode, so to be truely compliant, you should be opening it even for a protected mode OS. It was originally a purely hardware hack forcing an address line(A20, or the 21st address line) to stay low, thus "wrapping" addresses from 1mb-2mb to 0-1mb, so it would have affected real or protected mode identically. On modern hardware, there is a chance that A20 is (against the accepted spec) default open, or possible not implemented.
> On modern hardware, there is a chance that A20 is (against the accepted spec) default open, or possible not implemented.
To nitpick on this a little bit (consider it as a polite supplement):
In Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 3 (3A, 3B, 3C & 3D):
System Programming Guide
in section
8.7.13.4 External Signal Compatibility
one can read (emphasis by me):
"A20M# pin — On an IA-32 processor, the A20M# pin is typically provided for compatibility with the Intel 286
processor. Asserting this pin causes bit 20 of the physical address to be masked (forced to zero) for all external
bus memory accesses. Processors supporting Intel Hyper-Threading Technology provide one A20M# pin, which
affects the operation of both logical processors within the physical processor.
The functionality of A20M# is used primarily by older operating systems and not used by modern operating
systems. On newer Intel 64 processors, A20M# may be absent.".
TLDR: The accepted spec is that A20M# might not exist.
fair point, I hadn't bothered to look more, but it's still true that A20(when implemented) gates both real and protected modes, and therefore "ignoring it to focus on protected mode" is invalid
