|
Nowadays very few people read books. They will prefer to watch a set of YouTube videos and consider themselves as experts.
|
|
|
|
|
Amarnath S wrote: They will prefer to watch a set of YouTube videos and consider themselves as experts.
I know...  Alas!
|
|
|
|
|
Amarnath S wrote: They will prefer to watch a set of YouTube videos
I do it for woodworking
Amarnath S wrote: consider themselves as experts.
that's not what my fingers show...  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
And some use to read the book and consider themselves an expert. And even more so they would write a book and then proclaim themselves and expert (and force their students to buy it.)
The source of the knowledge doesn't matter as long as learning can take place.
|
|
|
|
|
Another perspective is that it often makes sense to think in terms of cross platform, for desktop applications. (I refuse to use the word "app" for desktop  )
VS Code and Slack are two such widespread applications (written in Electron). Another approach is Qt. I think the Xamarin framework was around, but might be dead? Google have their own such framework (JS based just like Electron), the name evades me.
Of course, if you want to learn Linux, such options will not help, so maybe I am just speaking into to void here.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
|
Saying this with tongue in cheek  Ask ChatGPT to write the book, seems everyone else does. Hopefully it learned from some old scripts and might give a good example OR, it might all be bull$#% like every other return it gives... Just joking!
|
|
|
|
|
Following is a link from the Code Project newsletter.
Value-Oriented Programming[^]
Besides being a bit long (academic journal so of course) it does have quite a bit about language maintaining 'safety'. If you are not familiar and do not want to read the article, think of it as the problem with using a pointer which is null when you expect it to be not null. Since that is the one most talked about.
Although the article does have an example about 'int' overflow in C++. Which doesn't seem like a great example to me.
Myself language problems have not been a significant source of problems since in the 90s. And that was once I learned to always initialize pointers (C++) and then when reviewing code insist that others do the same. Numeric overflow was sometimes considered but has always been found to not ever to be a problem (I even dealt with the analysis of one of in the recent past - it could never be a problem.)
Now following is a list of the problems that I do deal with. And have been dealing with for decades.
1. Failures in design.
2. Failures in requirements.
3. Failures in customer expectation management.
4. Failures is misunderstandings (or total ignorance) about what some change might do.
5. Failures caused by complexity in massive systems. And sometimes not so massive.
6. Failures caused by prioritization (so same problem comes up and is never fixed even when fix is known.)
7. Failures caused by programmers implementing something and either explicitly ignoring stuff either in the code base or in the domain space (very often associated with databases and/or any network protocol.)
There are probably some others.
Now myself I just go in every day hoping that the most complicated new thing that I must prioritize immediately is a null pointer exception. Because those are easy to find and fix.
I haven't worked in the same business domain either. But perhaps it is because I have only been working with C# and Java since the 90's (mostly)?
Do others find that they must spend all of their time fixing null pointer errors and numeric overflows?
|
|
|
|
|
The answer to your question is unequivocally YES. I can say that because every cyber-vulnerability is ultimately a failure of safety as elucidated in the article.
|
|
|
|
|
obermd wrote: because every cyber-vulnerability is ultimately a failure of safety
I don't see the reference. The word "cyber" does not appear in the article at all. Nor does security.
And as I read it is discussing safety as an attribute of a programming language and not how the programming language is used.
As a counter example as far as I can recall most of the security problems related to SSL over the years had to do either with design or implementation. And not anything like a null pointer exception (could be some but not most.)
|
|
|
|
|
just yesterday i dealt w/ a value problem (C++) . i was maintaining references to items stored in a vector via push_back() i.e. the items not the references were in the vector . i expected the references to still be valid since i was pushing back and not altering anything in the vector . oops . my mistake . it took a while to finally discover the vector size was being altered w/ each push_back . the fix was easy i.e. to wit merely set the initial capacity to a large number . recently i've been encountering a number of "tell my grandchildren about" kind of bugs . this may be one of them . another was due to merely omitting a "_" character in a file name . others i have yet to figure out as they disappeared on their own . i am assuming one of those was Explorer changing its mind .
|
|
|
|
|
Contrariwise, safety is not a problem. 
|
|
|
|
|
I really want to get into low-level programming and understand OS. How can I get myself into it? Like is there some material you know that it could be interesting to start designing basic OS such as MINIX or programming an ESP8266 board?
|
|
|
|
|
|
At the heart of it all... an OS is basically a kernel with a ton of crap rolled out on top of that. The kernel is the brain with direct access to hardware. All things (including drivers) feed into the brain. Depending on how your brain is designed drivers may or may not have direct access to hardware however.
Over simplified, but...
Power On > BIOS/UEFI > POST > MBR/GPT > Boot Loader > Kernel
Once your kernel is loaded. You control the whole thing. As far as kernel design, IMO a good start would be to go back to the early versions of the Linux kernel and start looking at its source code for ideas.
Jeremy Falcon
modified 9-Feb-23 15:37pm.
|
|
|
|
|
Presumably you already know the programming language C. If you know C++ you can use that as a starting point but you will probably need to learn about C.
Realistically you should probably expect to become familiar with linux. Several reasons for that including that all of the source code is available and you can get very small versions thus less for you to look at.
Pick one of the following and look at the code and attempt to write your own.
- Read a hard drive directly. Not files, but the 'sectors' on the drive.
- Write a device driver and figure out how to plug it into your existing OS. Getting the OS to recognize a USB with your driver (not existing one) would keep you busy for a while. Alternatively you can get a serial port card and there are projects you can find with that.
- A simpler task is to read up on memory management and then write your own version. This includes using low level OS APIs to allocate memory from the existing OS.
- Learn some assembly. Then write something. Doesn't need to do much. Then learn how to interface assembly with C. There are at least 3 ways that I can think of that do that.
|
|
|
|
|
Find the smallest code base.
As much as I love QNX, it is not small. You want to learn mastering the CPU first, then learn about hardware-drivers. Then, you start with the smallest you can find.
You focus on getting it to work, not on having it run on any CPU. Make it work.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
I had a class on OS design in college and the labs and textbook used MINIX. It's as good a place as any to start learning.
There is a textbook on OS design using MINIX here: Operating Systems: Design and Implementation[^]
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do.
- Bill Watterson (Calvin & Hobbes)
|
|
|
|
|
Just saw this post and I think a great place to start is with Linux (systems programming) and understanding what the OS does. It'll provide a good foundation to maybe later "writing your own little os" -- booting up hardware and running a little kernel of some type.
So, to reiterate, really learn about Linux systems programming because you'll get a lot of understanding the challenges that other devs had to solve.
And to really learn in depth that systems programming take a look at the fantastic book which will guide you through writing programs in Linux, The Linux Programming Interface: A Linux and UNIX System Programming Handbook[^] by Michael Kerrisk.
That book will help you get a foundation so you don't feel overwhelmed by the huge topic of OSes
|
|
|
|
|
There are emulated CPU's with reduced function sets, specifically so you can practice opcode instructions.
You can buy an FPGA board with some basic RAM and a DSP to practice VHDL and low level drivers loaded into RAM, which helps to explain the role of hardware VS machine instructions.
After that you can take a look at actual PC hardware. Do some MASM, some C, some C++ and some C#. Then roll your own "Linux from scratch" and make it compile and run those 4 languages.
That should cover everything, I think. Might take a while though.
|
|
|
|
|
If you start from scratch, master your C and at least some assembler programming in your platform of choice, as it will be needed for some of the startup code.
As for books, I studied on the Silberschatz / Gagne / Galvin Operating Systems Concepts. It is a monster doorstopper of a book and it costs a kidney but it's worth it.
If you start practicing on some embedded stuff with ARM you should be able to see the lowest level of controlling the CPU without much overhead, in this day and age it's definitely simpler than trying to wrestle with full kernels like Linux and it's not expensive.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Well, easy to ask but somewhat hard to answer... I had almost the same question roughly 35 years ago. Here's what I suggest: Read The Design and Implementation of the Unix System V by Maurice Bach. Dive into the sources of Minix 1.5 (the first one leveraging protected mode) and read Tannenbaum's documentation on this OS (I guess that's what Linus did as well before he coded his first kernel...). Read the INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986 to gain an understanding of how HW supports OS design ideas. Sure, these resources are old, but the basic concepts they tell about are still valid. While studying you will certainly encounter new questions, and grasping the answers (with help of Google) will lead you step-by-step into the present of OS design.
|
|
|
|
|
|
Go for books by
Andrew S Tanenbaum
It is *the* book on this subject. I cannot praise it enough.
This guy wanted his students to learn this subject so bad that he wrote an operating system from scratch (Minix, the actual birthplace of Linux).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
