Earlier quoted context omitted.
But if the goal of the rewrite is safer tooling then Rust wins.
Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages. When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".
Remote code execution, git, and OS X
261–270 of 385 posts
Re: Remote code execution, git, and OS X
#262Remember when I said El Capitan? Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths. Not even root is enough to do it. Can someone explain it to me?
Re: Remote code execution, git, and OS X
#263Earlier quoted context omitted.
There are many arguments to be made in favor of C++, such as talent availability, experience from other porting projects, the possibility of doing incremental porting, etc. My impression is that some projects are already experimenting with or using C++ in their C code bases, so C to C++ is quite likely.
But if the goal of the rewrite is safer tooling then Rust wins.
Otherwise yes, it could even be rewritten in Ruby, as falcolas suggested...
Re: Remote code execution, git, and OS X
#264Earlier quoted context omitted.
I agree with you, the only problem being that even in 2016 there are shops that prohibit the usage of STL. The real way out is to eventually change to a language where safety is opt-out and not opt-in, like in C++.
C++ is far safer than C precisely for the reasons listed. The standard is safe by default (it's not opt-in). If you want or need backward compatibility with C, then you can use the more error prone C constructs for that. Otherwise, pure C++ code is safe.
I have always been on the C++, in the C vs C++ wars, but I am also aware of all those developers that just code C with a C++ compiler, hence opt-in.
Re: Remote code execution, git, and OS X
#265Earlier quoted context omitted.
Disable it, reboot, fix the problem, reboot again with it enabled. Big f'ing deal. I'm far from a fan of Apple's protectionism, and yet this doesn't seem like anything to be up in arms about.
The core issue is that the system is vulnerable in its default configuration.
Re: Remote code execution, git, and OS X
#266Earlier quoted context omitted.
Claiming this isn't a hoop to jump through is Apple fanboyism at its best.
Really? Talking about how homebrew is pretty painless is "Apple fanboyism at its best?" Sure it's another thing to do, but look at any thread about running Linux on a laptop. How many people are like X laptop runs great you just need to add Y kernel parameter to the boot options. Isn't that a "hoop to jump through" too? Or all of the people fighting to keep their Windows install from upgrading to Windows 10. Isn't th…
Re: Remote code execution, git, and OS X
#267Earlier quoted context omitted.
Claiming this isn't a hoop to jump through is Apple fanboyism at its best.
Would much rather have a system that just worked but required a "hoop to jump through" in order to use git, vs the multitudes of hoops you have to jump to in order to get a Linux desktop system functional in a corporate environment. At home when I'm futzing around I don't mind (and quite enjoy it). But at work I don't have time to diddle my device drivers and OMG the xorg.conf crap I had to deal with in the past that…
Re: Remote code execution, git, and OS X
#268Earlier quoted context omitted.
And as has also been asked - why do they symlink to the /usr/bin directory in the first place then? They have three perfectly reasonable directories they can install into, which is what they recommend that application developers do when installing their software: /Applications /Library /usr/local So why do they feel the need to link git into /usr/bin? They could link it into /usr/local/bin - the $PATH variable includ…
There are no symlinks in /usr/bin, they are wrapper programs determining whether you already have the Command Line Tools or full Xcode installed. If not, they will open dialogs asking you to install these additional software packages.
Re: Remote code execution, git, and OS X
#269Earlier quoted context omitted.
And as has also been asked - why do they symlink to the /usr/bin directory in the first place then? They have three perfectly reasonable directories they can install into, which is what they recommend that application developers do when installing their software: /Applications /Library /usr/local So why do they feel the need to link git into /usr/bin? They could link it into /usr/local/bin - the $PATH variable includ…
There are no symlinks in /usr/bin, they are wrapper programs determining whether you already have the Command Line Tools or full Xcode installed. If not, they will open dialogs asking you to install these additional software packages.
Re: Remote code execution, git, and OS X
#270Earlier quoted context omitted.
Or Python, or Ada, or Ruby, or Go, or Java, or Lisp, or any of the myriad of other memory safe programming languages. When it comes to memory safe languages, your choices do not boil down to "Rust or nothing".
No, in this case it pretty much does boil down to Rust or C++. This is a low-level tool, not a webapp.
Of course, Mercurial gives lie to this assumption.