3 ms·

Sure, I do. I am just hooking linux kernel calls, I will never take JS for this. Pure C. Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which re

by stiray 7y ago

Sure, I do. I am just hooking linux kernel calls, I will never take JS for this. Pure C. Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this. But seriously, would you give JS developer making kernel module? Ruby? PHP? No. So I wont compare with them and I would expect they would stop comparing to C. It is not the same task they are made for. I am sick of constant moaning about who is faster and who is better and who is cutter,... System language? Make it. I dont care, if it will work better than C for the task, I will take it. If it is just a newage nonsense wasting resources for the sake of deallocating and taking care about buffer boundaries as it is so hard to take care and track your memory I will skip it. I dont care if I take a hammer or brick for using a nail, I will use what works best and my requirement is that I dont need 20 people to hammer in one nail for the sake of no one getting hurt due to putting its finger between hammer and nail. Someone would rather have a safety inspection. Also a fine decision as far as I care. Not my choice but I couldnt care less. --- Anyway, kids, downvoting me to censor what you cant handle, I am over 40 years old, developing for my whole my life. I have seen hypes, new "revolutionary" ideas, repacking old technologies as new, stealing ideas (I see this lately 24/7) at least 20 new "revolutionary" languages, cpus, mainframes, clouds, any possible way of another human trying to rip you off (google, fb,...), lies, deceit, preaching, evangelism,... Do you really think I will care about it? It is just sorry truth that you will have fun of enjoying kernels written in JS on a browser, on a linux kernel that no one develops any more. Have you seen movie Idiocracy? You really should. I cant wait for it to happen. And then will I ask you if you are sorry, that 20 years back you didnt rather decide to learn instead of copy/pasting and spitting over everything you are unable to handle. (your parent should told you that, but they didnt, I am sorry) ---- saagarjha: sure, ignore the part about censoring, that is not part of debate. About everything else. You get used to it in a same manner as using floats in js. But this is my expirience. It is completely ok, to have different one. Some people are memorizing decks of cards, i consider that something difficult. They probably dont. They have learned to do it. And I am so sorry if dont feel like I need to prove it to you. Anyway, thank you for the cycript.org link, the only problem is that i cant use userspace solution, but it might come handy some day.

saagarjha 7y ago
I'm just going to respond to the top part of your post, as it's at least somewhat relevant rather than being a disconnected rant about the kids censoring you. > I am just hooking linux kernel calls, I will never take JS for this. Pure C. Why not? Hooking native code in other languages is already fairly common: http://www.cycript.org http://www.cycript.org > Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this. Valgrind does significantly more checks than your solution. > System language? Make it. "Systems language" is a very ill-defined term, often used to gatekeep people. > If it is just a newage nonsense wasting resources for the sake of deallocating and taking care about buffer boundaries as it is so hard to take care and track your memory I will skip it. Keeping track of your memory is hard. If you say "no, it's easy for me", I'd like to see a non-trivial sample of your code that doesn't have memory safety issues.
- ncmncm 7y ago
  It is easy for engineers, because engineers are trained to make things correctly even when that is inconvenient. Engineers make bridges that don't collapse (unless not maintained for decades) and planes that don't fall from the sky (unless overruled by management). By the evidence, it is not easy for people who just can't be bothered to take the time to make anything correctly. So, there are languages for engineers to use to make things where it matters if they are right, and languages for everybody else, where apparently it doesn't. Now, all we need is for engineers not to need to call into libraries not written by engineers.
  - wasted_intel 7y ago
    > it is not easy for people who just can't be bothered to take the time to make anything correctly Laziness may make the problem more likely, but even a disciplined team working on security-critical software can make mistakes[0]. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777

by stiray 7y ago

saagarjha 7y ago

I'm just going to respond to the top part of your post, as it's at least somewhat relevant rather than being a disconnected rant about the kids censoring you. > I am just hooking linux kernel calls, I will never take JS for this. Pure C. Why not? Hooking native code in other languages is already fairly common: http://www.cycript.org http://www.cycript.org > Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger buffer with guards at beginning and the end while after 25 years of C I hardly do anything more problematic that this. Valgrind does significantly more checks than your solution. > System language? Make it. "Systems language" is a very ill-defined term, often used to gatekeep people. > If it is just a newage nonsense wasting resources for the sake of deallocating and taking care about buffer boundaries as it is so hard to take care and track your memory I will skip it. Keeping track of your memory is hard. If you say "no, it's easy for me", I'd like to see a non-trivial sample of your code that doesn't have memory safety issues.

ncmncm 7y ago
It is easy for engineers, because engineers are trained to make things correctly even when that is inconvenient. Engineers make bridges that don't collapse (unless not maintained for decades) and planes that don't fall from the sky (unless overruled by management). By the evidence, it is not easy for people who just can't be bothered to take the time to make anything correctly. So, there are languages for engineers to use to make things where it matters if they are right, and languages for everybody else, where apparently it doesn't. Now, all we need is for engineers not to need to call into libraries not written by engineers.
- wasted_intel 7y ago
  > it is not easy for people who just can't be bothered to take the time to make anything correctly Laziness may make the problem more likely, but even a disciplined team working on security-critical software can make mistakes[0]. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777