Not going to do a point by point breakdown of that, but, I dread to think of how expensive it would be to get the length of a string if you're considering uint64 sized strings if it were null-terminated.
My point was simply that analogies suck, because they can be flipped around on you.
If you want to continue the analogy, safety features do have costs. Either in R&D, per part costs, performance, etc.
Safety in computing has costs and trade-offs as well. Performance impact is there for managed languages, but modern computers are so much faster than older systems that the safety costs are unimportant for most applications, and the added cost of developer time greatly outweighs the much cheaper systems.
Fair point. If you are careful to not use any of the low level memory allocation functions except in exceptional circumstances, you can easily create modern C++ applications without memory safety issues by sidestepping them entirely.
However, a lot of applications have been developed before these paradigms became common, and I'm sure that a lot of applications have been developed since by developers who didn't know any better or reject them for whatever reason and thus don't use those paradigms.
I guess my critique against C++ is against the older style of C++, the parts that are there for compatibility with C code. And against any codebases that use those.
Did you know that modern cars have more safety features, meaning that you're much less likely to die in a collision in a modern vehicle, due to things such as airbags, seat belts, crumple zones, automated braking, etc.?
Just like modern, higher level languages give developers enough access to much of the system without requiring you to worry as much about memory safety, most car drivers don't need drag racers to get to work.
To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.
I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.
It would have brought a different set of problems, for sure. And we can never know what hundreds of thousands of developers, etc. would have discovered about it. But, it certainly would have made certain classes of issues pretty much non-existent.
Large systems require a lot of developers, and even the best developer can have a bad day and make a mistake that potentially exposes their application to various memory exploits. Sometimes you have to pay the tax of having better developers, more tools, etc. to make the applications safer.
But, in general, as processors get faster, memory amounts in modern computers gets higher, we should move away from such languages except for projects that require them.
True. Part of the issue is that some languages easily lets you develop programs that don't use memory safely. C/C++ easily let you develop applications that violate memory safety.
You have to be constantly vigilant, and everyone else who develops for the same project has to be constantly vigilant. Mistakes will happen, and nothing will call you out on it unless you do extensive memory safety testing or configure and use some tools that help detect common memory safety issues and hope that you catch anything they don't.
I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?
I do believe that there should be serious discussions on when and where AI can be used by companies, individuals and the government - as well as what data that AI is allowed to use.
A good example would be facial recognition systems. Companies keep data in facial recognition databases for their own purposes (eg. recognizing shoplifters, troublemakers, etc.). It's worth discussing the ethical implications of that, and potentially regulating the usage of this information. Same thing goes for Law Enforcement usage of such systems.
I do not personally subscribe to the belief that all usage of AI by specific governments is inherently bad, again it's all about how it's to be used.
I mean, AI is a neutral thing. It is neither good, nor bad.
By that, I mean, it's a tool. Whether or not it's a good thing or bad thing depends on who's using it and your point of view of the person using it. I'm somewhat uncomfortable that AIs are being trained to increase engagement on social media platforms, essentially we're training AI models and using them to make people more addicted to social media. But, at the same time, AI is also used for spam detection, fraud detection, etc.
So, saying that you don't want the "ORANGE MAN" to have access to powerful AIs is not unreasonable if you don't like "ORANGE MAN", or mistrust what they would do with it.
Then, when you tell the company about the exploit, and they ignore it for an entire year, what should you do? At some point, you have an obligation to make the exploit public so that the company is forced to deal with it, instead of letting others who discovered it in private exploit it freely. It's why Google has a responsible disclosure policy that involves telling the company privately for a certain amount of time, then a public disclosure a set number of days after.
The issue is that 5G is actually a set of speed standards that can technically be met with LTE. But, LTE was built to be a 4G platform and isn't going to expand to faster speeds in the future like a new standard built specifically for 5G would - and you really shouldn't buy into a phone as "5G" until whatever replaces LTE is released. AT&T pulled this same crap with 4G, branding things as "4G" because it technically just barely met the standards, well before they rolled out LTE.
Note: I have not read Apple's TOS for their enterprise application deployment.
If it is the case that Apple's enterprise application deployment license dictates that it's only to be used by employees or those being directly supervised by an employee, then, it's certainly fine for apple to ban this application for its flagrant disregard for their own terms. They want to control distribution of apps to the public through their app store, but allow for private distribution within enterprises. Facebook agreed to not try to go around this, but did so anyways.
I mean, Intel still leads in single-threaded performance.
If I have a workload that can be multi-threaded and take advantage of all the cores, though, AMD all the way, especially for the price you're going to pay. Even for mixed workloads that involve some single-threaded and some multi-threaded, it's probably worth considering AMD from a price perspective.
Not all android apps use the dalvik VM. You can create native android applications in c/c++. As well, you might link native libraries even if you're using the dalvik VM.
The base storage itself isn't expandable. Sure, they might have an SD card, but good luck getting windows to use a removable storage device to do windows updates from.
System builders start off with something like this, but they will likely either have access to other tools or use something like ntlite to slim things down.
That ignores that cheap, budget devices are sold with 32GB or 64GB of storage. They aren't expandable. Remember that Windows 10 is _supposed_ to run on more than just high end desktops.
Slashdot Mirror
Not going to do a point by point breakdown of that, but, I dread to think of how expensive it would be to get the length of a string if you're considering uint64 sized strings if it were null-terminated.
My point was simply that analogies suck, because they can be flipped around on you.
If you want to continue the analogy, safety features do have costs. Either in R&D, per part costs, performance, etc.
Safety in computing has costs and trade-offs as well. Performance impact is there for managed languages, but modern computers are so much faster than older systems that the safety costs are unimportant for most applications, and the added cost of developer time greatly outweighs the much cheaper systems.
Fair point. If you are careful to not use any of the low level memory allocation functions except in exceptional circumstances, you can easily create modern C++ applications without memory safety issues by sidestepping them entirely.
However, a lot of applications have been developed before these paradigms became common, and I'm sure that a lot of applications have been developed since by developers who didn't know any better or reject them for whatever reason and thus don't use those paradigms.
I guess my critique against C++ is against the older style of C++, the parts that are there for compatibility with C code. And against any codebases that use those.
Ooh, analogies!
Did you know that modern cars have more safety features, meaning that you're much less likely to die in a collision in a modern vehicle, due to things such as airbags, seat belts, crumple zones, automated braking, etc.?
Just like modern, higher level languages give developers enough access to much of the system without requiring you to worry as much about memory safety, most car drivers don't need drag racers to get to work.
To be fair, a lot of C's early use was to create tools for trusted users that were run from a commandline and typically didn't even need to worry too much about memory, as the OS would deal with clearing up anything the application didn't clear up after it exits.
I'm not sure that the designers could have predicted the rise of the internet, and our globally connected world where inherent trust just isn't applicable.
It would have brought a different set of problems, for sure. And we can never know what hundreds of thousands of developers, etc. would have discovered about it. But, it certainly would have made certain classes of issues pretty much non-existent.
Large systems require a lot of developers, and even the best developer can have a bad day and make a mistake that potentially exposes their application to various memory exploits. Sometimes you have to pay the tax of having better developers, more tools, etc. to make the applications safer.
But, in general, as processors get faster, memory amounts in modern computers gets higher, we should move away from such languages except for projects that require them.
True. Part of the issue is that some languages easily lets you develop programs that don't use memory safely. C/C++ easily let you develop applications that violate memory safety.
You have to be constantly vigilant, and everyone else who develops for the same project has to be constantly vigilant. Mistakes will happen, and nothing will call you out on it unless you do extensive memory safety testing or configure and use some tools that help detect common memory safety issues and hope that you catch anything they don't.
I wonder how much the people who designed the C string (string of characters, implicitly terminated by a null) knew of its potential issues in the long term, and if they would have gone with ptr+length instead if they knew?
I do believe that there should be serious discussions on when and where AI can be used by companies, individuals and the government - as well as what data that AI is allowed to use.
A good example would be facial recognition systems. Companies keep data in facial recognition databases for their own purposes (eg. recognizing shoplifters, troublemakers, etc.). It's worth discussing the ethical implications of that, and potentially regulating the usage of this information. Same thing goes for Law Enforcement usage of such systems.
I do not personally subscribe to the belief that all usage of AI by specific governments is inherently bad, again it's all about how it's to be used.
I mean, AI is a neutral thing. It is neither good, nor bad.
By that, I mean, it's a tool. Whether or not it's a good thing or bad thing depends on who's using it and your point of view of the person using it. I'm somewhat uncomfortable that AIs are being trained to increase engagement on social media platforms, essentially we're training AI models and using them to make people more addicted to social media. But, at the same time, AI is also used for spam detection, fraud detection, etc.
So, saying that you don't want the "ORANGE MAN" to have access to powerful AIs is not unreasonable if you don't like "ORANGE MAN", or mistrust what they would do with it.
Then, when you tell the company about the exploit, and they ignore it for an entire year, what should you do? At some point, you have an obligation to make the exploit public so that the company is forced to deal with it, instead of letting others who discovered it in private exploit it freely. It's why Google has a responsible disclosure policy that involves telling the company privately for a certain amount of time, then a public disclosure a set number of days after.
Indeed. In fact, there's some evidence that coins are being transferred out of some of the "cold" wallets. https://cointelegraph.com/news...
The issue is that 5G is actually a set of speed standards that can technically be met with LTE. But, LTE was built to be a 4G platform and isn't going to expand to faster speeds in the future like a new standard built specifically for 5G would - and you really shouldn't buy into a phone as "5G" until whatever replaces LTE is released. AT&T pulled this same crap with 4G, branding things as "4G" because it technically just barely met the standards, well before they rolled out LTE.
Wow. Biased post much?
Note: I have not read Apple's TOS for their enterprise application deployment.
If it is the case that Apple's enterprise application deployment license dictates that it's only to be used by employees or those being directly supervised by an employee, then, it's certainly fine for apple to ban this application for its flagrant disregard for their own terms. They want to control distribution of apps to the public through their app store, but allow for private distribution within enterprises. Facebook agreed to not try to go around this, but did so anyways.
Why so many lies to the FBI if there was nothing to hide?
"Stuff that matters". I'd say that big politics is stuff that matters.
GPL is infectious. And restrictive.
I will not release anything under any GPL variant, and I do not use GPL licensed things if I can avoid it due to the licensing headache it creates.
I mean, Intel still leads in single-threaded performance.
If I have a workload that can be multi-threaded and take advantage of all the cores, though, AMD all the way, especially for the price you're going to pay. Even for mixed workloads that involve some single-threaded and some multi-threaded, it's probably worth considering AMD from a price perspective.
Not all android apps use the dalvik VM. You can create native android applications in c/c++. As well, you might link native libraries even if you're using the dalvik VM.
I'm surprised that a scientific endeavor would allow for the potential of contaminating the surface with live biological samples.
Regardless if there ever were anything on the moon, this makes studying that harder by its very existence.
Also, we've already done zero-g growth experiments, what value did this add? It's not like the lander sourced soil and water for this.
The base storage itself isn't expandable. Sure, they might have an SD card, but good luck getting windows to use a removable storage device to do windows updates from.
Worth looking at something like ntlite.
https://docs.microsoft.com/en-...
System builders start off with something like this, but they will likely either have access to other tools or use something like ntlite to slim things down.
That ignores that cheap, budget devices are sold with 32GB or 64GB of storage. They aren't expandable. Remember that Windows 10 is _supposed_ to run on more than just high end desktops.