Heh, I guess I'm the only one who is constantly having fix my Linux machines when they fail to boot. But then again, I tend to get bored once everything is working...;-)
Are you saying that, if I make, say, some gadget, and put it on sale in my store, I shouldn't be upset if someone breaks in at night and takes it away because they "didn't think the price is worth the value", and "found other ways to get it"?
How is that anything alike? If we are going to have an intelligent discussion on the subject, then why don't we compare the situations accurately.
A more apt analogy would be if that someone purchased your product (or looked at it in the store), and then opened up a shop selling the same product for cheaper (presumably because he didn't have any R&D cost). I am not necessarily saying that is right or wrong, but if you need to "inflate" the moral dilemma to make your point, well, that says quite a bit about your point already...
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
I'm no FOSSIE pro, but if those assets are needed to actually build and run the program, than it would seem source code does in fact == assets. (DISCLAIMER: I hate GPL and have no idea what I am talking about... this is just my interpretation of the above quote... so please correct me if I am mistaken)
Stop responding to him. He doesn't care about any "bug." He's just having a laugh at your expense. Trust me, there is no "winning" with APK. Any response results in more trolling.
Well according to the UK's Transport Research Laboratory, certain driving abilities are actually improved at low doses. At higher dosages, they did find a negative impact, but practically negligible when compared to alcohol.
I bet they could pull it off. If my Android port of FF3 can scale up beautifully to my HD tablet, I don't see why Nintendo would have any trouble. Unless of course they just ran out of time and didn't implement anything to handle it.
I've always wondered if there was some kind of liquor license that would allow you to deliver beer and wine with your pizza. Pizza beer and a movie right at my front door? Sign me up!
So, how long have you been working for Adobe? Flash and SWF are terrible technologies. They're slow, they're buggy, they're insecure. Most of the time when my browser crashes it's because of one of those two technologies.
I wish you could say who the no flash order was from, because they deserve my business. Flash was one of the worst things to ever happen to the web.
I can promise you flash is only as slow and buggy as the flash developer. Unfortunately, there are hordes of the sluggish variety mucking about. Security is a non issue. In fact, flash is one of the easier things to get clearance on in our government contracts.
I will however be the first to admit the platform would do much better if the whole thing were given to Apache. The problems with Flash are political, not technical.
We got our first "no flash" order on a project awhile back, and I have cried a little on the inside every day I have worked on it. My first introduction to flash was compiling SWFs in Linux using the MXMLC compiler. In fact, I even wrote the Actionscript 3 syntax highlighting rules for KDevelop (Kate) 3.5, because that's what I had available on my system to use. The flash platform is an AMAZING technology stack, and it is sad to see it go to waste behind a wall of patents wielded by a bafoon of a company.
Well since I got down modded on my GP post, I will reply to your comment here as well...
Have your clients buy Enterprise licenses?
We did actually consider this, and decided it wasn't the way to go. Our primary concern being that we run the risk of losing our developer license.
It would be fine if we were developing an app for a single client, which they would own the rights to on delivery. But what if we have multiple clients who want the same system? We could have each client add us as an authorized developer so we could sign the code using their certificates, but this is clearly in contradiction to to Apple's app store model, and probably would not end well for us were they to find out what we were up to (and there is a paper trail).
After weighing the risks, we decided it would be best to brave the approval process for the Volume Purchasing Program. As it turns out, it was a good decision. We got our product delivered on time, and now we can start working on an "ideal" solution.
The bottom line is that developing enterprise applications for a walled garden presents additional risk, and we are now taking active steps to eliminate that risk entirely.
We did actually consider this, and decided it wasn't the way to go. Our primary concern being that we run the risk of losing our developer license.
It would be fine if we were developing an app for a single client, which they would own the rights to on delivery. But what if we have multiple clients who want the same system? We could have each client add us as an authorized developer so we could sign the code using their certificates, but this is clearly in contradiction to to Apple's app store model, and probably would not end well for us were they to find out what we were up to (and there is a paper trail).
After weighing the risks, we decided it would be best to brave the approval process for the Volume Purchasing Program. As it turns out, it was a good decision.
If you actually read the terms carefully, this only authorizes you to distribute the app to internal employees. I know because we have an Enterprise license, which is pretty much entirely useless to us (as a provider of B2B services). We need to go through the standard approval process to get our app in the Volume Purchasing Program (which I imagine is what these guys in TFA actually needed).
Um. No. It's simple to set up enterprise distribution with your provisioning profile, which will allow you install any of your signed apps on any of your devices. You can even push the apps OTA.
Have a clue before you make stuff up.
You are the one without a clue. We are a small company that develops (among other things) internal training software for much larger corporations. Using the enterprise license, we are only allowed to install on our own devices, and not the client's. Only the Volume Purchasing Program will work for our business model, which puts us entirely at Apple's mercy to deliver our products. We are so fed up with the process, we spent the last year stripping functionality so we can make it work as a web app.
I don't RTFA, but there's not a single thing in TFS saying the "counterfeits" are defective or dangerous.
Indeed, no one's been hurt.
Sounds like it's just a case of trademark infringement, a practice that usually saves the consumer money.
My thoughts exactly. To bad you got a -1 for them. Oh, and I did RTFA, and you were right. The complaint here is that some IP was violated. Fuck those guys, and fuck their "name brand" airbags (which are probably made in china anyways).
Here is the entire design document in one sentence:
Make the app look like an Android app, make the home screen look like iOS (but circles instead of rounded squares).
Not possible, given your requirements. You will need to choose between relying on the deprecated UDID, lack of a perma-ban abilty (token generated on install), or requiring a login.
It's hard to watch a video on a page that continually loops a flash add (with sound), and with no way to stop it. For those of you who have trouble paying attention to people talking over each other, here is a link to the video on youtube.
If you do not restrict your input (at least to some extent), you open up the crypto library on your system as a potential attack vector. Granted, its not very likely to come across an exploitable flaw of this nature, but even the best programmers make mistakes. Bottom line, opening up a pipe (completely unrestricted input) to a low level system service is a bad idea. I think a sane limit on password input (maybe 256 - 512 printable latin ascii characters) is reasonable.
Slashdot Mirror
This is an informative overview of the windows security model. To bad I blew my mod points for this thread earlier on, with a worthless comment.
Heh, I guess I'm the only one who is constantly having fix my Linux machines when they fail to boot. But then again, I tend to get bored once everything is working... ;-)
Aye, I missed the AC there.
Are you saying that, if I make, say, some gadget, and put it on sale in my store, I shouldn't be upset if someone breaks in at night and takes it away because they "didn't think the price is worth the value", and "found other ways to get it"?
How is that anything alike? If we are going to have an intelligent discussion on the subject, then why don't we compare the situations accurately.
A more apt analogy would be if that someone purchased your product (or looked at it in the store), and then opened up a shop selling the same product for cheaper (presumably because he didn't have any R&D cost). I am not necessarily saying that is right or wrong, but if you need to "inflate" the moral dilemma to make your point, well, that says quite a bit about your point already...
Source code != assets.
Well according to the GPL...
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
I'm no FOSSIE pro, but if those assets are needed to actually build and run the program, than it would seem source code does in fact == assets. (DISCLAIMER: I hate GPL and have no idea what I am talking about... this is just my interpretation of the above quote... so please correct me if I am mistaken)
Stop responding to him. He doesn't care about any "bug." He's just having a laugh at your expense. Trust me, there is no "winning" with APK. Any response results in more trolling.
Well according to the UK's Transport Research Laboratory, certain driving abilities are actually improved at low doses. At higher dosages, they did find a negative impact, but practically negligible when compared to alcohol.
Source: The Influence of Cannabis on Driving, Sexton, BF, Tunbridge, RJ Brook-carter, N Jackson, PG Wright, K Stark, and MM Englehart, 2000
Well I for one, wouldn't want to bet my life on the "average intelligence" of the populace. In my experience, that average is pretty low.
True, there is an extra level of software control there I didn't consider.
I bet they could pull it off. If my Android port of FF3 can scale up beautifully to my HD tablet, I don't see why Nintendo would have any trouble. Unless of course they just ran out of time and didn't implement anything to handle it.
Include a prepaid envelope for the return? It's like the original Netflix, but without all the waiting, and pizza. Pizza idea FTW.
I've always wondered if there was some kind of liquor license that would allow you to deliver beer and wine with your pizza. Pizza beer and a movie right at my front door? Sign me up!
On those large wifi networks, it is less about the outbound pipe speed, and more about the signal noise.
So, how long have you been working for Adobe? Flash and SWF are terrible technologies. They're slow, they're buggy, they're insecure. Most of the time when my browser crashes it's because of one of those two technologies.
I wish you could say who the no flash order was from, because they deserve my business. Flash was one of the worst things to ever happen to the web.
I can promise you flash is only as slow and buggy as the flash developer. Unfortunately, there are hordes of the sluggish variety mucking about. Security is a non issue. In fact, flash is one of the easier things to get clearance on in our government contracts. I will however be the first to admit the platform would do much better if the whole thing were given to Apache. The problems with Flash are political, not technical.
We got our first "no flash" order on a project awhile back, and I have cried a little on the inside every day I have worked on it. My first introduction to flash was compiling SWFs in Linux using the MXMLC compiler. In fact, I even wrote the Actionscript 3 syntax highlighting rules for KDevelop (Kate) 3.5, because that's what I had available on my system to use. The flash platform is an AMAZING technology stack, and it is sad to see it go to waste behind a wall of patents wielded by a bafoon of a company.
Well since I got down modded on my GP post, I will reply to your comment here as well...
Have your clients buy Enterprise licenses?
We did actually consider this, and decided it wasn't the way to go. Our primary concern being that we run the risk of losing our developer license.
It would be fine if we were developing an app for a single client, which they would own the rights to on delivery. But what if we have multiple clients who want the same system? We could have each client add us as an authorized developer so we could sign the code using their certificates, but this is clearly in contradiction to to Apple's app store model, and probably would not end well for us were they to find out what we were up to (and there is a paper trail).
After weighing the risks, we decided it would be best to brave the approval process for the Volume Purchasing Program. As it turns out, it was a good decision. We got our product delivered on time, and now we can start working on an "ideal" solution.
The bottom line is that developing enterprise applications for a walled garden presents additional risk, and we are now taking active steps to eliminate that risk entirely.
We did actually consider this, and decided it wasn't the way to go. Our primary concern being that we run the risk of losing our developer license.
It would be fine if we were developing an app for a single client, which they would own the rights to on delivery. But what if we have multiple clients who want the same system? We could have each client add us as an authorized developer so we could sign the code using their certificates, but this is clearly in contradiction to to Apple's app store model, and probably would not end well for us were they to find out what we were up to (and there is a paper trail).
After weighing the risks, we decided it would be best to brave the approval process for the Volume Purchasing Program. As it turns out, it was a good decision.
If you actually read the terms carefully, this only authorizes you to distribute the app to internal employees. I know because we have an Enterprise license, which is pretty much entirely useless to us (as a provider of B2B services). We need to go through the standard approval process to get our app in the Volume Purchasing Program (which I imagine is what these guys in TFA actually needed).
Um. No. It's simple to set up enterprise distribution with your provisioning profile, which will allow you install any of your signed apps on any of your devices. You can even push the apps OTA.
Have a clue before you make stuff up.
You are the one without a clue. We are a small company that develops (among other things) internal training software for much larger corporations. Using the enterprise license, we are only allowed to install on our own devices, and not the client's. Only the Volume Purchasing Program will work for our business model, which puts us entirely at Apple's mercy to deliver our products. We are so fed up with the process, we spent the last year stripping functionality so we can make it work as a web app.
I don't RTFA, but there's not a single thing in TFS saying the "counterfeits" are defective or dangerous. Indeed, no one's been hurt. Sounds like it's just a case of trademark infringement, a practice that usually saves the consumer money.
My thoughts exactly. To bad you got a -1 for them. Oh, and I did RTFA, and you were right. The complaint here is that some IP was violated. Fuck those guys, and fuck their "name brand" airbags (which are probably made in china anyways).
Here is the entire design document in one sentence: Make the app look like an Android app, make the home screen look like iOS (but circles instead of rounded squares).
This one has my vote. :-)
Not possible, given your requirements. You will need to choose between relying on the deprecated UDID, lack of a perma-ban abilty (token generated on install), or requiring a login.
It's hard to watch a video on a page that continually loops a flash add (with sound), and with no way to stop it. For those of you who have trouble paying attention to people talking over each other, here is a link to the video on youtube.
You are missing the point entirely.
If you do not restrict your input (at least to some extent), you open up the crypto library on your system as a potential attack vector. Granted, its not very likely to come across an exploitable flaw of this nature, but even the best programmers make mistakes. Bottom line, opening up a pipe (completely unrestricted input) to a low level system service is a bad idea. I think a sane limit on password input (maybe 256 - 512 printable latin ascii characters) is reasonable.