Users are not even interested in this, they don't care about their privacy. For a good example of just that go take a look at facebook. No need for anyone to worry about protecting those who do not care to be protected.
Most users (and I'd include myself in this list) are very interested in some aspects of privacy. I care quite a bit if someone access my bank account and takes my money. I don't care at all if someone wants to send me an email, or get in touch with me because of a common interest. Privacy does not have to equate to invisibility.
While a particular group may have been responsible for the data theft, Sony is still responsible for the irresponsible storage that they used to enable the theft. Good (industry standard) practices around credit card retention, such as gateway tokenization, would have drastically reduced the financial implications. There would still have been privacy implications, but by not storing card numbers they'd actually have made the information much less appealing to hackers as well.
Having to type the application name is much slower than just selecting it from the menu, or clicking the icon on the desktop. Particularly when said icon or menu option also passes whatever command-line options you need so it's already configured to do whatever you want it to do.
Seems like that could be fixed. In OSX, its nice having the choice to either mouse-n-click or (my preference) just hit Apple-Space and type a few letters of the name, then hit enter. Having to do a combined mouse/keyboard movement would be a big bucket of fail, though.
There is. Almost every Merchant Gateway worth their salt offers it, too. Not using an "expert" (and typically almost-free) service like this is just arrogance coming from a big player like Sony. Let the card industry specialists do what they do best, which frees the seller-of-shine up to do what they do best.
With Authorize, its called "Customer Information Management". With Sage Payments, its the "Vault." And so on. Works exactly as described, and the only thing you can do with the token (if you steal one) is charge an arbitrary amount of money to a credit card - that goes to the merchant bank account associated with the initial charge.
As a merchant or service provider, you rarely if ever need anything more.
Its the same problem that you get with AmTrak (which is also set up exactly backwards to other countries' systems), in which a private company owns the infrastructure and government, if it plays at all, is running on top of it (as a 2nd class citizen).
When there are truly limited resources, you have local government own the conduits and allow businesses to compete to provide services. Its how the electric grid works, as well, in most places.
AdBlock doesn't redistribute the modified work; it is entirely on behalf of the reader. If MediaCom distributed a browser that pulls these shenanigans, or gave users a proxy to install on user machines instead of running their own customers-can't-opt-out proxy, then they would likely be in the clear.
AdBlock also doesn't change the work itself (where work is defined as the HTML file). It alters the display of the work on your screen, sure, but then again so does changing the size of your monitor. Big difference, legally.
The main reason is because Task Manager is often used to try and regain control of a system which has stopped responding. It must be a small and efficient program so that it can be loaded and used when the system is low on resources (like processor time, memory, or even handles). It provides enough information for the user to determine resource usage for the system and running processes, and provides enough functionality for user to manage them. It is not meant to be used for in-depth performance analysis or detailed process information.
Where they went wrong, in my opinion, is not replacing Task Manager with two other programs. They should have the über-powerful task manager (like Process Explorer) tucked away for the experts to use, and something akin to the OSX "Force Quit..." option for everyone else. In case you're not a Mac user, "Force Quit..." launches from the system menu and opens a very simple dialog with a list of public program names, some of which (if they start misbehaving) are identified with a "(Not Responding)" label. That's all. They're alphabetical, and you can't do anything except quit them (well, it also shows Finder but the quit button turns into a "restart" button in that case).
Not shoving everything into a single app can often be a more elegant solution.
First, there's a difference between 20% useful legit content and.0002% useful legit content, at least in the real world.
Even if only 1% of bittorrent traffic is used for legitimate purposes like Linux or other FOSS, that proves that bittorrent has a legitimate use and consequently should not be restricted.
Hmm. Not so much, I'm afraid. If you take that argument to its conclusion, everything (absolutely everything) should be permitted, because you can always find some legitimate use for it. I'm a huge fan of the ideas behind Bittorrent, but I won't try to argue that the vast majority of the service is used for illegal fileswapping. I also wouldn't advocate for its banning (if that was even possible), but I completely understand why organisations who feel that they're legally liable for infringing content moving across their networks would themselves attempt to ban it.
Not really. They could continue to show your previously buffered content, appropriately upscaled, and then download new content (possibly, if they were nice and you had bandwidth to spare, back-filling over your existing buffer as well so you'd get the higher definition stream sooner). This is, for example, how Netflix streaming does it.
And how many of those industrial networks are connected up over an open inbound port to "teh interwebz", going to a server that IT has never heard of, which is then on the same network segment as a ton of confidential information and/or massively expensive (and potentially lethal if reprogramed) equipment?
Depending on the poster's country, there may be a lot of regulatory, compliance, legal, and other issues at play here. This appears to be a rogue server as you cite. If I were the head of IT, I'd have it outta-there in a heartbeat and write up whomever deployed it-- on the surface and without other information, this is a problem.
WIthout more information, it sounds to me like a convenience issue for the department head, but it's a legal nightmare looking for a spot marked X-- that server, for starters.
A maintenance nightmare, too. In 3 years when the server stops working due to a drive failure, guess who's going to get the blame for not having a highly available system with regular backups? Yup - the IT department. Nobody will remember that this wasn't an officially offered service. Its quite possible that nobody will even be able to find the machine if everyone involved in setting it up the first time has moved on to somewhere else.
There's a good reason for paperwork sometimes, especially when providing what may become "essential" services to medical personnel.
You can not patent a general design, you can only patent a very specific design.
Which is why Apple isn't suing most manufacturers, but is suing the one whose product looks close enough to both the iPhone and to its patent drawings to be confused at a quick glance.
so what if they copied? its not illegal to base your product on someone else's, provided you dont ACTUALLY copy the designs.
Plenty of cars look very similar to other cars, and in some cases designers obviously take cues from others' work.
In this case it would be as if Ford released a car that looked like the 'Vette, so close that everyone thought it was one, but with a small blue oval logo on it. Which they wouldn't be able to do. There's a difference between using the concepts (2 doors, stubby trunk, long hood, etc - or capacitive touchscreen, full glass front, etc) and creating a product that looks exactly the same to a layperson. There are plenty of "iPhone concept" phones that aren't iPhone clones. This one arguably is.
And not one of those would be confused for an iPad when sitting in a retail store. That's the difference - if you look at the pictures in the suit, the Samsung products in question appear identical-enough to both the drawings in the patent and to the finished Apple products that, without close examination, you'd mistake the one for the other. Hence the lawsuit.
To use a car analogy, its the same reason that Chevy can't sell a "Horse" car that looks exactly like a Mustang but with a bowtie logo on it, even though "Two doors and a long hood are obvious," without getting the crap sued out of them by Ford.
Not if nobody else was selling minimalistic touchscreen phones before you were. The iPhone did, indeed, look completely different from everything else on the market, and for several years every "new" phone tried to look as close to it as possible in order to capture the "oh, you got an iPhone" factor that, rightly or wrongly, drove sales.
Haven't you noticed that not a single one of those phones initially released in red? Not one? Even though it was a very popular color in other lines for the other manufacturers (Nokia, Motorola, etc)? That's a copycat.
The point is they are fast to use and take great video. I'll pick up several while they are in stores and pack them away for the future. It's sad that such a great product gets dropped.
What you describe is exactly why we bought them for ourselves as well.
Its also exactly why ours haven't been used since the iPhone 4's video camera came out. Sure, the phone is missing image stabilization (btw, WTF Apple) and the quality isn't quite as good, but those facts are well-mitigated by the fact that I always have it with me... exactly the same thought process used to justify the Flip vs. an HD-capable-SLR.
Anyone who could make the leap from complex->Flip will, or has, made exactly the same leap from Flip to celphone, with a few exceptions (we still use a Flip for recording corporate video-blog footage, for example).
The only real heartache I have with java is the fact that I don't "enjoy" working with it as much as I do the scripting languages.
I guess I have better things to do then deal with any of the following shit.
Alright, I'll bite. Its actually an interesting list. We have a pretty decent real-world "100%-uptime-goal" application, a standalone common platform with internal and external API access, a few webapps, et cetera, so that's what I'll refer to here.
1. ant build shit
Nah. Never understood the fascination behind complicated project layout. Wrote a couple of basic ant scripts 4 years ago by hand, barely touched 'em since. Complicated builds are a sign of... well, something. But they're absolutely not necessary for a complicated real project.
2. xml config shit
Likewise. Admittedly we use Seam-over-J2EE for most of our stuff, but beyond tagging classes with "Oh, this one should be Stateless" or objects with "Please provide me a standard representation of this at runtime from somewhere", its not a big deal. There are 3-4 lines of XML code per interesting webpage, but that's not much compared to the XML defining the webpage itself.
3. 20 minute app startup shit
Yeah, I'd hate that too. Luckily, JBoss and all the associated apps take about 22 seconds. Which still gets annoying.
4. compiler shit
Like type checking? Dead code warnings? Everything that gives us, we don't have to write tests for, which is fine by me.
5. managers that love a language they do not have to use shit
Er... whatever.
6. container shit
Not having to worry about some of the things that containers give you is great. I define my message bus implementation over here, use it over there... works perfectly. Now, some of the container implementations (including the one we use) are far from great at certain things, but they bring a lot to the table when you're working on a 20+ server application too.
7. insane memory usage shit
Agreed here, although this is far less of a big deal than it used to be (the relatively fixed overhead is dwarfed over time by the scalability of the application). Its far more apparent on dev machines than production servers, and not very meaningful on those.
8. curly brace shit
I like curly braces, actually. Its one less thing I have to guess, one less thing that can be copy/pasted incorrectly, and it helps the compiler to help me know when I've likely done something incorrectly instead of just doing it wrong.
9. wordy language shit
One of my favorite Java features, actually. No, seriously. When I read Java code - even a few lines of sample code exercising a library written by someone else 4 years ago halfway around the world - I know what its doing. I may not understand the library calls, but I have no doubt whatsoever about the language.
This isn't a feature thats useful for small projects. Its wonderful when dealing with software written over 5-10 years by a variety of people who may or may not still work with you.
10. framework shit
Again, useless on small projects, pretty durn good on larger ones where you're working on software that can handle hundreds or thousands of parallel, complicated requests all performing complex business tasks. And no, I haven't found a Java web framework that I really like yet, but I could say that about all the frameworks I've tried, regardless of the language.
Modern Java's not bad when its used to solve problems its good at solving. The same is true for many languages - I'd never write a Windows GUI in Java, for example, nor would I reach for C# to do my next clustered platform. You can do a good job in both... but its a lot harder than it needs to be.
Yeah... its a pity that you can't add Solitaire and AIM to global policies. Then everyone would have been happy. Maybe in 2012 they'll figure out that technology.
Your approach requires that people think. People are mostly incapable of even the simplest degree of thought when it comes to such things. I don't know why - they just can't do it.
And those people would be able to figure out SELinux permissions, where 9/10 sysadmins give up at some point?
Or in this particular case, maybe they want to do that so that they can send you music over wireless when available, at higher fidelity with lower battery drain?
Slashdot Mirror
Talk about putting words in my mouth.
Users are not even interested in this, they don't care about their privacy. For a good example of just that go take a look at facebook. No need for anyone to worry about protecting those who do not care to be protected.
Most users (and I'd include myself in this list) are very interested in some aspects of privacy. I care quite a bit if someone access my bank account and takes my money. I don't care at all if someone wants to send me an email, or get in touch with me because of a common interest. Privacy does not have to equate to invisibility.
While a particular group may have been responsible for the data theft, Sony is still responsible for the irresponsible storage that they used to enable the theft. Good (industry standard) practices around credit card retention, such as gateway tokenization, would have drastically reduced the financial implications. There would still have been privacy implications, but by not storing card numbers they'd actually have made the information much less appealing to hackers as well.
Having to type the application name is much slower than just selecting it from the menu, or clicking the icon on the desktop. Particularly when said icon or menu option also passes whatever command-line options you need so it's already configured to do whatever you want it to do.
Seems like that could be fixed. In OSX, its nice having the choice to either mouse-n-click or (my preference) just hit Apple-Space and type a few letters of the name, then hit enter. Having to do a combined mouse/keyboard movement would be a big bucket of fail, though.
There is. Almost every Merchant Gateway worth their salt offers it, too. Not using an "expert" (and typically almost-free) service like this is just arrogance coming from a big player like Sony. Let the card industry specialists do what they do best, which frees the seller-of-shine up to do what they do best.
With Authorize, its called "Customer Information Management". With Sage Payments, its the "Vault." And so on. Works exactly as described, and the only thing you can do with the token (if you steal one) is charge an arbitrary amount of money to a credit card - that goes to the merchant bank account associated with the initial charge.
As a merchant or service provider, you rarely if ever need anything more.
Its the same problem that you get with AmTrak (which is also set up exactly backwards to other countries' systems), in which a private company owns the infrastructure and government, if it plays at all, is running on top of it (as a 2nd class citizen).
When there are truly limited resources, you have local government own the conduits and allow businesses to compete to provide services. Its how the electric grid works, as well, in most places.
AdBlock doesn't redistribute the modified work; it is entirely on behalf of the reader. If MediaCom distributed a browser that pulls these shenanigans, or gave users a proxy to install on user machines instead of running their own customers-can't-opt-out proxy, then they would likely be in the clear.
AdBlock also doesn't change the work itself (where work is defined as the HTML file). It alters the display of the work on your screen, sure, but then again so does changing the size of your monitor. Big difference, legally.
The main reason is because Task Manager is often used to try and regain control of a system which has stopped responding. It must be a small and efficient program so that it can be loaded and used when the system is low on resources (like processor time, memory, or even handles). It provides enough information for the user to determine resource usage for the system and running processes, and provides enough functionality for user to manage them. It is not meant to be used for in-depth performance analysis or detailed process information.
Where they went wrong, in my opinion, is not replacing Task Manager with two other programs. They should have the über-powerful task manager (like Process Explorer) tucked away for the experts to use, and something akin to the OSX "Force Quit..." option for everyone else. In case you're not a Mac user, "Force Quit..." launches from the system menu and opens a very simple dialog with a list of public program names, some of which (if they start misbehaving) are identified with a "(Not Responding)" label. That's all. They're alphabetical, and you can't do anything except quit them (well, it also shows Finder but the quit button turns into a "restart" button in that case).
Not shoving everything into a single app can often be a more elegant solution.
First, there's a difference between 20% useful legit content and .0002% useful legit content, at least in the real world.
Even if only 1% of bittorrent traffic is used for legitimate purposes like Linux or other FOSS, that proves that bittorrent has a legitimate use and consequently should not be restricted.
Hmm. Not so much, I'm afraid. If you take that argument to its conclusion, everything (absolutely everything) should be permitted, because you can always find some legitimate use for it. I'm a huge fan of the ideas behind Bittorrent, but I won't try to argue that the vast majority of the service is used for illegal fileswapping. I also wouldn't advocate for its banning (if that was even possible), but I completely understand why organisations who feel that they're legally liable for infringing content moving across their networks would themselves attempt to ban it.
Not really. They could continue to show your previously buffered content, appropriately upscaled, and then download new content (possibly, if they were nice and you had bandwidth to spare, back-filling over your existing buffer as well so you'd get the higher definition stream sooner). This is, for example, how Netflix streaming does it.
"YES" give them limited access. (you can always remove the account after they have done the scan)
Otherwise you're opening yourself to a multimillion $ law suit if there is ANY breach of the system due to your server being on the network.
If you let them check it over then subsequently there's a breach, then it's the hospitals problem.
Which attitude is exactly why most IT folk would have just said, "No," from the start.
And how many of those industrial networks are connected up over an open inbound port to "teh interwebz", going to a server that IT has never heard of, which is then on the same network segment as a ton of confidential information and/or massively expensive (and potentially lethal if reprogramed) equipment?
Depending on the poster's country, there may be a lot of regulatory, compliance, legal, and other issues at play here. This appears to be a rogue server as you cite. If I were the head of IT, I'd have it outta-there in a heartbeat and write up whomever deployed it-- on the surface and without other information, this is a problem.
WIthout more information, it sounds to me like a convenience issue for the department head, but it's a legal nightmare looking for a spot marked X-- that server, for starters.
A maintenance nightmare, too. In 3 years when the server stops working due to a drive failure, guess who's going to get the blame for not having a highly available system with regular backups? Yup - the IT department. Nobody will remember that this wasn't an officially offered service. Its quite possible that nobody will even be able to find the machine if everyone involved in setting it up the first time has moved on to somewhere else.
There's a good reason for paperwork sometimes, especially when providing what may become "essential" services to medical personnel.
You can not patent a general design, you can only patent a very specific design.
Which is why Apple isn't suing most manufacturers, but is suing the one whose product looks close enough to both the iPhone and to its patent drawings to be confused at a quick glance.
Ford to sue Chevy for producing a car that looks exactly like the Mustang down to the radio controls, but with a bowtie logo on it.
FTFY
so what if they copied? its not illegal to base your product on someone else's, provided you dont ACTUALLY copy the designs.
Plenty of cars look very similar to other cars, and in some cases designers obviously take cues from others' work.
In this case it would be as if Ford released a car that looked like the 'Vette, so close that everyone thought it was one, but with a small blue oval logo on it. Which they wouldn't be able to do. There's a difference between using the concepts (2 doors, stubby trunk, long hood, etc - or capacitive touchscreen, full glass front, etc) and creating a product that looks exactly the same to a layperson. There are plenty of "iPhone concept" phones that aren't iPhone clones. This one arguably is.
And not one of those would be confused for an iPad when sitting in a retail store. That's the difference - if you look at the pictures in the suit, the Samsung products in question appear identical-enough to both the drawings in the patent and to the finished Apple products that, without close examination, you'd mistake the one for the other. Hence the lawsuit.
To use a car analogy, its the same reason that Chevy can't sell a "Horse" car that looks exactly like a Mustang but with a bowtie logo on it, even though "Two doors and a long hood are obvious," without getting the crap sued out of them by Ford.
Not if nobody else was selling minimalistic touchscreen phones before you were. The iPhone did, indeed, look completely different from everything else on the market, and for several years every "new" phone tried to look as close to it as possible in order to capture the "oh, you got an iPhone" factor that, rightly or wrongly, drove sales.
Haven't you noticed that not a single one of those phones initially released in red? Not one? Even though it was a very popular color in other lines for the other manufacturers (Nokia, Motorola, etc)? That's a copycat.
Or possibly the A5.1, OSX being what it is.
How do you keep their loose pants on in that case? I wouldn't think that the normal spec grubby suspenders would do the trick any more.
The point is they are fast to use and take great video. I'll pick up several while they are in stores and pack them away for the future. It's sad that such a great product gets dropped.
What you describe is exactly why we bought them for ourselves as well.
Its also exactly why ours haven't been used since the iPhone 4's video camera came out. Sure, the phone is missing image stabilization (btw, WTF Apple) and the quality isn't quite as good, but those facts are well-mitigated by the fact that I always have it with me... exactly the same thought process used to justify the Flip vs. an HD-capable-SLR.
Anyone who could make the leap from complex->Flip will, or has, made exactly the same leap from Flip to celphone, with a few exceptions (we still use a Flip for recording corporate video-blog footage, for example).
The only real heartache I have with java is the fact that I don't "enjoy" working with it as much as I do the scripting languages.
I guess I have better things to do then deal with any of the following shit.
Alright, I'll bite. Its actually an interesting list. We have a pretty decent real-world "100%-uptime-goal" application, a standalone common platform with internal and external API access, a few webapps, et cetera, so that's what I'll refer to here.
1. ant build shit
Nah. Never understood the fascination behind complicated project layout. Wrote a couple of basic ant scripts 4 years ago by hand, barely touched 'em since. Complicated builds are a sign of ... well, something. But they're absolutely not necessary for a complicated real project.
2. xml config shit
Likewise. Admittedly we use Seam-over-J2EE for most of our stuff, but beyond tagging classes with "Oh, this one should be Stateless" or objects with "Please provide me a standard representation of this at runtime from somewhere", its not a big deal. There are 3-4 lines of XML code per interesting webpage, but that's not much compared to the XML defining the webpage itself.
3. 20 minute app startup shit
Yeah, I'd hate that too. Luckily, JBoss and all the associated apps take about 22 seconds. Which still gets annoying.
4. compiler shit
Like type checking? Dead code warnings? Everything that gives us, we don't have to write tests for, which is fine by me.
5. managers that love a language they do not have to use shit
Er... whatever.
6. container shit
Not having to worry about some of the things that containers give you is great. I define my message bus implementation over here, use it over there... works perfectly. Now, some of the container implementations (including the one we use) are far from great at certain things, but they bring a lot to the table when you're working on a 20+ server application too.
7. insane memory usage shit
Agreed here, although this is far less of a big deal than it used to be (the relatively fixed overhead is dwarfed over time by the scalability of the application). Its far more apparent on dev machines than production servers, and not very meaningful on those.
8. curly brace shit
I like curly braces, actually. Its one less thing I have to guess, one less thing that can be copy/pasted incorrectly, and it helps the compiler to help me know when I've likely done something incorrectly instead of just doing it wrong.
9. wordy language shit
One of my favorite Java features, actually. No, seriously. When I read Java code - even a few lines of sample code exercising a library written by someone else 4 years ago halfway around the world - I know what its doing. I may not understand the library calls, but I have no doubt whatsoever about the language.
This isn't a feature thats useful for small projects. Its wonderful when dealing with software written over 5-10 years by a variety of people who may or may not still work with you.
10. framework shit
Again, useless on small projects, pretty durn good on larger ones where you're working on software that can handle hundreds or thousands of parallel, complicated requests all performing complex business tasks. And no, I haven't found a Java web framework that I really like yet, but I could say that about all the frameworks I've tried, regardless of the language.
Modern Java's not bad when its used to solve problems its good at solving. The same is true for many languages - I'd never write a Windows GUI in Java, for example, nor would I reach for C# to do my next clustered platform. You can do a good job in both ... but its a lot harder than it needs to be.
obJargonRef: Big [Blue] Room
Yeah... its a pity that you can't add Solitaire and AIM to global policies. Then everyone would have been happy. Maybe in 2012 they'll figure out that technology.
Your approach requires that people think. People are mostly incapable of even the simplest degree of thought when it comes to such things. I don't know why - they just can't do it.
And those people would be able to figure out SELinux permissions, where 9/10 sysadmins give up at some point?
Or in this particular case, maybe they want to do that so that they can send you music over wireless when available, at higher fidelity with lower battery drain?