On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
just the general interfacing with obj-c from swift is a bummer
Really? Huh, I always thought it was "fine, I guess". Got a little annoying when a type didn't bridge exactly how I wanted, but past that it never made me mad at it. I mean more than usual mad at Xcode anyway.
Then again, Python flat-out gives me a headache, so all about taste I guess.
Does it matter if any of those are an object underneath or not? Is that significantly different than any other language with a C based syntax? The stuff like __class__ above is not anything you normally use. If you are, you're probably doing it wrong.
print("Printing the number five: " + 5)
Come on Python. You know what I'm trying to do. You'll let force me to duck type all sorts of crap, but this one is a bridge too far?
"Just use print("Printing the number five: {}".format(5))!"
Oh come on, you were just telling me 5 minutes ago that Java is unnecessarily verbose and clunky!
hippofant on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
It's better in Swift 3, but it's still a mess of needing to know when to use String, CFString, NSString, CFDictionary, Data, NSData, etc. God forbid you have to deal with CoreCrypto and the Security framework, which I was. It's some of the worst documented libraries I've ever used.
On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
It's better in Swift 3, but it's still a mess of needing to know when to use String, CFString, NSString, CFDictionary, Data, NSData, etc. God forbid you have to deal with CoreCrypto and the Security framework, which I was. It's some of the worst documented libraries I've ever used.
Ah yeah, that's true, goes back to that fiddly type bridging I guess. I just assume I'm going to have to check the docs on anything I want to use that I haven't used in the last... 10 minutes anyway, so don't mind needing to refresh which is which so much.
What did bug me was "I know we just released 2.1, but here's 3.0, by the way everything's different now, primarily in subtle ways you're not going to notice until you accidentally break something somewhere."
need to use a popular open source objc framework in a swift project? good luck!!
its harder to use objc in swift than it was to use C++ in objc, which is a little nutty considering objc/swift are basically made by the same entity for the same environment
Jasconius on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
That's actually one of the more annoying things about Swift, that they have no concept of keeping the syntax backwards compatible. Though I guess Swift 4 will be the first version to be a super set of the previous version, so all your Swift 3 code won't have to be changed to compile.
The documentation is the function signature and the text No overview available.. I happen to know that if you drill in to the function in XCode it will take you to the header file, where there is some comment documentation...but outside of that it's trial and error all the way down.
Okay yeah, that's fair, their documentation wavers between "hey this is good!" and "all these tires seem to be on fire", sometimes within the same page. That's above and beyond, though; normally the worst I've run into is how the docs are split between slightly different sites, and sometimes the docs don't match each other.
I never had the framework problem, though, to be honest. Might have just gotten lucky, god knows mileage varies on those things.
it would take them announcing a whole new generation of Foundation and UIKit authored in Swift for me to even consider switching. some sort of sign that ObjC is being literally phased out
Edit: I actually can't put into words how fucking outraged I am by this exploit and some attempts to establish a story line with "Most likely nobody noticed, so no worries.". Fuck. This. Shit.
The examples we're finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to cleanup. I've informed cloudflare what I'm working on. I'm finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We're talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.
Does it matter if any of those are an object underneath or not? Is that significantly different than any other language with a C based syntax? The stuff like __class__ above is not anything you normally use. If you are, you're probably doing it wrong.
print("Printing the number five: " + 5)
Come on Python. You know what I'm trying to do. You'll let force me to duck type all sorts of crap, but this one is a bridge too far?
"Just use print("Printing the number five: {}".format(5))!"
Oh come on, you were just telling me 5 minutes ago that Java is unnecessarily verbose and clunky!
Fair enough on the + 5 bit in that Python should be smart enough to make it work, but even that is more verbose than it needs to be with what Python already provides.
# Py2 with no __future__ imports
# can also %s here if you're lazy like me... I almost always just %s unless I need the number formatting
# You can also wrap that in print() if you are in py3 or have print_function imported... but why would you given the next option
# unless you need the printf style formatting
print "Printing the number %d" % 5
# Py3 and Py2 with __future__ print_function import - like you wanted but you don't even need to type a +
print("Printing the number", 5)
# Python 3.6 has also introduced this
number = 5
print("Printing the number {number}")
If there's anything to complain about with Python string formatting it's that there are too many choices, which is annoying and pretty clearly breaks the "There should be one-- and preferably only one --obvious way to do it." mandate from The Zen of Python. They need to pick something and go with it. The String.format() type formatting also supports named parameters - although obviously more verbose, but if you need to interpolate/format the same variable into a string 5 times it can save typing, although I wouldn't use it with
print "If your name is {name} then I will call you {name}. Alright, {name}".format(name="Bob")
It's more than terrifying. I'm never using anything from that company or from the people involved with it ever again. Those are the same guys that were so proud of running into kernel space and releasing a mitm while making it sound like a service.
It's more than terrifying. I'm never using anything from that company or from the people involved with it ever again. Those are the same guys that were so proud of running into kernel space and releasing a mitm while making it sound like a service.
It's not really your choice to use CloudFlare or not, unless you're just going to stop using the internet.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
It's more than terrifying. I'm never using anything from that company or from the people involved with it ever again. Those are the same guys that were so proud of running into kernel space and releasing a mitm while making it sound like a service.
It's not really your choice to use CloudFlare or not, unless you're just going to stop using the internet.
Mmmm, you do realize that I meant as a business user, right?
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
No, it wasn't.
Oh do we have access to their source and commit history? I'd love to read it actually.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
No, it wasn't.
Oh do we have access to their source and commit history? I'd love to read it actually.
*blink* This is RTL, written in Verilog, for a private company, instantiated on a digital ASIC (chip). It was never public, and it will never be public.
How many ASICs have public sourcecode?
edit: Yeah, there's OpenCores, but that's largely generic stuff like memory controllers, I2C controllers, etc. Apple isn't going to give you the source to the iPhone processor line, and neither is Samsung going to do that for the Exynos chipset. IF you pay a boatload of money, you can instantiate an ARM core on your ASIC, but I'm pretty sure licensing agreements prevent you from putting the source out there. RTL is a whole other world and is nothing like web work. In this case, the chip contains a substantial part of our secret sauce (the other legs being the physical device it's controlling, the analog ASIC, and the firmware). None of those will ever be public unless someone completely screws the pooch. I'd expect the same to be true for, say, the RTL for Intel's processor line.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
No, it wasn't.
Oh do we have access to their source and commit history? I'd love to read it actually.
*blink* This is RTL, written in Verilog, for a private company, instantiated on a digital ASIC (chip). It was never public, and it will never be public.
How many chips have public sourcecode?
My point would then be neither of us know who wrote it or designed the ASIC chip.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
No, it wasn't.
Oh do we have access to their source and commit history? I'd love to read it actually.
*blink* This is RTL, written in Verilog, for a private company, instantiated on a digital ASIC (chip). It was never public, and it will never be public.
How many chips have public sourcecode?
My point would then be neither of us know who wrote it or designed the ASIC chip.
And I'm telling you I know who wrote it and who designed the ASIC. There were bits and pieces that were offshored, but most of it was written by people I can toss a softball at from my cube. The entire chain from physical device to firmware is under our control. Saying this is an offshoring problem is flat out incorrect. This is a programming problem, and one that anybody can make unless you write the tools to prevent it from being a problem. Not manually iterating through indices is a damned good first step to it.
The root cause of the Cloudbleed vulnerability was that "reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer."
"Had the check been done using >= instead of == jumping over the buffer end would have been caught," said Cumming.
That is a painfully rookie level mistake.
offshored code gonna offshore
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
Probably still offshored though.
No, it wasn't.
Oh do we have access to their source and commit history? I'd love to read it actually.
*blink* This is RTL, written in Verilog, for a private company, instantiated on a digital ASIC (chip). It was never public, and it will never be public.
How many chips have public sourcecode?
My point would then be neither of us know who wrote it or designed the ASIC chip.
And I'm telling you I know who wrote it and who designed the ASIC. There were bits and pieces that were offshored, but most of it was written by people I can toss a softball at from my cube. Saying this is an offshoring problem is flat out incorrect. This is a programming problem, and one that anybody can make unless you write the tools to prevent it from being a problem. Not manually iterating through indices is a damned good first step to it.
Probably an H1B problem.
:rotate:
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
...
You know what? I'm done.
Believe what you will, and then act surprised when you pull something similarly boneheaded.
I was about to type out a post about how varnish would be useless on forums like these, but I guess there are probably a lot of people who just read and don't log in.
Posts
Really? Huh, I always thought it was "fine, I guess". Got a little annoying when a type didn't bridge exactly how I wanted, but past that it never made me mad at it. I mean more than usual mad at Xcode anyway.
Then again, Python flat-out gives me a headache, so all about taste I guess.
print("Printing the number five: " + 5)
Come on Python. You know what I'm trying to do. You'll let force me to duck type all sorts of crap, but this one is a bridge too far?
"Just use print("Printing the number five: {}".format(5))!"
Oh come on, you were just telling me 5 minutes ago that Java is unnecessarily verbose and clunky!
It's better in Swift 3, but it's still a mess of needing to know when to use String, CFString, NSString, CFDictionary, Data, NSData, etc. God forbid you have to deal with CoreCrypto and the Security framework, which I was. It's some of the worst documented libraries I've ever used.
Ah yeah, that's true, goes back to that fiddly type bridging I guess. I just assume I'm going to have to check the docs on anything I want to use that I haven't used in the last... 10 minutes anyway, so don't mind needing to refresh which is which so much.
What did bug me was "I know we just released 2.1, but here's 3.0, by the way everything's different now, primarily in subtle ways you're not going to notice until you accidentally break something somewhere."
need to use a popular open source objc framework in a swift project? good luck!!
its harder to use objc in swift than it was to use C++ in objc, which is a little nutty considering objc/swift are basically made by the same entity for the same environment
This is what I mean by Apple's terrible documentation though:
https://developer.apple.com/reference/security/1643916-seckeycreatesignature
The documentation is the function signature and the text No overview available.. I happen to know that if you drill in to the function in XCode it will take you to the header file, where there is some comment documentation...but outside of that it's trial and error all the way down.
I never had the framework problem, though, to be honest. Might have just gotten lucky, god knows mileage varies on those things.
i hope that never happens though
This shit should end businesses.
Edit: I actually can't put into words how fucking outraged I am by this exploit and some attempts to establish a story line with "Most likely nobody noticed, so no worries.". Fuck. This. Shit.
Fair enough on the + 5 bit in that Python should be smart enough to make it work, but even that is more verbose than it needs to be with what Python already provides.
If there's anything to complain about with Python string formatting it's that there are too many choices, which is annoying and pretty clearly breaks the "There should be one-- and preferably only one --obvious way to do it." mandate from The Zen of Python. They need to pick something and go with it. The String.format() type formatting also supports named parameters - although obviously more verbose, but if you need to interpolate/format the same variable into a string 5 times it can save typing, although I wouldn't use it with
It's not really your choice to use CloudFlare or not, unless you're just going to stop using the internet.
On a side note, I had to make a change to a legacy application yesterday, the code is VB. Oh gosh VB is terrible.
Also, this site (Penny Arcade) is listed under the possibly affected sites.
That is a painfully rookie level mistake.
offshored code gonna offshore
Outsourcing :rotate:
Doesn't need to be offshored. I've seen that sort of thing creep up in a digital ASIC before. In fact, most of the clock dividers in the system seem to be setup that way, under the assumption that the clock rate should never be changed, since <= is considerably more logic than == (gotta save those gates!). Of course, then there was a problem that required the clock rate to be changed at runtime, uncovering a bug that required an oscilloscope and repeated runs to uncover.
Solution: start at the maximum rate (smallest divider), monotonically decrease the clock rate if changes are needed (increase divider to avoid requiring the register to rollover to reset).
Then, as icing on the cake, there was a second divider that used the output of the first as its clock, and that divider needed to move in the opposite direction in conjunction with the first to maintain a constant sample rate regardless of the input clock. Fortunately, we could delay when that one was enabled to avoid the hardware bug.
Needless to say, the RTL team is now onboard with <=, even though that means burning a picowatt more power.
I don't know if that makes it better or worse.
Probably still offshored though.
No, it wasn't.
Probably not particularly better or worse, but I can at least understand how it got through.
Mmmm, you do realize that I meant as a business user, right?
Oh do we have access to their source and commit history? I'd love to read it actually.
It makes it more understandable to a degree. I tend to trust non UI auto generated code as little as possible.
*blink* This is RTL, written in Verilog, for a private company, instantiated on a digital ASIC (chip). It was never public, and it will never be public.
How many ASICs have public sourcecode?
edit: Yeah, there's OpenCores, but that's largely generic stuff like memory controllers, I2C controllers, etc. Apple isn't going to give you the source to the iPhone processor line, and neither is Samsung going to do that for the Exynos chipset. IF you pay a boatload of money, you can instantiate an ARM core on your ASIC, but I'm pretty sure licensing agreements prevent you from putting the source out there. RTL is a whole other world and is nothing like web work. In this case, the chip contains a substantial part of our secret sauce (the other legs being the physical device it's controlling, the analog ASIC, and the firmware). None of those will ever be public unless someone completely screws the pooch. I'd expect the same to be true for, say, the RTL for Intel's processor line.
(edit: woops, just noticed I was way slow with this)
My point would then be neither of us know who wrote it or designed the ASIC chip.
I changed my password, either that I am a Russian troll who found some logins. There is no way to be sure, comrades.
"== your hacked OKCupid profile"
And I'm telling you I know who wrote it and who designed the ASIC. There were bits and pieces that were offshored, but most of it was written by people I can toss a softball at from my cube. The entire chain from physical device to firmware is under our control. Saying this is an offshoring problem is flat out incorrect. This is a programming problem, and one that anybody can make unless you write the tools to prevent it from being a problem. Not manually iterating through indices is a damned good first step to it.
Probably an H1B problem.
:rotate:
You know what? I'm done.
Believe what you will, and then act surprised when you pull something similarly boneheaded.
Main site is separate from the forums. Though I dunno if Vanilla uses Cloudflare.
The club PA and main site stuff ties into the forum logins I thought?
apples to snake oil and all that