Actually COBOL programs typically don't use strings (PIC X(length)) to represent numbers. They normally use PIC 9(length) data, which is a legit number. If there will be a calculation or comparison based on the numbers, which is usually the case for dates, PIC 9 is preferred. Heck, you could even represent the numbers in a binary format (PIC 9 COMP-3) if you fancy saving a few bytes and optimizing the calculation.
The actual arrangement of the month, day, and year values depends on the particular COBOL program, and would usually depend on how the data looks on the input file\DB. Many of them just so happened to use 2 digits, but it's not like that was set in stone. Lots of these programs and datasets had to be updated to add 2 digits to the date field, but it wasn't really a COBOL issue they were fixing. It was a program design issue that was being repeated all over the place.
I guess the question is how exactly did the CVS repository get compromised? I imagine there's only a set number of people with commit access, and no one who works on it would willingly compromise it.
In the end, this all comes down to web services being a stupid idea.
I disagree. While I hate the buzzword BS as much as anybody, I wouldn't throw out a whole class of software just because it happens to be "Buzzword Compliant".
Really, to solve some kinds of problems, web services make sense. If you can get data from a web service, who know (more or less) that it's the same data you would get from running the web app in a browser. The difference is you will get back data (often XML) as opposed to Data + Page Layout + javascript, etc.
You don't want to be screen-scraping the data from (often malformed) HTML, do you? To me, that sounds like a bad plan, to be avoided whereever possible.
You don't normally have to do anything to write an arbitrary app for an Andriod phone that happens to have Sense. You just write your app using the regular Android SDK and don't worry about it. Sense and other skins are just not relevant factors for almost any app you would want to write.
Charging money for software is not the problem. The way I see it, the problem is anticompetitive behavior like vendor lock-in (or lock-out).
I like open source just as much as anyone else, but you seem to miss the point that open source means availability of source code, not $0 software. If people spend hours writing software, they get to decide whether or not it's open, and whether or not to charge for it. If you don't like it, write your own apps to compete and release them on your own terms.
A shallow water spill doesn't mean it'll be easy. There was one in Mexico that was really bad, and it spilled in 150 feet of water. Wikipedia says it leaked on average 10,000 to 30,000 barrels a day for about 10 months.
Anyway it also depends on the type of rig, type of accident, etc.
You're right in theory, however writing a test suite is not always an option. A common reason for this is when your business software is not in-house, but comes from a vendor. I saw this once on the job. Before every release all the mainframe backend staff were performing QA test scripts against the Java web frontend. This entailed following a Word document, clicking and doing what the document described, and recording results, particularly if anything weird happened. A trained monkey could do it.
Is this an ideal use of developer time? Not really. We were all bored, and I know my performance suffers when doing boring, mindless repetitive tasks such as this. So I sympathize with the OP. But when the boss tells you to do something, you probably should. I guess you could suggest some kind of front-end automation, but whether or not your boss goes for it is the question.
I personally would LOVE to see if anyone has any valuable advice for the OP. The best I have come up with is to on my iPod and try to get some momentum that way. It makes it suck just a little bit less.
That poses another problem. In general, vendor support contracts for a given piece of software usually become inapplicable if you modified the code in question. At least, this is how RedHat operates (See: Modified RPMs) so it's reasonable to expect that other vendors have similar policies.
IMHO, this is a reasonable policy, because the complexity in supporting the software distribution increases quite a bit if you can't guarantee the code\behavior is vanilla. So while you're still free to integrate upstream fixes, most businesses won't, because then they lose their support.
Disclaimer: I am not attempting to justify Oracle/Sun's decisions. I believe everyone should have access to security patches.
So grandma gets another dialog that she doesn't understand, every time flash\acrobat\whatever loads? She'll just hit any random button to make the dialog go away. She has stuff to do.
Plugin makers won't want to change their legacy behavior, as it will break their code. If they do, It'll take a long time to get through the testing phase even in a best case scenario. Basically, we're looking at the UAC debacle for legacy apps all over again. I don't see how this helps anything.
Anyone worth listening to knows that software of non-trivial complexity will always have bugs. There's usually a vocal minority in any group, and sometimes they don't know what they're talking about. So that said, I don't think it's valid to strawman the slashdot-reading linux community at large based on the opinions of a handful of fools.
You have a point. "Motivations" such as this can actually hurt morale and lead to in-fighting and nasty politics. Mary Poppendieck wrote a great essay on this subject [Warning: PDF]. It's more geared towards corporate environments but a lot of the same principles still apply.
Funny, but you've got a point. What would a potential employer think when, upon googling your name, they learn that you're so good at hiding malicious code that you won a contest for it. Would you hire that guy?
Most of Android in general (ie new code) is Apache 2.0. Parts of it use other licenses; Linux is GPL, Webkit is LGPL, SQLite is Public Domain, etc. Patches they submit to those upstream projects maintain the original license of that project.
If you're gonna be fiddling with the volume to make the algorithm work, then the algorithm is pointless. You may just as well watch TV normally with no algorithm, then turn down the volume when the commercial break starts. There's no benefit there.
That may be true, but their preferences only work if OpenDNS can tell which networks are yours. They detect this when you use your browser to log into the control panel, or if you install client-side software (OpenDNS Updater, which is Win\Mac only). You could do it with DynDNS too, but not everyone uses that.
Anyway I'd rather not go through all that effort, and would prefer the NXDOMAIN behavior to be the default for anonymous requests.
For me, the dealbreaker with OpenDNS is that, when you type in a non-existant domain, OpenDNS resolves it to an IP that gives you their custom search page. The standards compliant response would be NXDOMAIN, which is what Google (and some others) provide. This alone was enough to make me switch away from OpenDNS.
The performance really depends on the browser's architecture, which is comprised of a lot of parts and potential bottlenecks.
Chrome and Chromium, for example, are heavily multi-processed and handle large amounts of tabs\plugins very nicely. It certainly doesn't hurt that they were designed from the ground up for this kind of behavior.
You absolutely can use that in commercial products. You can also create derivative works and not release the source.
Apache 2.0 is considered a "commerce friendly" open source license (whatever that means). You'll see it in commercial products like Android and the Apache web server.
What is it about JS's OO syntax that isn't "real"?
Is it because it's prototype-based instead of the class-based paradigm that you're probably used to? There are actually some advantages (and disadvantages) to this approach. Just because it may not be what you're used to or comfortable with doesn't make it bad.
Light on facts, but also seems to have a viewpoint to push. TFA points out that the Android Java VM (Dalvik) is nonstandard, giving it all the associated stigma that a free software oriented audience would perceive. He also claims that this will somehow lock you in to Google's web apps:
... forced to use Java with non-standard bytecode. One might even suggest that Google has done this on purpose, in order to limit interoperability and push users towards its proprietary web services.
How Dalvik or its bytecode would accomplish this feat is left to the imagination. Anyone wanna clear this up for me?
I posted a response in TFA that points out that the Dalvik VM is also free software licensed under Apache 2.0
Slashdot Mirror
Actually COBOL programs typically don't use strings (PIC X(length)) to represent numbers. They normally use PIC 9(length) data, which is a legit number. If there will be a calculation or comparison based on the numbers, which is usually the case for dates, PIC 9 is preferred. Heck, you could even represent the numbers in a binary format (PIC 9 COMP-3) if you fancy saving a few bytes and optimizing the calculation.
The actual arrangement of the month, day, and year values depends on the particular COBOL program, and would usually depend on how the data looks on the input file\DB. Many of them just so happened to use 2 digits, but it's not like that was set in stone. Lots of these programs and datasets had to be updated to add 2 digits to the date field, but it wasn't really a COBOL issue they were fixing. It was a program design issue that was being repeated all over the place.
I guess the question is how exactly did the CVS repository get compromised? I imagine there's only a set number of people with commit access, and no one who works on it would willingly compromise it.
You can export your waves right now.
In the end, this all comes down to web services being a stupid idea.
I disagree. While I hate the buzzword BS as much as anybody, I wouldn't throw out a whole class of software just because it happens to be "Buzzword Compliant".
Really, to solve some kinds of problems, web services make sense. If you can get data from a web service, who know (more or less) that it's the same data you would get from running the web app in a browser. The difference is you will get back data (often XML) as opposed to Data + Page Layout + javascript, etc.
You don't want to be screen-scraping the data from (often malformed) HTML, do you? To me, that sounds like a bad plan, to be avoided whereever possible.
You don't normally have to do anything to write an arbitrary app for an Andriod phone that happens to have Sense. You just write your app using the regular Android SDK and don't worry about it. Sense and other skins are just not relevant factors for almost any app you would want to write.
Charging money for software is not the problem. The way I see it, the problem is anticompetitive behavior like vendor lock-in (or lock-out).
I like open source just as much as anyone else, but you seem to miss the point that open source means availability of source code, not $0 software. If people spend hours writing software, they get to decide whether or not it's open, and whether or not to charge for it. If you don't like it, write your own apps to compete and release them on your own terms.
A shallow water spill doesn't mean it'll be easy. There was one in Mexico that was really bad, and it spilled in 150 feet of water. Wikipedia says it leaked on average 10,000 to 30,000 barrels a day for about 10 months.
Anyway it also depends on the type of rig, type of accident, etc.
You're right in theory, however writing a test suite is not always an option. A common reason for this is when your business software is not in-house, but comes from a vendor. I saw this once on the job. Before every release all the mainframe backend staff were performing QA test scripts against the Java web frontend. This entailed following a Word document, clicking and doing what the document described, and recording results, particularly if anything weird happened. A trained monkey could do it.
Is this an ideal use of developer time? Not really. We were all bored, and I know my performance suffers when doing boring, mindless repetitive tasks such as this. So I sympathize with the OP. But when the boss tells you to do something, you probably should. I guess you could suggest some kind of front-end automation, but whether or not your boss goes for it is the question.
I personally would LOVE to see if anyone has any valuable advice for the OP. The best I have come up with is to on my iPod and try to get some momentum that way. It makes it suck just a little bit less.
That poses another problem. In general, vendor support contracts for a given piece of software usually become inapplicable if you modified the code in question. At least, this is how RedHat operates (See: Modified RPMs) so it's reasonable to expect that other vendors have similar policies.
IMHO, this is a reasonable policy, because the complexity in supporting the software distribution increases quite a bit if you can't guarantee the code\behavior is vanilla. So while you're still free to integrate upstream fixes, most businesses won't, because then they lose their support.
Disclaimer: I am not attempting to justify Oracle/Sun's decisions. I believe everyone should have access to security patches.
So grandma gets another dialog that she doesn't understand, every time flash\acrobat\whatever loads? She'll just hit any random button to make the dialog go away. She has stuff to do.
Plugin makers won't want to change their legacy behavior, as it will break their code. If they do, It'll take a long time to get through the testing phase even in a best case scenario. Basically, we're looking at the UAC debacle for legacy apps all over again. I don't see how this helps anything.
Anyone worth listening to knows that software of non-trivial complexity will always have bugs. There's usually a vocal minority in any group, and sometimes they don't know what they're talking about. So that said, I don't think it's valid to strawman the slashdot-reading linux community at large based on the opinions of a handful of fools.
You have a point. "Motivations" such as this can actually hurt morale and lead to in-fighting and nasty politics. Mary Poppendieck wrote a great essay on this subject [Warning: PDF]. It's more geared towards corporate environments but a lot of the same principles still apply.
Android devices can mount loopback file systems, overcoming FAT's lack of unix permissions. They did it to install Debian on the G1's SD card.
Funny, but you've got a point. What would a potential employer think when, upon googling your name, they learn that you're so good at hiding malicious code that you won a contest for it. Would you hire that guy?
It's not worth the $100 gift certificate.
Most of Android in general (ie new code) is Apache 2.0. Parts of it use other licenses; Linux is GPL, Webkit is LGPL, SQLite is Public Domain, etc. Patches they submit to those upstream projects maintain the original license of that project.
Citation
If you're gonna be fiddling with the volume to make the algorithm work, then the algorithm is pointless. You may just as well watch TV normally with no algorithm, then turn down the volume when the commercial break starts. There's no benefit there.
That may be true, but their preferences only work if OpenDNS can tell which networks are yours. They detect this when you use your browser to log into the control panel, or if you install client-side software (OpenDNS Updater, which is Win\Mac only). You could do it with DynDNS too, but not everyone uses that.
Anyway I'd rather not go through all that effort, and would prefer the NXDOMAIN behavior to be the default for anonymous requests.
For me, the dealbreaker with OpenDNS is that, when you type in a non-existant domain, OpenDNS resolves it to an IP that gives you their custom search page. The standards compliant response would be NXDOMAIN, which is what Google (and some others) provide. This alone was enough to make me switch away from OpenDNS.
The performance really depends on the browser's architecture, which is comprised of a lot of parts and potential bottlenecks.
Chrome and Chromium, for example, are heavily multi-processed and handle large amounts of tabs\plugins very nicely. It certainly doesn't hurt that they were designed from the ground up for this kind of behavior.
You absolutely can use that in commercial products. You can also create derivative works and not release the source.
Apache 2.0 is considered a "commerce friendly" open source license (whatever that means). You'll see it in commercial products like Android and the Apache web server.
Wikipedia entry
Apache 2.0 License full text
I'd like to have real OO syntax
What is it about JS's OO syntax that isn't "real"?
Is it because it's prototype-based instead of the class-based paradigm that you're probably used to? There are actually some advantages (and disadvantages) to this approach. Just because it may not be what you're used to or comfortable with doesn't make it bad.
The Garmin Nuviphone G60 is a Linux device, but it does not run Android.
Relevant Engadget article. A quick google search will give you more sources.
For android can you go and find the 2.0 SDK anywhere? Nope. So much for Verizon's claims about 'droid being 'open'.
The Android 2.0 SDK is right here. And btw, Verizon has little or nothing to do with the SDK.
This is precisely why mobile web apps make sense for apps that don't really need to be fully native.
You may even wrap that web app in a native container if it makes sense to do so.
... forced to use Java with non-standard bytecode. One might even suggest that Google has done this on purpose, in order to limit interoperability and push users towards its proprietary web services.
How Dalvik or its bytecode would accomplish this feat is left to the imagination. Anyone wanna clear this up for me?
I posted a response in TFA that points out that the Dalvik VM is also free software licensed under Apache 2.0
Source Code for Dalvik VM
Apache 2.0 License, embedded in Dalvik source repository.