Gender is real, but it is provably not binary. Whether you want to classify those non-binary case as a mutation/disorder or nature running its course is more of a social statement, not a scientific statement.
I try to consider the upside. Can I throw a harness on my dog and call him a "service dog"? Every time I take him out for a walk it's therapy for my gaming addiction. He's very well trained and quite persistent, I'd argue he is essential to my recovery.
The downside is my cat. He also is responsible for some gaming therapy, but I don't want an excuse to have him tethered to me.
I don't think there's anything sneaky about it, it's pretty much done in the open. OS X does this differently than windows (thumbs.db in same folder), but it's not "surreptitious" anymore than memory allocation or hardware initialization is surreptitious.
The news is that the data is not being encrypted if it is located on an encrypted drive (and presumably, the main OS drive is not), and evidently had been a well kept secret that is being revealed now.
Not knowing the definition of the word compulsory is ignorant, not unintelligent. Reading the paragraph and missing the word is careless, not unintelligent. Knowing the word and reading the word and not putting it all together is unintelligent.
Old people today act like the USA is so much more violent and riddled with crime when in reality we have considerably less violence and crime.
They also hate it when you show them the hard data from local police, the FBI, etc. Crime really is very low, but it is against the propaganda campaign. My personal feeling is that we've reached a point where crime is too low. Crime can be the relief valve of an oppressive government, and our corporations do tend to make things fairly oppressive at times.
Now you're just trolling. First you insist on an argument about calling C/C++ from Swift, which is the least interesting topic, performance wise. Step one is to get your C or C++ based engine to call Apple's libraries, either via swift or objective c. That accomplished you can then call C/C++ from your preferred language, whatever it is. I will not assume swift because outside of iOS/OSX I just don't see the interest. I see a lot of python calling C these days.
I agree with you to the extent that calling C from just about anything does not need to bring on overhead. C is the most minimal option out there short of writing assembly code, and thus calling libraries with C calling conventions would not invoke any overhead that isn't brought on by the language you call it from. C++ is worse, and can be quite not-ideal if you designed your class hierarchy poorly, but again is as minimal as object orientation gets. What you choose to run from that part is your business, and I'm not going to tell you it's right or wrong.
And second, you're wrong. Absolutely there is a performance hit if, to call a module in another language, with different calling conventions, more code is injected. And that happens calling objective C where, for example, method calls generate an objc_msgSend (or variant); a function which stands in place of the desired function. Possibly not a big deal depending on your object hierarchy, or when making very infrequent high level calls, it absolutely is important in a performance critical inner loop. Objective C does not have to "dislike" being called by C, it is simply less efficient. That necessarily has to be built into your binary when calling obj-c libraries.
Having learned swift just enough to see how objects and methods work, there is no question that if I call it from C or C++, there's going to be substantial overhead to obey the calling convention that swift must need to do what it does in all but the most trivial case of a static function with no arguments. I don't think anyone has data to measure the performance overhead here since there is not yet any easy way to do this. My argument is simply this: why even have this conversation? It's virtually certain that the Metal libraries were written in C, that's what systems programmers continue to use precisely because it is low level. So expose the API as standard C. Tie a nice bow around it in ObjectiveC/Swift for those devoted to those languages, and let's stop arguing about it.
This is the opposite of what is needed. If you have your favorite high level graphics engine (not necessarily Unity or Unreal, if you're a small indy), it's probably in C++, sometimes plain old C. The good ones have abstracted the underlying OpenGL/DirectX interaction, so if you want to support Metal, which you really might wish to do, you have to figure out how to call it. It's designed to be called from Swift. You're not going to rewrite your entire engine in Swift just to support OS X, which isn't the world's preferred gaming platform.
You can write a wrapper around the objective-C bindings and get some very iffy performance. Then maybe someone follows your advice and writes their swift code around your C++ engine for some extra performance loss.
It's not a great solution, and while it may help coddle some app developers who don't understand how computers really work, the fact is computers have not magically changed how they work and all that is being done here is adding a layer of presumptive code that you may or may not really need.
Chief, in my opinion, amongst its many problems is that it's a standard without any form of independent regulatory or licensing body to render verdict on the thousands of devices out there are "compliant" or "not compliant". When I was still doing hardware development, no one wanted to touch USB, it is such a nest of hard problems and impossible solutions. Even things as simple as memory keys might, or might not work on a given host controller and/or with a given version of an operating system. Most of them provably did not obey the electrical spec (pirate code?), but that's ok because most laptops out there did not either, creating some fun and dangerous scenarios which I'm not going to outline here.
And the electrical spec was at least simple to read. The protocol and software spec is much more involved and implementations varied even more wildly.
At the core USB is like it is to ensure a wide ecosystem of cheap components that was all inclusive, and could be easy made in any cheap shop in China. Possibly this is good, in that it ensures access to small and large outfits equally, and in a place like china where one US cent is a big deal, it let everyone in. On the other hand, sometimes that corner you cut shouldn't have been cut and while the device may "work" it doesn't actually work as intended, across the board. And so other standards would require you have your device tested and certified, and made to work as intended. That doesn't really exist for USB. People throw the logo on and launch their stuff out there without any consideration. Then when it doesn't work, they say it's not compatible with X or Y. To a customer, we're left with "what the fuck, is it USB or not?".
Most programmers aren't going to write directly against a graphics API either, but those APIs are typically consumed by big engines that are written in C/C++, for good reasons, and it is hard to write swift that calls C/C++ and vice versa.
Near as I can tell this is one of two purposes. The other purpose is that many "app" developers are not professional programmers.
Anyway, the lack of support for C/C++ is going to hurt them in the long run, probably not even that long run. For example if they want to improve Metal adoption, they probably need to get C support out there soonest.
There are plenty of languages out there that address one concern or another that various types of programmers have or don't want to deal with, and C/C++ support ensures that any gaps in that language can be filled with a compiled in module they can almost forget about. Swift isn't doing anything really that useful except being not-C++.
I don't want C# or Swift, I have better ways to waste my time.
Unfortunately I do not know Ivanka's phone number, I might be able to convince her that net neutrality means she can reach more working moms like herself, but she needs to act now.
Most of the games I played as a teen would these days have been rated 17+, the criteria has really dropped to the point of making ratings worthless. I will not let my 10 year old play (some of) them (ex. Witcher 3), but others I don't really care about. I do not rely on Steam or anything else to make that call, I tell him what he may and may not play. That's the only real solution, parents have to parent, the end. You cannot outsource that job.
That said, the games I most often boycott are not rated MA at all. They simply enable communication with strangers on the internet. Those are banned completely, but it is surprising how many of them are out there. You are way, way likely to be exposed to the most vile forms of racism, horrible and demeaning sex acts, terrible descriptions of violence and just about every other normally censorable topic via the chat systems than you are from the games themselves, which are usually geared toward entertainment. There are lines games do not cross, but people will.
It's a fair criticism that youtube is one of the absolute worst, and it's fairly impossible and self-defeated to ban that, but the benefits outweigh the risks, and normally hte comment section gets ignored. But the point remains: it is the social part of gaming that lately is the most terrible.
So how hard would it be to have the Tesla's computer not even turn on the autopilot if they're not on a road with center divider and clear lane markings
It will hand off to the driver if it does not detect clear lane markings already, I've tested this myself. The FUD is, who can say for certain that their AI performs equally well in all situations? No one. So far though, it's been humans behaving badly.
A system like this needs good statistics, none of which have been published (and possibly don't exist).
And airplane autopilot has been a contributing factor in a number of airline crashes. However those are usually blamed on the human who failed to use them properly.
It is definitely worse, I ignore it entirely at this point. I would also stop using Github for different reasons, just on principle. MS needs to slink off into the night and be happy with its monopoly on dumb users who need invasive IT support.
Slashdot Mirror
Don't confuse this shit with science.
Gender is real, but it is provably not binary. Whether you want to classify those non-binary case as a mutation/disorder or nature running its course is more of a social statement, not a scientific statement.
I try to consider the upside. Can I throw a harness on my dog and call him a "service dog"? Every time I take him out for a walk it's therapy for my gaming addiction. He's very well trained and quite persistent, I'd argue he is essential to my recovery.
The downside is my cat. He also is responsible for some gaming therapy, but I don't want an excuse to have him tethered to me.
I don't think there's anything sneaky about it, it's pretty much done in the open. OS X does this differently than windows (thumbs.db in same folder), but it's not "surreptitious" anymore than memory allocation or hardware initialization is surreptitious.
The news is that the data is not being encrypted if it is located on an encrypted drive (and presumably, the main OS drive is not), and evidently had been a well kept secret that is being revealed now.
Not knowing the definition of the word compulsory is ignorant, not unintelligent. Reading the paragraph and missing the word is careless, not unintelligent. Knowing the word and reading the word and not putting it all together is unintelligent.
It's not clear what he's guilty of here.
Old people today act like the USA is so much more violent and riddled with crime when in reality we have considerably less violence and crime.
They also hate it when you show them the hard data from local police, the FBI, etc. Crime really is very low, but it is against the propaganda campaign. My personal feeling is that we've reached a point where crime is too low. Crime can be the relief valve of an oppressive government, and our corporations do tend to make things fairly oppressive at times.
90% seems like a somewhat conservative estimate on the invalidity of social sciences.
iOS being touch based, not really multi-tasking, and without the most important feature: the command line, would really blow.
Are you high, or off your meds?
Now you're just trolling. First you insist on an argument about calling C/C++ from Swift, which is the least interesting topic, performance wise. Step one is to get your C or C++ based engine to call Apple's libraries, either via swift or objective c. That accomplished you can then call C/C++ from your preferred language, whatever it is. I will not assume swift because outside of iOS/OSX I just don't see the interest. I see a lot of python calling C these days.
I agree with you to the extent that calling C from just about anything does not need to bring on overhead. C is the most minimal option out there short of writing assembly code, and thus calling libraries with C calling conventions would not invoke any overhead that isn't brought on by the language you call it from. C++ is worse, and can be quite not-ideal if you designed your class hierarchy poorly, but again is as minimal as object orientation gets. What you choose to run from that part is your business, and I'm not going to tell you it's right or wrong.
And second, you're wrong. Absolutely there is a performance hit if, to call a module in another language, with different calling conventions, more code is injected. And that happens calling objective C where, for example, method calls generate an objc_msgSend (or variant); a function which stands in place of the desired function. Possibly not a big deal depending on your object hierarchy, or when making very infrequent high level calls, it absolutely is important in a performance critical inner loop. Objective C does not have to "dislike" being called by C, it is simply less efficient. That necessarily has to be built into your binary when calling obj-c libraries.
Having learned swift just enough to see how objects and methods work, there is no question that if I call it from C or C++, there's going to be substantial overhead to obey the calling convention that swift must need to do what it does in all but the most trivial case of a static function with no arguments. I don't think anyone has data to measure the performance overhead here since there is not yet any easy way to do this. My argument is simply this: why even have this conversation? It's virtually certain that the Metal libraries were written in C, that's what systems programmers continue to use precisely because it is low level. So expose the API as standard C. Tie a nice bow around it in ObjectiveC/Swift for those devoted to those languages, and let's stop arguing about it.
This is the opposite of what is needed. If you have your favorite high level graphics engine (not necessarily Unity or Unreal, if you're a small indy), it's probably in C++, sometimes plain old C. The good ones have abstracted the underlying OpenGL/DirectX interaction, so if you want to support Metal, which you really might wish to do, you have to figure out how to call it. It's designed to be called from Swift. You're not going to rewrite your entire engine in Swift just to support OS X, which isn't the world's preferred gaming platform.
You can write a wrapper around the objective-C bindings and get some very iffy performance. Then maybe someone follows your advice and writes their swift code around your C++ engine for some extra performance loss.
It's not a great solution, and while it may help coddle some app developers who don't understand how computers really work, the fact is computers have not magically changed how they work and all that is being done here is adding a layer of presumptive code that you may or may not really need.
Chief, in my opinion, amongst its many problems is that it's a standard without any form of independent regulatory or licensing body to render verdict on the thousands of devices out there are "compliant" or "not compliant". When I was still doing hardware development, no one wanted to touch USB, it is such a nest of hard problems and impossible solutions. Even things as simple as memory keys might, or might not work on a given host controller and/or with a given version of an operating system. Most of them provably did not obey the electrical spec (pirate code?), but that's ok because most laptops out there did not either, creating some fun and dangerous scenarios which I'm not going to outline here.
And the electrical spec was at least simple to read. The protocol and software spec is much more involved and implementations varied even more wildly.
At the core USB is like it is to ensure a wide ecosystem of cheap components that was all inclusive, and could be easy made in any cheap shop in China. Possibly this is good, in that it ensures access to small and large outfits equally, and in a place like china where one US cent is a big deal, it let everyone in. On the other hand, sometimes that corner you cut shouldn't have been cut and while the device may "work" it doesn't actually work as intended, across the board. And so other standards would require you have your device tested and certified, and made to work as intended. That doesn't really exist for USB. People throw the logo on and launch their stuff out there without any consideration. Then when it doesn't work, they say it's not compatible with X or Y. To a customer, we're left with "what the fuck, is it USB or not?".
Most programmers aren't going to write directly against a graphics API either, but those APIs are typically consumed by big engines that are written in C/C++, for good reasons, and it is hard to write swift that calls C/C++ and vice versa.
Schwifty... in here .
Wubba lubba dub dub.
Near as I can tell this is one of two purposes. The other purpose is that many "app" developers are not professional programmers.
Anyway, the lack of support for C/C++ is going to hurt them in the long run, probably not even that long run. For example if they want to improve Metal adoption, they probably need to get C support out there soonest.
There are plenty of languages out there that address one concern or another that various types of programmers have or don't want to deal with, and C/C++ support ensures that any gaps in that language can be filled with a compiled in module they can almost forget about. Swift isn't doing anything really that useful except being not-C++.
I don't want C# or Swift, I have better ways to waste my time.
Unfortunately I do not know Ivanka's phone number, I might be able to convince her that net neutrality means she can reach more working moms like herself, but she needs to act now.
We can only hope.
Most of the games I played as a teen would these days have been rated 17+, the criteria has really dropped to the point of making ratings worthless. I will not let my 10 year old play (some of) them (ex. Witcher 3), but others I don't really care about. I do not rely on Steam or anything else to make that call, I tell him what he may and may not play. That's the only real solution, parents have to parent, the end. You cannot outsource that job.
That said, the games I most often boycott are not rated MA at all. They simply enable communication with strangers on the internet. Those are banned completely, but it is surprising how many of them are out there. You are way, way likely to be exposed to the most vile forms of racism, horrible and demeaning sex acts, terrible descriptions of violence and just about every other normally censorable topic via the chat systems than you are from the games themselves, which are usually geared toward entertainment. There are lines games do not cross, but people will.
It's a fair criticism that youtube is one of the absolute worst, and it's fairly impossible and self-defeated to ban that, but the benefits outweigh the risks, and normally hte comment section gets ignored. But the point remains: it is the social part of gaming that lately is the most terrible.
The only winning move is not to play.
This movie is about Hand Solo, a totally different kind of Solo adventure, very familiar to /.
This was of course a movie made for streaming. It's almost the definition of not worth a movie theater trip.
Account deleted and code moved to my ec2 instance. Pretty sure MS won't be buying that any time soon.
So how hard would it be to have the Tesla's computer not even turn on the autopilot if they're not on a road with center divider and clear lane markings
It will hand off to the driver if it does not detect clear lane markings already, I've tested this myself. The FUD is, who can say for certain that their AI performs equally well in all situations? No one. So far though, it's been humans behaving badly.
A system like this needs good statistics, none of which have been published (and possibly don't exist).
That's the problem, everyone is guessing. Stop guessing. If you care, get the data.
And airplane autopilot has been a contributing factor in a number of airline crashes. However those are usually blamed on the human who failed to use them properly.
It is definitely worse, I ignore it entirely at this point. I would also stop using Github for different reasons, just on principle. MS needs to slink off into the night and be happy with its monopoly on dumb users who need invasive IT support.