"Since UNIX times delays assuming tabs set every 8, this has become a defacto ‘standard.’"
Oh ...
It is something beautiful over such simple, small and hackable systems like this. Imagine how much control you actually had over your computer.
Oh ...
It is something beautiful over such simple, small and hackable systems like this. Imagine how much control you actually had over your computer.
If you're interested, you may find it easier than you think to program computers instead of scripting UIs or server farms. A hobby or career in OS development can be satisfying and rewarding.
I do believe that I'd easily pick it up (eg. I can easily spot potential races and common problems with async code in other people's code, which is usually the trickiest problem though I'd expect hw bugs to be even worse in low-level stuff), but I am not sure I can sell myself well enough to get a position that matches my skills (since experience is limited).
Other than spending time away from work (which I lack because of the family), do you have any other tips on how to break into the field?
Remote from a EU timezone a requirement :)
Pick up a Nucleo or mbed board and make something cool!
That's currently in conflict with my life circumstances ;-)
The number of "projects" I wish I could do sitting on my shelves already surpasses the time I can find to spend on them.
Basically, I want to be paid to "learn," and I think I'll be fair value in a month or two. So the question is how to get there? ;-)
You can do that, or you can choose to exert some control over the process.
That was actually my real point. For many smaller companies, it will. General programming experience plus any honest signal, even small, of low-level qualification will get you attention. We get lots of generalist candidates for our embedded positions and the #1 easiest high-signal filter for us is "how do we know they're actually interested in embedded?" Pass that, and things can open up for you.
I haven't applied for a lower level dev so far, but it gives me some encouragement to maybe try next time I want to switch positions (though I did work or get offers on some embedded dev shops, but on the web side of things).
Just an observation, but I've almost never seen job postings for entry/junior level engineers in the embedded/systems world. Only senior-staff level roles (I get the feeling that a lot of early career talent in these domains is sourced from local university pipelines). This has been my observation across both small companies and large corporations. Are these shops really considering people who's only experience is some contrived side projects at that level?
for which salary tho. just checked a bit the current offers and in my country, senior embedded engineer is 60k€ / year at most, and I saw a fair bit around 40k€...
That said, I think you are correct in that there are less magic than you think when looking at the surface.
Yeah, unfortunately I thought that I could easily understand modern computers after having played around with the 6502 family a lot. Only to learn that even at the lowest level there's a lot of legacy cruft and decades worth of added abstractions.
e.g., I'm too young to remember the Commodore computers, but it's my understanding that you could change the display colors and sprites by poking a memory address. I'm not advocating for specifically that, modern computers are connected to the Internet and it would be a security disaster, but that kind of interaction with the machine is something that's missing.
Meanwhile there's Raspberry Pi and a whole host of retro-clones out there for cheap, and emulators out there for free. We live in a golden age where all the old stuff is still there if you want it, but you can also download incredibly sophisticated enterprise level development tools at zero cost, and hundreds of pages of tutorials and guides just a Google search away. It's never been easier for kids to get into programming.
* Example from here yesterday https://news.ycombinator.com/item?id=28441563
100% agree, I said it in my comment :)
There's no chance you can get away with unrestricted memory access on a machine that ever talks to any other unknown machine ever, on any protocol and for any reason.
> It's never been easier for kids to get into programming.
I honestly don't know about that. Some things are easier, others are harder. There's no question the amount of quality information out there makes it much easier for someone who wants to learn, but even setting up a development environment is a huge blocker for a complete beginner. Hello world is the hardest program you're ever going to code, it's all downhill from there. And that's where the layers of abstraction are coming back to bite you.
Of course everyone who wants to learn how to program is going to overcome that, most people are just not interested in the first place and it's kind of dumb to assume they'd learn if only the environment were different, etc.
OTOH I wonder if the layers of crap aren't just making it harder for those who are interested.
Lets not fool ourselves, programming has a steep effort-reward curve, maybe even steeper than chess or music instruments. Nowadays it's competing against an infinite supply of deliberately tuned shallow-curved attention seekers like youtube/tiktok videos and app store quasi-games.
The barriers for programming something that other find usefull is way higher today.
However, moving up from there to more powerful systems adds more and more (mostly necessary) complexity: address space isolation for robust multitasking, more complicated busses and attached devices, more asynchonous operations, etc. There is no way to have both true simplicity and the comfort / performance of a modern personal computer.
As far as I know FreeBSD still lets you poke around in /dev/mem, you could make the poor OS have a seizure by doing "sudo dd if=/dev/random of=/dev/mem" last time I tried it. Linux is more restrictive with /dev/mem by default, but I think it can be configured to be more lax if you compile it yourself.
You can still do that in PCs by booting into real mode, OSDev has plenty examples.
The tabs file does predate this, and I'll make a note of that (which is what this article is about).
Modern machines are quite the opposite. It's the current crop of main stream OS's and their associated API's which are to blame, not the hardware designs.
> e.g., I'm too young to remember the Commodore computers, but it's my understanding that you could change the display colors and sprites by poking a memory address.
The commodore 64 was a very simple machine with little memory. Only one program ran at a time so no OS was needed. And the memory registers you poked at was the API as things were very simple back then.
However, you can certainly do the same with modern GPUs[1] but they are so massively complex that the manual for the Intel graphics controllers are well over 1000 pages, some manuals exceeding 2000 pages[2]. For comparison, the manual for the voodoo2 is 132 pages[3].
> I'm not advocating for specifically that, modern computers are connected to the Internet and it would be a security disaster, but that kind of interaction with the machine is something that's missing.
That's why we have an OS to control access to those bits of hardware. The internet has nothing to do with it.
The problem you face is most modern operating systems are massive, bloated even, to the point where the interfaces are buried underneath miles of code. How does one approach a simple hardware project of poke at bitmaps and pixels stored in the Intel GPU from a "modern" Operating system.
The Linux kernel is something like 10% AMD GPU driver code, mostly auto-generated by massive build tools which are as complex as the kernel itself. So no wonder you see the system as narrow, its so massive it blurs into one indistinguishable monolithic blob which gives it that narrow feel.
[1] https://wiki.osdev.org/Accelerated_Graphic_Cards
The Commodore 64 had a simple OS, and it does have all the elements to be called a primitive OS. The features include:
- Devices (0 was the keyboard, 1 was cassette, 2 was RS-232, 3 was the screen, 4-30 were the serial bus where printers and disks lived)
- Uniform I/O calls across those devices (you must OPEN a device, and then can use CHRIN, GETIN, CHROUT, LOAD, SAVE calls to move data, and then you have to CLOSE it).
- Handles (called "logical file numbers", up to 10 open at once supported) - a bit more sophisticated than CP/M really.
- A rudimentary notion of standard input/output (called the "default" input and output device)
But this primitive OS definitely depended upon what could be considered a single background task to read the keyboard (SCNKEY) and update the timer (UDTIM) - triggered by an IRQ that was set to fire off 60 times a second (50 for PAL). Tape I/O overtook this IRQ and messed up the timer though.
However nothing in this primitive OS except for reset routines even acknowledged the presence of the SID chip or features of the VIC beyond the text display, so you were definitely on your own there.
> How does one approach a simple hardware project of poke at bitmaps and pixels stored in the Intel GPU from a "modern" Operating system.
Linux exposes a `/dev/fb0` device, doesn't. Can't you `mmap()` this device and peek/poke to your hearts content, assuming something else isn't trying to write to `/dev/fb0`?