4 ms·

Apps aren't the entire computing universe. There are probably dozens of processors in the room with you right now, in everything from your smartwatch to your mo

Apps aren't the entire computing universe. There are probably dozens of processors in the room with you right now, in everything from your smartwatch to your monitor to your thermostat to multiple components within your laptop/phone, each running firmware that somebody had to write in a more constrained way than apps can get away with. It's the "dark matter" of computing, but it's not narrow at all.

jcelerier 7y ago
I do some work in embedded myself but vehemently disagree with that. Only very small parts of embedded systems need zero-alloc policies. Hell, I know people succesfully using new / delete on arduinos and the like. I taught a bit at uni and you can't imagine the amount of students who read stuff like parent comment's "it's common to not use malloc" on internet and then try to apply this as a mantra to their codebase when the assignment is to make a freakin snake game with SDL and write actually legible code - the immense majority of them will never ever encounter any realtime problem and don't need to think that this is an actually common thing - it is not ! This is doing a disservice to the whole profession. If you actually need to program real-time systems, you will have processes in place to ensure that things don't end up in a syscall - or just don't have malloc at all available in which case the problem does not exist.
kllrnohj 7y ago
My smartwatch runs a fat Java stack. My thermostat runs full fat Linux stack with a ton of services. My lightbulb runs fucking HTTP server for its REST API that controls it. None of this is operates in any way remotely close to "malloc up front and never touch again." Nor do they operate with any sort of significant constraints vs. the typical app. There are definitely things that do that. But even in the world of embedded it's a subset of things that do that. Heck, the most software-constrained thing I have is probably the controller in my monitor. But then again that also runs Altera Arria V GX FPGA with 768MB of DDR3 RAM, which also definitely classifies as a niche area with highly specialized demands.

jcelerier 7y ago

I do some work in embedded myself but vehemently disagree with that. Only very small parts of embedded systems need zero-alloc policies. Hell, I know people succesfully using new / delete on arduinos and the like. I taught a bit at uni and you can't imagine the amount of students who read stuff like parent comment's "it's common to not use malloc" on internet and then try to apply this as a mantra to their codebase when the assignment is to make a freakin snake game with SDL and write actually legible code - the immense majority of them will never ever encounter any realtime problem and don't need to think that this is an actually common thing - it is not ! This is doing a disservice to the whole profession. If you actually need to program real-time systems, you will have processes in place to ensure that things don't end up in a syscall - or just don't have malloc at all available in which case the problem does not exist.

kllrnohj 7y ago

My smartwatch runs a fat Java stack. My thermostat runs full fat Linux stack with a ton of services. My lightbulb runs fucking HTTP server for its REST API that controls it. None of this is operates in any way remotely close to "malloc up front and never touch again." Nor do they operate with any sort of significant constraints vs. the typical app. There are definitely things that do that. But even in the world of embedded it's a subset of things that do that. Heck, the most software-constrained thing I have is probably the controller in my monitor. But then again that also runs Altera Arria V GX FPGA with 768MB of DDR3 RAM, which also definitely classifies as a niche area with highly specialized demands.