And unfortunately Informix never got the respect it deserved (even after being bought by IBM for $1Billion (yes, with a B). Mainly because there was no good living in being an Informix consultant, whereas Oracle consultants made bank. I was once half of a two person team administering about 200 production mission-critical high-volume Informix instances - almost never was there an issue. Good thing we weren't relying on billing by the hour!
This is true for many real "Strings". Its not true at all for arbitrary length blocks of bytes that don't happen to contain a NUL (also called "Strings" by many C programmers, a practice encouraged by the names of the str___() functions). And one thing that C does really well, as it should, is manipulate tons of arbitrary length blocks of bytes.
C doesn't _require_ you to use NUL terminated strings, you can do whatever you feel is cute. A 'char *' is nothing but a pointer, which you can use as a string, but you don't have to, nor the reverse.
If C had used byte instead of char, and something like bzs (for null terminated byte sequence) instead of str in its standard library names, we'd all be much happier. Not only would people not thing that a char* was a string (since its an argument to strcpy), but one of the evolutions of C might have presented a real string type designed at a time when memory was less precious than it once was.
C does not have strings.... It has a char and a pointer to a char - this means you have low level control of everything (and you have to cope with the consequences)
Actually, I'd say its worse than that; it has a byte - which is confusingly named char, but no Character. It also has a series of routines designed to work on arbitrary length byte arrays, some of which confusingly start with the letters str. Then C coders get to sniff at anyone who things that char is a Character, or that a char* (which is what the str...() routines all work on) is a String.
Amazing how many of those confusions would have also been eliminated with one additional byte - the value returned by strsize() would have been much more obvious. As with the difference between weight and mass, when two different concepts commonly share the same value its easy to confuse them - but terribly confusing later when the differences become critical.
When massively hardware constrained, and when all programmers were good (and programs 100% debuggable/testable), that did make sense.
Using a length marker rather than a NUL makes 50% of your string handling slightly more complicated, and in exchange it makes a relatively common error that often has truly disastrous security and stability consequences completely disappear. That's a good deal, at least from a "software engineering" standpoint. That doesn't mean that you can afford to take the deal, but if/when you can, you probably should.
Although - ideally - if your language of choice was trying to have a String type, it would allow you to use string[n] to refer to the "standard" (glyph at the n'th position of the precomposed iterator), and let you use a library to see the String as a byte[]. Since, as you mentioned, you should always use the glyphs as glyphs and never as bytes, unless you were performing actual IO on them (which is comparatively rare in application development).
What I'm saying is if the BB freezes, its generally an app. most apps are very well written and have no problems. Some are crap, just like an every other platform.
The point that yodleboy was making, I believe, is that these days there's no excuse whatsoever for an app - even a malicious app - to crash anything beyond itself. If the OS allows an app to either take all cycles by refusing to yield, or to b0rk the OS itself through poor memory management techniques, then there's proof that the OS authors didn't know what they were doing. Its not as if these are new concepts. Once you've established that a modern OS was written by people without those very basic (by today's standards) skills, you're so far in the hole that its not even worth continuing.
If I ever saw someone performing sexual intercourse on a young adolescent, I swear to God, I will fucking kill the predator with my bare hands, and stand trial by jury knowing I did the right thing.
Sounds like most people (myself included) when we were adolescents ourselves. Glad you never saw us.
Even though in many cultures that's completely normal, you'd be willing to force someone to move and, quite possibly, never have a real job again as long as they live, because they helped your child come home after they wandered away from their new house?
I'd say not so much - although the recent lumping in of 17.9 year olds with 5 year olds has dramatically muddled the waters to the point where your statement is somewhat reasonable from a colloquial standpoint.
I used to do that, and then stopped - I just don't pretend that "Inbox" means "You must read this." Same process, but without the ARCHIVE button, and it still works just fine. Sure, the #unread reading is meaningless, but it turns out that I'm okay with that in exchange for not having to worry about whether or not my undeleted email has an INBOX tag on it.
Email's a tool. Having an empty INBOX (and a searchable ARCHIVE) doesn't make you better or worse than someone with a searchable INBOX instead...
Actually, gmail will happily support your you@yourdomain.com address. My email address is live, on the web, and I've been handing it out to all and sundry for many a year; I see about one false positive every 3 months in gmail's spam filters, and about 3 spam messages a month in my inbox. Filtering works, and it lets me stop acting all paranoid about handing out my address.
Like this, for example? This is not a new product - possibly its a slight convenience tool in making it easier to put together courses, but the GPS -> grade-specific training file process isn't that hard now, and often contains much finer elevation change information than the Google Maps version, especially when taken with a device that supports barometric altitude like an Edge.
The new CycleOps has announced support for video cameras, making it easier to get a full "re-ride" experience if you ride with a small camera as well as your GPS. Pretty cool stuff.
It thrives on new features and new technologies to enable developers to create whole new applications you haven't' even begun to imagine. They can't do this if the feature set never changes
Actually, they totally can. The currently supported feature set is still bleeding-edge enough that most public-facing websites haven't begun to scratch the surface of it, and won't until at least 80% (probably much higher) of their traffic is using a browser that supports it. Yet, somehow, people are still managing to innovate and build tons of new web-based applications.
If there are enough non-players like me on facebook, small games are going to suffer a lot because every such "hide it for me, thanks" is going to count as a negative vote. If you're not Zynga with a gazillon of players on your virtual Farm to counter-balance the non-gamers, you're screwed.
Of course, if your relatively-unpopular game doesn't auto-spam by posting hundreds of updates on every player's wall, you won't have this problem in the first place...
Note that the source code actually distributed the secret key (which is not in the URL) as well as the application key (which is). This is a not insignificant point.
Besides, being able to spam everyone who's a friend of a logged-in user is still pretty bad.
From the error, it actually sounds like the application had an API key distributed inside of it... which means that anyone, anywhere, could pretend to be the application.. and could use its credentials to upload anything they want.
To be honest, as much as I hate Facebook's developer program, sharing an API key in an end-user downloaded application (open source or not: doesn't matter) seems downright inane, and I can easily see circumstances where it looked like the application in general was doing something downright forbidden (maybe uploading porn), and the entire application got banned and all of its content got retroactively pulled.
In fact, I'm a little rusty on this whole Facebook API thing, but I could easily see situations where the application was authorized to access peoples' photo galleries, then allowing anyone with those API keys to upload photos/as other people/. This likely went unnoticed for a while, but eventually someone figured it out, uploaded porn to/someone else's account/, and then the only feasible way to fix the situation (assuming a person even bothered looking into it, and I wouldn't blame Facebook much if no one did) was to just pull all photos that had been uploaded.
Seriously: this is not a situation of "do not use Facebook": this is a situation of "do not use insecure applications".
The linked but talks about the application key being public (which appears to be the case in URLs and suchlike), but makes no mention of the fact that the secret key to the application was also made public in the source code. This would allow anyone with access to the application (ie, most script kiddies) to write other programs (anything that can make an outbound HTTP connection) to use the permissions granted to that application (such as writing to the logged-in user's wall, notifying friends (think image tags), et cetera).
I'm not actually sure how this problem could be "solved." Could you ever, really, distribute the source for a remote-permissions-based program like this in such a way that it couldn't be impersonated, if people grant permissions based on their identity (secure) and the identity of the program (100% completely unsecure)?
IF an organization takes public funding (either directly or in the form of discounted goods and services), its generally held to a higher standard as far as discrimination goes. Organizations are, in fact, perfectly free to determine their own members however they see fit, if they're 100% privately funded. You can discriminate. You can get public money. You just don't get to do both.
Scala's actor framework is indeed built in, and works very well for multi-core scaling. What it doesn't have is a distributed concurrency model that makes it trivial to run a single "program" on multiple weakly-connected systems ("in the cloud.")
Giving someone "the right to pay $2 for something that's now worth $20" is great, and a relatively standard form of partial compensation, especially at startups where long hours are the norm. Where it became fraud was the little hidden clause that boiled down to "... which we may then repurchase from you at the $2 you paid us, not the $20 its now worth, entirely at our discretion." The fact that people are even looking at the vesting side of things means that the clause was, indeed, very well hidden.
Effectively, in exchange for every stock option the company gave him, they made him give them an equally-valuable stock option in return. That's about as far from compensation as you can get.
Nope, I'm an accountant and reading the "incomprehensible" passage via the CNN link the phrase "...subject to the repurchase and other provisions..." jumps out like a big neon animated diagram with the words "bend over" and a rather uncomfortable-looking arrow.
Slashdot Mirror
And unfortunately Informix never got the respect it deserved (even after being bought by IBM for $1Billion (yes, with a B). Mainly because there was no good living in being an Informix consultant, whereas Oracle consultants made bank. I was once half of a two person team administering about 200 production mission-critical high-volume Informix instances - almost never was there an issue. Good thing we weren't relying on billing by the hour!
This is true for many real "Strings". Its not true at all for arbitrary length blocks of bytes that don't happen to contain a NUL (also called "Strings" by many C programmers, a practice encouraged by the names of the str___() functions). And one thing that C does really well, as it should, is manipulate tons of arbitrary length blocks of bytes.
C doesn't _require_ you to use NUL terminated strings, you can do whatever you feel is cute. A 'char *' is nothing but a pointer, which you can use as a string, but you don't have to, nor the reverse.
If C had used byte instead of char, and something like bzs (for null terminated byte sequence) instead of str in its standard library names, we'd all be much happier. Not only would people not thing that a char* was a string (since its an argument to strcpy), but one of the evolutions of C might have presented a real string type designed at a time when memory was less precious than it once was.
Oh well.
C does not have strings .... It has a char and a pointer to a char - this means you have low level control of everything (and you have to cope with the consequences)
Actually, I'd say its worse than that; it has a byte - which is confusingly named char, but no Character. It also has a series of routines designed to work on arbitrary length byte arrays, some of which confusingly start with the letters str. Then C coders get to sniff at anyone who things that char is a Character, or that a char* (which is what the str...() routines all work on) is a String.
Amazing how many of those confusions would have also been eliminated with one additional byte - the value returned by strsize() would have been much more obvious. As with the difference between weight and mass, when two different concepts commonly share the same value its easy to confuse them - but terribly confusing later when the differences become critical.
I'd still take NULL-terminated for most purposes.
When massively hardware constrained, and when all programmers were good (and programs 100% debuggable/testable), that did make sense.
Using a length marker rather than a NUL makes 50% of your string handling slightly more complicated, and in exchange it makes a relatively common error that often has truly disastrous security and stability consequences completely disappear. That's a good deal, at least from a "software engineering" standpoint. That doesn't mean that you can afford to take the deal, but if/when you can, you probably should.
Although - ideally - if your language of choice was trying to have a String type, it would allow you to use string[n] to refer to the "standard" (glyph at the n'th position of the precomposed iterator), and let you use a library to see the String as a byte[]. Since, as you mentioned, you should always use the glyphs as glyphs and never as bytes, unless you were performing actual IO on them (which is comparatively rare in application development).
However, in terms of enjoyment-per-hour, games are still remarkably cheap.
Still hard to beat the $0.99 Tiny Wings or Angry Birds, though.
What I'm saying is if the BB freezes, its generally an app. most apps are very well written and have no problems. Some are crap, just like an every other platform.
The point that yodleboy was making, I believe, is that these days there's no excuse whatsoever for an app - even a malicious app - to crash anything beyond itself. If the OS allows an app to either take all cycles by refusing to yield, or to b0rk the OS itself through poor memory management techniques, then there's proof that the OS authors didn't know what they were doing. Its not as if these are new concepts. Once you've established that a modern OS was written by people without those very basic (by today's standards) skills, you're so far in the hole that its not even worth continuing.
If I ever saw someone performing sexual intercourse on a young adolescent, I swear to God, I will fucking kill the predator with my bare hands, and stand trial by jury knowing I did the right thing.
Sounds like most people (myself included) when we were adolescents ourselves. Glad you never saw us.
Even though in many cultures that's completely normal, you'd be willing to force someone to move and, quite possibly, never have a real job again as long as they live, because they helped your child come home after they wandered away from their new house?
You utter bastard.
I'd say not so much - although the recent lumping in of 17.9 year olds with 5 year olds has dramatically muddled the waters to the point where your statement is somewhat reasonable from a colloquial standpoint.
I used to do that, and then stopped - I just don't pretend that "Inbox" means "You must read this." Same process, but without the ARCHIVE button, and it still works just fine. Sure, the #unread reading is meaningless, but it turns out that I'm okay with that in exchange for not having to worry about whether or not my undeleted email has an INBOX tag on it.
Email's a tool. Having an empty INBOX (and a searchable ARCHIVE) doesn't make you better or worse than someone with a searchable INBOX instead...
Actually, gmail will happily support your you@yourdomain.com address. My email address is live, on the web, and I've been handing it out to all and sundry for many a year; I see about one false positive every 3 months in gmail's spam filters, and about 3 spam messages a month in my inbox. Filtering works, and it lets me stop acting all paranoid about handing out my address.
Like this, for example? This is not a new product - possibly its a slight convenience tool in making it easier to put together courses, but the GPS -> grade-specific training file process isn't that hard now, and often contains much finer elevation change information than the Google Maps version, especially when taken with a device that supports barometric altitude like an Edge.
The new CycleOps has announced support for video cameras, making it easier to get a full "re-ride" experience if you ride with a small camera as well as your GPS. Pretty cool stuff.
It thrives on new features and new technologies to enable developers to create whole new applications you haven't' even begun to imagine. They can't do this if the feature set never changes
Actually, they totally can. The currently supported feature set is still bleeding-edge enough that most public-facing websites haven't begun to scratch the surface of it, and won't until at least 80% (probably much higher) of their traffic is using a browser that supports it. Yet, somehow, people are still managing to innovate and build tons of new web-based applications.
If there are enough non-players like me on facebook, small games are going to suffer a lot because every such "hide it for me, thanks" is going to count as a negative vote. If you're not Zynga with a gazillon of players on your virtual Farm to counter-balance the non-gamers, you're screwed.
Of course, if your relatively-unpopular game doesn't auto-spam by posting hundreds of updates on every player's wall, you won't have this problem in the first place...
Distributing the secret key (ie: password) of a somewhat popular application to the masses is probably why the app was blocked...
Note that the source code actually distributed the secret key (which is not in the URL) as well as the application key (which is). This is a not insignificant point.
Besides, being able to spam everyone who's a friend of a logged-in user is still pretty bad.
Courtesy Jay Freeman:
The linked but talks about the application key being public (which appears to be the case in URLs and suchlike), but makes no mention of the fact that the secret key to the application was also made public in the source code. This would allow anyone with access to the application (ie, most script kiddies) to write other programs (anything that can make an outbound HTTP connection) to use the permissions granted to that application (such as writing to the logged-in user's wall, notifying friends (think image tags), et cetera).
I'm not actually sure how this problem could be "solved." Could you ever, really, distribute the source for a remote-permissions-based program like this in such a way that it couldn't be impersonated, if people grant permissions based on their identity (secure) and the identity of the program (100% completely unsecure)?
IF an organization takes public funding (either directly or in the form of discounted goods and services), its generally held to a higher standard as far as discrimination goes. Organizations are, in fact, perfectly free to determine their own members however they see fit, if they're 100% privately funded. You can discriminate. You can get public money. You just don't get to do both.
Scala's actor framework is indeed built in, and works very well for multi-core scaling. What it doesn't have is a distributed concurrency model that makes it trivial to run a single "program" on multiple weakly-connected systems ("in the cloud.")
Giving someone "the right to pay $2 for something that's now worth $20" is great, and a relatively standard form of partial compensation, especially at startups where long hours are the norm. Where it became fraud was the little hidden clause that boiled down to "... which we may then repurchase from you at the $2 you paid us, not the $20 its now worth, entirely at our discretion." The fact that people are even looking at the vesting side of things means that the clause was, indeed, very well hidden.
Effectively, in exchange for every stock option the company gave him, they made him give them an equally-valuable stock option in return. That's about as far from compensation as you can get.
Nope, I'm an accountant and reading the "incomprehensible" passage via the CNN link the phrase "...subject to the repurchase and other provisions..." jumps out like a big neon animated diagram with the words "bend over" and a rather uncomfortable-looking arrow.
Well, of course it does now...
Whether or not Skype is legally right here, it's not in any company's best interest to obfuscate important terms of employment.
Well, unless they have a "BTW, half of your compensation doesn't actually exist," clause. In which case it kinda is.