>>Java GUI is slower than native alternatives
>Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program.
SWT == Native widget bindings. This is why you get to chose if you want to download the "Motif" or "GTK" version of Eclipse for Unix systems... That being said, GUI's in Java tend to be slow (IMHO) mainly because the developers writing them don't properly use the EventQueue and helper threads correctly. Writing a GUI which doesn't block in Java is somehow conceptually harder than in C/C++ even though the tools/methods are part of the SDK. Dunno why that is...
>>Java is not supported by all platforms
>You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old).
This is sorta non-argument. Every platform has it's own JVM (just like every platform has its own C compiler). The problem is that JVM's are large, and often liscensed differently. (For example, HP has a funky license) With a compiled language like C, you have to track down compiliers for every platform you support, but you only have to ship the resulting binary. For Java, you have to ship the JVM which you have a lot less control over. Now, other interpreted languages, like Perl, have the same need to provide the "VM" but there are fewer providers. (Unlike Java which has a ton of different implementors all working towards the same "spec")
I'm not a doctor. I can barely spell doctor. But, I do know this from personal experience:
It is definitely possible to make yourself physically sick if you are mentally convinced you are sick.
I spent years fighting near constant bouts of nausea. Saw a slew of specialists, had scans, tests, X-rays, pokes, prods, and pills. Nothing helped. After a few years I began to realize it was the situtations I was in that seemed to induce my nausea... gee could it be mental?
Short story: yes. I had(have?) "Social Phobia" before it was the cool thing (like ADHD that every third kid has). The damnest thing is that once I knew what was wrong, and was positive my feeling sick was purely in my head, I discovered it was still impossible to not feel "sick" sometimes. It's just like being scared of flying. You can be on a plane and rationally know that you are safer than in your car, but still be terrified at the same time.
My feeling is that a lot of these MCS people just freak out when they smell something "odd". I doubt there is a single treatment to snap these people out of their loop. Therarpy did nothing for my problem, but the slightest taste of an SSRI drug fixed me like flipping a switch. For other people, drugs just make them feel nasty, and talking things out helps.
The point is, I think there is something wrong with people who "have" MCS, and it can be serious, but no amount of avoid the "bad chemicals" is going to help them.
Take two, call me in the morning. Don't sue. No for use with certain sets, your mileage may vary...
Okay, I agree that if the EULA sez: "say something objectionable, and we'll forward tapes of all your calls to the police, FBI, and your mom" then this is bad. But perhaps this just covers communications with their customer support people? For example, if I call up and start threatening to kill the service rep, isn't it reasonable (and probably responsible) for the company to report me to the relevant authorities if they think I might be serious?
I have to admit haven't managed to find the section the author mentioned during my brief scans of the three links, but it's a bit early to be reading EULA's for crap I didn't even buy.:)
I disagree. Think about how many cases there have been of an institution expressing displeasure with Windows and desire to look at something other, and suddenly MS is there with huge discounts and licensing deals?
Oh, boy, are you in for a suprise! Have you ever read a EULA? Microsoft and IBM would probably piss their pants laughing if you try to pin a liability suit on them.
If the case went to court, yes. But there is a lot more to it than that. The hospital wouldn't win in court, but the vendor would get annihilated in the marketplace by a saavy customer.
When your using free software, and you threaten to not only not buy any more, but tell your friends not to either, it doesn't really make your problem better.
When you've got a big name vendor, you've got a lot of leverage. Threaten to defer future sales, be a reference customer for a competitor, or make a stink in a trade publication and you'll get pretty much anything you want. The argument of "we do a lot of business with you, and we're not happy" works a lot better when used on a vendor you actually pay.
It's a lot harder to tell a paying customer: "too bad, you shouldn't have done something so stupid."
In college, (in Baltimore, MD), I had a roommate with a beat-to-hell Saab 900. The factory "stereo" worked out of one speaker intermittantly, and only if you occassionally pounded on the dash with the "Club" to jiggle the magic wires back into contact.
My roommate had one of the CD-to-tape adapters, which he left inserted into the tape deck. (He took the discman out). One night, someone broke the windows, climbed in, and cut the wires to the tape adapter, and stole them! (The adapter itself wouldn't eject without the car being started or the key in the ACC position).
Wires! They broke in for wires they could clearly see! And even if the adapter had been easily removed, we're talking about a 10 buck item new.
I've got a hard time beleiving this. I know that all Thinkpad's have a password you can set on the harddrive which can't be disabled. (Or can only be disabled by IBM or a spindle transplant depending on who you beleive....)
Self destructing hardware is more of a liability than an assest. If something is sensitive enought to require this sort of protection, then: 1) It shouldn't come in easy-to-carry sizes, and 2) the risk (and cost) of accidental destruction is probably greater than the risk of actual theft.
The AS/400 hardware is built like a tank. You have to respect anything that's attitude towards Windows compatibility is: "yeah, you can add a daughter card, and we'll sandbox that crap on there..."
The big iron z/OS (formally S/390) machines are supposed to be even beefier. They have the ability to virtualize a processor if one becomes damaged instantly.
Am I understanding you correctly? You're saying it's illegal to take a photograph of a priced item in a store?(!)
Is the in the USA? EU? It's not that I don't beleive you, I just am amazed that's illegal. I understand that it might be illegal to take photographs inside someone's place of business without permission, but what about an outdoor vendor in a public location? Is it legal for me to stand on the sidewalk and photograph the visible items and prices?
There's no sane reason why RFID should have a feature added that would allow wireless re-writes. It costs more and it only adds a security issue.
While I agree with you for certain bits of data, I think you are over-generalizing. Data like item identifiers used to say "this is a 12-pack of Pepsi" should be static. But other bits of data, like the date the item was last inventoried, and the ID of the employee who performed the inventory would be valuable rewritable fields. Sure, some jackass could come in an overwrite all the inventory fields with "RFID iz teh suckz", but the same jackass could take down those inventory stickers you sometime see, or peel off all the barcodes.
I don't like the idea of RFID being used to track consumer purchasing, but I can certianly see it's appeal.
Can you honestly tell me that the government is going to hire a panel of people to check in in-depth source changes on OSS projects? People who are familiar enough that they can catch an exploit that may only take 3-4 lines of code to perform?
There are different types and levels of certification of software used by the govenment. For example, a lot of the FIPS (Federal Information Processing Standards) guidelines apply to crypto. And there are levels of them. The simpliest levels only require passing a test suite, but the more complex levels REQUIRE external line-of-code auditing, formal mathematical models, etc... Very expensive, very in depth.
I've worked on projects which went for lower level certifications, and while there is a lot of BS, it's also clear that there it would be nearly impossible to trojan the code and anything other than the lowest levels of code.
Software has specs just like everything else. The higher the risk, the higher the inspection bar. The flavor of Unix used to control the Boeing 777 airplanes was audited in amazing depth because a bug could have life-or-death consequences. The code used to host some less-than-critical NASA webserver is likely off-the-shelf. If it fails, big deal. The impact is commisurate with price.
As for trojans, I beleive sneaking something nefarious into FOSS is a lot harder than into something commerical because the source of the FOSS is always available for inspection. With closed-source, you give the code to an auditer, they audit it as quickly as possible (because it is a business) and give it back. Once the source is returned, there is no oppertunity to audit. There is no chance of some motivated nerd with a personal project downloading the source and stumbling accross something the auditers missed. If the end-user notices something "fishy", they have no way to investigate it themselves in their own environment.
Okay.... one last point...
On a project I was involved with, we used a very fancy cryptographic co-processor to do things. The co-processor was certified to FIPS-3, and later became certified to FIPS-4. (which was a BIG deal, it was the first device of it's type to EVER to reach that level) Funny thing was, every once in a great while, my code would reject a valid digital signature. It took a long time, but it turned out that the card's firmware had a bug which caused a certian mode if SHA1 to digest incorrectly if a certain pattern of bits occurred in a few specific places. It was a bug in the software, not a trojan, but the point is that even in a closed source environment which is heavily audited, stuff slips through. I doubt I would have been able to determine the bug was in the software if I wasn't an expert user of the software, and didn't have a direct line to the engineers who made the hardware. (We work for the same parent company...) A third-party customer (even the government) would have had a LOT harder time. If the source was open, that third-party is at least on equal footing should they choose to look into matters themselves.
Interesting approach. I'd pretty much resigned myself to the need to spend a ton of time soldering and provide my own controller, but I hadn't thought about cutting the board.
The whole idea that "5 users is enough" for a UI is misleading. I'm far from an expert, but I am theoretically a trained "Cooper Interactive Design Engineer". (Woohoo, let's here it for a week and a half of classes and some books!)
The problem is that you really need to build archtypical "personas" for each of the major "roles" which use the product. The way people use a product is greatly influenced by what they are doing with it.
A product with only a few clearly defined use-cases, the number of required test users could easily be as low as five, but Gnome is really a lot more. These tests weren't just on the widget set, but on the applications which make up the Gnome Desktop. The way a programmer uses these is likely to differ from how a graphic artist uses them, which is likely to differ from how the average web-browsing user is going to use them.
I'm not slagging on the study. Frankly I'm delighted someone is doing it, but Linux (and yes I know Gnome isn't just Linux...) tends to be an operating system which supports a broad spectrum of users.
The site is throughly suspended, so I can't RTFA, but I'm very interested. I've wanted to make my own "custom" keyboard for some time, but the limiting factor for me is how/where to get switches which have the proper "action".
Size and placement is great, but the way a key feels when pressed, how it "breaks", and the speed and feedback it returns with are just as important. Most keyboards I've taken apart either have a fairly specialized switch molded directly into the base plastic, or use a rather complicated system of guide wire slides and a simple membrane switch. Neither of these is really suited for reproduction or modification by the average tinkerer.
So, the question is, does anyone have any cleaver suggestions?
I don't know enough about the pro/con's of hemp to take sides, but I'm curious, does the anti-hemp side argue that it would be difficult to tell the difference between a field of non/low THC hemp and high-end THC containing hemp? It strikes me that if they can make a case that "weed is bad" then it's pretty easy to say that non-THC hemp is bad because I could be growing a small patch of THC hemp in the middle of my huge field undetected.
I'm not looking for pro or anti hemp stuff, just if this is a known argument. (And I suppose playing devil's advocate a little...)
Interesting idea, but it seems the bet already took "nerdy cleverness" into account:
"Since Stephen has changed his view and now believes that black holes do not destroy information, I expect him [and Kip] to concede the bet," Preskill told New Scientist. The duo are expected to present Preskill with an encyclopaedia of his choice "from which information can be recovered at will".
(And I use "nerdy cleverness" as a compliment here...)
The point isn't the govenment trying to regulate PBS, it's the government suddenly jacking up the fines for behavior deemed indecent and aggressively pursuing all violators.
There are laws against swearing in public too, but they are enforced with better discression. If I go around a playground talking to kids in language laced with profanity, I bet the cops will want to talk to me. (And as well they should) But if I'm talking with a friend on the street, and happen to swear when a kid walks by, I shouldn't have to pay a fine or go to jail.
PBS is a lot less able to take the finacial hit if they get cited for a violation, than say, FOX or the WB. And ask yourself, if your kids had to watch a show with some swearing in it, do you think the show on PBS or the show on another network would be more likely to use those words with a modicum of decency?
The execution path is different between the profiled and non-profiled library, so you can not be 100% assured you are getting the same result.
To engage a profiled library you have to stop and start the target process, and often play all sorts of pre-load and path games.
Looking into the kernel requires even more invasion, and can mean rebooting the server.
Basically, the idea here is that you don't have to use a possibly "different" library, and you can instrument code on the fly (without stopping the process or the box). This is really nice for production boxes where any interruption or change of software is a really big deal.
What's the exact point of this? Making the broadcaster provide proof of their own infraction? Even though I'm no friend of the broadcasting industry, and they don't have 5th Amendment rights, this idea seems like a lot of overhead for the ability to self-incriminate.
Assuming editing the recordings is a major no-no (and totally defeats the purpose) the recording has to be the same quality/resolution as the original feed. At "low-def" resolutions of 320x240, a person flashing their naughty bits in the background may be sufficently pixlated to be "decent", but at HDTV resolutions, may be offensive. (Think about the screencaps of the "nipple incident"...) So, really, the stations should be required to keep all 2160 hours of previous HDTV broadcasts archived. I'm not sure what that would be stored on, but it's a gi-normous amount of data.
Even for standard "low-def" TV, assume the stations can record onto a theoretical 4 hour tape at broadcast quality. (I know, they use Beta, or something exotic, so I'm spitballing here....) Anyway, thats:
(90 days * 24 hours) / 4 hours a tape = 540 tapes
Which need to be labelled, tracked, stored, rotated, etc... Ouch.
And what about syndicated stations? I have a friend who works in the news, and she told me that local stations often tweak what they get from the network feed to fit the local audience. So every station is going to have to track a lot of duplicate data.
Funny thing is, they actually only do upgrade about every 4-6 months. They spend more time piloting than we spend developing and testing. (Good for them.) By the time they are ready for a production rollout, they usually skip a level.
The product I work on is currently on roughly a quarterly schedule. (Our customers demand it.) The problem is, that with development that "fast" most innovation gets throw out the door. Each "release" is pretty much a bug-fix with maybe one or two absolutely-critical new features. The complexity of keeping up with multiple linked development streams is enormous, and the result is more mistakes and a much lower level of code refactoring.
I can't imagine physical products are much different. Sure, you get a new model every 6 months, but what's really changed? Personally, I'd like to wait a year, and get a substantial benefit. My experience is that shorter cycles are good for the marketing droids (who always have vaporware "almost" ready to release) and bad for the customer and the developer.
Oh, and another funny thing. The same customers who demand quarterly releases also bitch about the fact they have to migrate ever four months. I told them there was a simple solution to that problem...:)
This is known as "Bait & Switch" and is highly illegal for large retailers like best buy.
I always thought "bait & switch" required the vendor to advertise something they either didn't have or wouldn't sell you as advertised. For example, isn't it legal (but pretty immoral) to say "Come to Crazy Bob's and buy a widget for the low, low price of $10" and then try to convince the customer that they could buy the $10 widget, but what they really should buy is the far superior $50 super-widget? I thought you had to say something like: "Nope, fresh outta $10 widgets, but take a look at these $50 ones..." (when they never had or intended to sell the $10 widgets in the first place)
I'm assuming from your nick that you understand this sort of thing better than I do. So, have I been wrong about bait & switch all this time?
Thankfully, I'm far from an expert on torture, but my understanding was that with the right interrogator, torture pretty much always works, but it depends on being able to keep the subject from going totally insane.
Once someone is broken down too far, they'll agree with anything and even make up detailed stories which support what the interrorgator wants to hear. It's a survival instinct. If I think you'll stop hurting me if I tell you the sky is green, it's entirely likely I'll eventually beleive the sky is green and tell you so. Breaking down someone's sense of ethics/responsibility/community is hard, and it's a short step to breaking down their sense of reality.
So yeah, it works, in that the victim will tell you anything. But the victim has to be in a mental state to actually know the right answer, and therein lies the problem.
Of course, in a lot of instances, the goal of torture is simply torture, so the information is moot. Wonderful world, eh?
The increase in international outsourcing is only going to compound this problem in the future. In my experience the outsourcing firms feel even less "investment" in codebases they contribute to than normal contractors. This, coupled with a definite mercenary attitude towards development can lead to some very dubious code. They are paid for rapid, loosely overseen development, aren't responsible for support, and their salary isn't based on the success or failure of the product. Even if they are held accountable for "borrowed" code, enforcing copyright and IP laws internationally is extremely difficult in the best of situations.
A related issue is where to set the line when copying is fair-use and when it becomes theft. The tutorials from Sun for Java contain some fairly useful code, but they also have a Sun copyright plastered across their headers. For example, the lack of a "TreeTable" widget in Java is compensated for by a detailed example of rolling your own, here. But if you look at the source, some of it is free of any headers, and other bits contain things like:
/* * @(#)JTreeTable.java 1.2 98/10/27 * * Copyright 1997, 1998 by Sun Microsystems, Inc., * 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. * All rights reserved. * * This software is the confidential and proprietary information * of Sun Microsystems, Inc. ("Confidential Information"). You * shall not disclose such Confidential Information and shall use * it only in accordance with the terms of the license agreement * you entered into with Sun. */
Personally, I'd never allow code derived from this into a sourcetree I managed out of paranoia, but I can completely see how most people (perhaps rightly) would see this code as fair game for reuse. Picking up code from an acquired company or contractor which borrows from code of similiar origins is almost unavoidable.
Close. It's that piracy isn't discovered. I suspect there is a lot more code "borrowed" in the closed-source ranked, than the open-source ones. Closed source tends to be more deadline driven, and is a LOT less throughly vetted. Most open-source is done for ego or altruistic reasons. (take your pick) But the incentive to steal (bonuses, making deadlines, etc) coupled with the much lower chance of detection might tempt people.
Slashdot Mirror
>>Java GUI is slower than native alternatives >Not really. Tried it recently? eclipse is a good example (eclipse.org) of fast java program. SWT == Native widget bindings. This is why you get to chose if you want to download the "Motif" or "GTK" version of Eclipse for Unix systems... That being said, GUI's in Java tend to be slow (IMHO) mainly because the developers writing them don't properly use the EventQueue and helper threads correctly. Writing a GUI which doesn't block in Java is somehow conceptually harder than in C/C++ even though the tools/methods are part of the SDK. Dunno why that is... >>Java is not supported by all platforms >You can get a JVM for most if not all platforms. It also works on XP (don't confuse MS JVM as being a workable JVM, its years old). This is sorta non-argument. Every platform has it's own JVM (just like every platform has its own C compiler). The problem is that JVM's are large, and often liscensed differently. (For example, HP has a funky license) With a compiled language like C, you have to track down compiliers for every platform you support, but you only have to ship the resulting binary. For Java, you have to ship the JVM which you have a lot less control over. Now, other interpreted languages, like Perl, have the same need to provide the "VM" but there are fewer providers. (Unlike Java which has a ton of different implementors all working towards the same "spec")
It is definitely possible to make yourself physically sick if you are mentally convinced you are sick.
I spent years fighting near constant bouts of nausea. Saw a slew of specialists, had scans, tests, X-rays, pokes, prods, and pills. Nothing helped. After a few years I began to realize it was the situtations I was in that seemed to induce my nausea... gee could it be mental?
Short story: yes. I had(have?) "Social Phobia" before it was the cool thing (like ADHD that every third kid has). The damnest thing is that once I knew what was wrong, and was positive my feeling sick was purely in my head, I discovered it was still impossible to not feel "sick" sometimes. It's just like being scared of flying. You can be on a plane and rationally know that you are safer than in your car, but still be terrified at the same time.
My feeling is that a lot of these MCS people just freak out when they smell something "odd". I doubt there is a single treatment to snap these people out of their loop. Therarpy did nothing for my problem, but the slightest taste of an SSRI drug fixed me like flipping a switch. For other people, drugs just make them feel nasty, and talking things out helps.
The point is, I think there is something wrong with people who "have" MCS, and it can be serious, but no amount of avoid the "bad chemicals" is going to help them.
Take two, call me in the morning. Don't sue. No for use with certain sets, your mileage may vary...
I have to admit haven't managed to find the section the author mentioned during my brief scans of the three links, but it's a bit early to be reading EULA's for crap I didn't even buy. :)
I disagree. Think about how many cases there have been of an institution expressing displeasure with Windows and desire to look at something other, and suddenly MS is there with huge discounts and licensing deals?
If the case went to court, yes. But there is a lot more to it than that. The hospital wouldn't win in court, but the vendor would get annihilated in the marketplace by a saavy customer.
When your using free software, and you threaten to not only not buy any more, but tell your friends not to either, it doesn't really make your problem better.
When you've got a big name vendor, you've got a lot of leverage. Threaten to defer future sales, be a reference customer for a competitor, or make a stink in a trade publication and you'll get pretty much anything you want. The argument of "we do a lot of business with you, and we're not happy" works a lot better when used on a vendor you actually pay.
It's a lot harder to tell a paying customer: "too bad, you shouldn't have done something so stupid."
My roommate had one of the CD-to-tape adapters, which he left inserted into the tape deck. (He took the discman out). One night, someone broke the windows, climbed in, and cut the wires to the tape adapter, and stole them! (The adapter itself wouldn't eject without the car being started or the key in the ACC position).
Wires! They broke in for wires they could clearly see! And even if the adapter had been easily removed, we're talking about a 10 buck item new.
Self destructing hardware is more of a liability than an assest. If something is sensitive enought to require this sort of protection, then: 1) It shouldn't come in easy-to-carry sizes, and 2) the risk (and cost) of accidental destruction is probably greater than the risk of actual theft.
The big iron z/OS (formally S/390) machines are supposed to be even beefier. They have the ability to virtualize a processor if one becomes damaged instantly.
Is the in the USA? EU? It's not that I don't beleive you, I just am amazed that's illegal. I understand that it might be illegal to take photographs inside someone's place of business without permission, but what about an outdoor vendor in a public location? Is it legal for me to stand on the sidewalk and photograph the visible items and prices?
While I agree with you for certain bits of data, I think you are over-generalizing. Data like item identifiers used to say "this is a 12-pack of Pepsi" should be static. But other bits of data, like the date the item was last inventoried, and the ID of the employee who performed the inventory would be valuable rewritable fields. Sure, some jackass could come in an overwrite all the inventory fields with "RFID iz teh suckz", but the same jackass could take down those inventory stickers you sometime see, or peel off all the barcodes.
I don't like the idea of RFID being used to track consumer purchasing, but I can certianly see it's appeal.
There are different types and levels of certification of software used by the govenment. For example, a lot of the FIPS (Federal Information Processing Standards) guidelines apply to crypto. And there are levels of them. The simpliest levels only require passing a test suite, but the more complex levels REQUIRE external line-of-code auditing, formal mathematical models, etc... Very expensive, very in depth.
I've worked on projects which went for lower level certifications, and while there is a lot of BS, it's also clear that there it would be nearly impossible to trojan the code and anything other than the lowest levels of code.
Software has specs just like everything else. The higher the risk, the higher the inspection bar. The flavor of Unix used to control the Boeing 777 airplanes was audited in amazing depth because a bug could have life-or-death consequences. The code used to host some less-than-critical NASA webserver is likely off-the-shelf. If it fails, big deal. The impact is commisurate with price.
As for trojans, I beleive sneaking something nefarious into FOSS is a lot harder than into something commerical because the source of the FOSS is always available for inspection. With closed-source, you give the code to an auditer, they audit it as quickly as possible (because it is a business) and give it back. Once the source is returned, there is no oppertunity to audit. There is no chance of some motivated nerd with a personal project downloading the source and stumbling accross something the auditers missed. If the end-user notices something "fishy", they have no way to investigate it themselves in their own environment.
Okay.... one last point...
On a project I was involved with, we used a very fancy cryptographic co-processor to do things. The co-processor was certified to FIPS-3, and later became certified to FIPS-4. (which was a BIG deal, it was the first device of it's type to EVER to reach that level) Funny thing was, every once in a great while, my code would reject a valid digital signature. It took a long time, but it turned out that the card's firmware had a bug which caused a certian mode if SHA1 to digest incorrectly if a certain pattern of bits occurred in a few specific places. It was a bug in the software, not a trojan, but the point is that even in a closed source environment which is heavily audited, stuff slips through. I doubt I would have been able to determine the bug was in the software if I wasn't an expert user of the software, and didn't have a direct line to the engineers who made the hardware. (We work for the same parent company...) A third-party customer (even the government) would have had a LOT harder time. If the source was open, that third-party is at least on equal footing should they choose to look into matters themselves.
Thank you.
The problem is that you really need to build archtypical "personas" for each of the major "roles" which use the product. The way people use a product is greatly influenced by what they are doing with it.
A product with only a few clearly defined use-cases, the number of required test users could easily be as low as five, but Gnome is really a lot more. These tests weren't just on the widget set, but on the applications which make up the Gnome Desktop. The way a programmer uses these is likely to differ from how a graphic artist uses them, which is likely to differ from how the average web-browsing user is going to use them.
I'm not slagging on the study. Frankly I'm delighted someone is doing it, but Linux (and yes I know Gnome isn't just Linux...) tends to be an operating system which supports a broad spectrum of users.
Size and placement is great, but the way a key feels when pressed, how it "breaks", and the speed and feedback it returns with are just as important. Most keyboards I've taken apart either have a fairly specialized switch molded directly into the base plastic, or use a rather complicated system of guide wire slides and a simple membrane switch. Neither of these is really suited for reproduction or modification by the average tinkerer.
So, the question is, does anyone have any cleaver suggestions?
I'm not looking for pro or anti hemp stuff, just if this is a known argument. (And I suppose playing devil's advocate a little...)
Interesting idea, but it seems the bet already took "nerdy cleverness" into account:
(And I use "nerdy cleverness" as a compliment here...)
There are laws against swearing in public too, but they are enforced with better discression. If I go around a playground talking to kids in language laced with profanity, I bet the cops will want to talk to me. (And as well they should) But if I'm talking with a friend on the street, and happen to swear when a kid walks by, I shouldn't have to pay a fine or go to jail.
PBS is a lot less able to take the finacial hit if they get cited for a violation, than say, FOX or the WB. And ask yourself, if your kids had to watch a show with some swearing in it, do you think the show on PBS or the show on another network would be more likely to use those words with a modicum of decency?
- The execution path is different between the profiled and non-profiled library, so you can not be 100% assured you are getting the same result.
- To engage a profiled library you have to stop and start the target process, and often play all sorts of pre-load and path games.
- Looking into the kernel requires even more invasion, and can mean rebooting the server.
Basically, the idea here is that you don't have to use a possibly "different" library, and you can instrument code on the fly (without stopping the process or the box). This is really nice for production boxes where any interruption or change of software is a really big deal.Assuming editing the recordings is a major no-no (and totally defeats the purpose) the recording has to be the same quality/resolution as the original feed. At "low-def" resolutions of 320x240, a person flashing their naughty bits in the background may be sufficently pixlated to be "decent", but at HDTV resolutions, may be offensive. (Think about the screencaps of the "nipple incident"...) So, really, the stations should be required to keep all 2160 hours of previous HDTV broadcasts archived. I'm not sure what that would be stored on, but it's a gi-normous amount of data.
Even for standard "low-def" TV, assume the stations can record onto a theoretical 4 hour tape at broadcast quality. (I know, they use Beta, or something exotic, so I'm spitballing here....) Anyway, thats:
(90 days * 24 hours) / 4 hours a tape = 540 tapes
Which need to be labelled, tracked, stored, rotated, etc... Ouch.
And what about syndicated stations? I have a friend who works in the news, and she told me that local stations often tweak what they get from the network feed to fit the local audience. So every station is going to have to track a lot of duplicate data.
Seems like a lot of cost for a possible nipple.
Funny thing is, they actually only do upgrade about every 4-6 months. They spend more time piloting than we spend developing and testing. (Good for them.) By the time they are ready for a production rollout, they usually skip a level.
I can't imagine physical products are much different. Sure, you get a new model every 6 months, but what's really changed? Personally, I'd like to wait a year, and get a substantial benefit. My experience is that shorter cycles are good for the marketing droids (who always have vaporware "almost" ready to release) and bad for the customer and the developer.
Oh, and another funny thing. The same customers who demand quarterly releases also bitch about the fact they have to migrate ever four months. I told them there was a simple solution to that problem... :)
I always thought "bait & switch" required the vendor to advertise something they either didn't have or wouldn't sell you as advertised. For example, isn't it legal (but pretty immoral) to say "Come to Crazy Bob's and buy a widget for the low, low price of $10" and then try to convince the customer that they could buy the $10 widget, but what they really should buy is the far superior $50 super-widget? I thought you had to say something like: "Nope, fresh outta $10 widgets, but take a look at these $50 ones..." (when they never had or intended to sell the $10 widgets in the first place)
I'm assuming from your nick that you understand this sort of thing better than I do. So, have I been wrong about bait & switch all this time?
Once someone is broken down too far, they'll agree with anything and even make up detailed stories which support what the interrorgator wants to hear. It's a survival instinct. If I think you'll stop hurting me if I tell you the sky is green, it's entirely likely I'll eventually beleive the sky is green and tell you so. Breaking down someone's sense of ethics/responsibility/community is hard, and it's a short step to breaking down their sense of reality.
So yeah, it works, in that the victim will tell you anything. But the victim has to be in a mental state to actually know the right answer, and therein lies the problem.
Of course, in a lot of instances, the goal of torture is simply torture, so the information is moot. Wonderful world, eh?
The increase in international outsourcing is only going to compound this problem in the future. In my experience the outsourcing firms feel even less "investment" in codebases they contribute to than normal contractors. This, coupled with a definite mercenary attitude towards development can lead to some very dubious code. They are paid for rapid, loosely overseen development, aren't responsible for support, and their salary isn't based on the success or failure of the product. Even if they are held accountable for "borrowed" code, enforcing copyright and IP laws internationally is extremely difficult in the best of situations.
A related issue is where to set the line when copying is fair-use and when it becomes theft. The tutorials from Sun for Java contain some fairly useful code, but they also have a Sun copyright plastered across their headers. For example, the lack of a "TreeTable" widget in Java is compensated for by a detailed example of rolling your own, here. But if you look at the source, some of it is free of any headers, and other bits contain things like:
Personally, I'd never allow code derived from this into a sourcetree I managed out of paranoia, but I can completely see how most people (perhaps rightly) would see this code as fair game for reuse. Picking up code from an acquired company or contractor which borrows from code of similiar origins is almost unavoidable.
Close. It's that piracy isn't discovered. I suspect there is a lot more code "borrowed" in the closed-source ranked, than the open-source ones. Closed source tends to be more deadline driven, and is a LOT less throughly vetted. Most open-source is done for ego or altruistic reasons. (take your pick) But the incentive to steal (bonuses, making deadlines, etc) coupled with the much lower chance of detection might tempt people.