No thanks. As a software developer who has to deal with coders, they're literally more trouble than they're worth. To get good code out of them I have to nail things down so explicitly and in such detail that I could've written the code myself in the time it took to write the instructions for them. I nearly have to write the code anyway just to figure out all the stuff I need to give them instructions on. And if I don't give them instructions in that much detail, their lack of analytical ability means they churn out code that doesn't quite do what it's supposed to or does things in ways that conflict with what the rest of the system needs. I either have to spend time re-writing their code, or I have to spend 10x as much time down the road working around the brokenness in their code when I'm trying to do maintenance and enhancement. The kind of code a pure coder would be good for writing, is the kind of code I go find a library for.
Don't teach the kids how to code. Teach them how to program. That means teaching them to think about the problem, determine requirements, clarify requirements (I'm working on one now where it's taking literally days to tease out of the person exactly what they actually want, it's repetitions of my restating what he said and him going "That sounds right, except for..." and then outlining a new thing the software has to do that he hadn't mentioned before), evaluate approaches and settle on a basic design and outline for the software, and finally document the requirements and design. And then once the code's written it has to be tested and debugged, which is another skill set entirely. Plus, while coding you have to think about what tools are available in the language, what libraries are out there, and how they integrate with your code. Often that affects the design of the software, and you need to understand that and learn how to think ahead during the design stage so your design works with the tools you'll need to use while coding.
Actual coding is the smallest part of the job. Critical thinking, analytical skills, general problem-solving, research, all that is far more important to the job than merely knowing how to crank out code.
Ask any writer. They'll tell you that the actual physical act of typing out a book is the easy part, it's just time-consuming. The hard parts are all the research and working out the actual story before you sit down to start typing.
There's always jamming. Drones can't fly without a signal from their controller, and controllers can't fly the drones without a return signal from the drone. Frequency-hopping makes jamming harder, but one thing works against it: distance. The jammers on a competing fighter are a lot closer than the drone's base, and since signal strength varies as the square of distance the jammers can put more power on target easier than the base can. To give you an example you can try, think about how loudly you'd need to talk to drown out someone yelling from half a mile away.
And then there's situational awareness. Think for a minute about the relatively small screens drone pilots have to watch the camera feeds on, and the relatively low resolution of the video. They show only a very small cone in the direction the camera's facing. That's fine for a ground-attack drone, but a fighter pilot has to be watching virtually an entire sphere. It'll be very easy for a stealthy opposing fighter to sneak up on a drone from a direction the drone's pilot isn't watching. And even if the pilot does see the incoming enemy, he may not identify that speck of static in the image as an enemy fighter. To top it off, once an enemy launches a missile the drone pilot's going to have a very hard time scanning and locating the missile track to start evading. The camera doesn't pan fast enough, doesn't show a wide enough area and doesn't have a high enough resolution to nail down the missile in the few seconds the pilot has to start evading.
Before we start deploying drone fighters, they need to go through Red Flag first. Take them out to the range and put them in a real dogfight against real pilots who aren't required to abide by artificial restrictions on what they can do (beyond "don't bend the bird"). When they can hold their own there, then they're ready for the battlefield.
That's no longer my problem. It's now an operating expense for me instead of a massive up front capital expense.
Exactly. Now, answer me this: you've decided that you can't afford that large up-front capital expense and having that capacity sitting around unused to deal with the occasional large spike in demand. So why is your cloud provider not following exactly the same business logic that you find sound? Why are they not trying to avoid exactly the same large capital expenditure that you're trying to avoid? ISPs, cel phone carriers, airlines, they all oversubscribe for good business reasons. So why do those reasons not apply to your cloud provider the same as they apply everywhere else?
I've lost count of how many times I've heard someone go "But this is different!". The number of times it really has been different? I can count those on my fingers, using only one hand, and still not run out of fingers.
And you think the cloud works differently? It's just that someone else is buying all that hardware to have sitting around idle until you need it. You hope. But, being a business, I'll bet one of their policies is to not buy more hardware than their projected needs, to avoid having any more sitting around idle than they absolutely have to to cover their own short-term needs. Anything else increases their costs without providing any revenue, so as a business they're going to avoid it just like you are.
What makes it work is that they have so many customers that when one needs more capacity they can take a bit away from everybody else and each customer's share will be so small they won't notice. With a large number of customers, hopefully not too many will need a lot more capacity at the same time. What could possibly go wrong?
My problem with those SLAs is that they're for a credit for a fraction of the cost of the service for that month. Which is fine if your business doesn't depend on the service and you suffer no disruption when the service is down. But if you're hosting a Web site on the service, or using it for anything business-critical? The cost of the service is going to be the smallest part of the cost to you of the disruption (that's why you went with the service after all, because it was so much cheaper than doing it in-house). The SLA doesn't cover you for lost sales, lost business, lost customers, the cost of employees sitting around idle because the systems they need to do their jobs aren't working...
For me, I don't care whether the site honors that header or not. If they're going to abuse tracking, they're not likely to suddenly come over all ethical and change their servers to not track. What the DNT header does is give a standard, recognized signal present in every single browser request that I do not consent to tracking. It's like the fence with the locked gates and "Private Property - No Trespassing" signs around a property: it's not going to keep trespassers out, but it's a clear and more importantly legally-recognized demarcation. If they jump over the fence onto my land and get in trouble because of being there, the court's going to look at the fact the land was clearly posted and tell them "Sorry, we don't accept your claim that you didn't know it was private property.". With the DNT header, no Web site can claim they didn't know I didn't consent to tracking. They can't claim implicit consent, because there's explicit non-consent in the very request they serviced. And this is why the advertisers are making such a play to get the DNT header dismissed and abandoned. Up to now they've taken the position of "You must consent as a condition of access, you accessed so we can assume your consent.". As long as there's no standard way of saying "I do not consent.", they can get away with that. But with a standard DNT header they can't argue that it's infeasible to check every possible way of not consenting. There's just one, and it's not ambiguous. The counter-argument of "If they don't want to allow access to those who don't consent, why did they not simply return an HTTP error when they saw the DNT header?" becomes rather more convincing.
The secret the advertisers don't want to state up front is that they don't want to require consent to tracking. They just want to track everybody whether they consent or not. Anything that provides a clear, unambiguous message to them about consent or lack thereof is a threat to that position, because it makes it harder for them to argue a basis for their assuming consent.
And a message to every Web-site and ad-network operator out there: if you're serious, stop whining and configure your servers to return 403 Forbidden to every request with the DNT header set. It's not that hard.
A likely explanation is that the user's running an older update of RHEL 6 (it's currently on update 3) that RH isn't providing updates for anymore. I could make a case for ceasing to support older updates, because they aren't getting security patches anymore and users really should be applying the regular updates from RH which, if they were, would've transitioned their systems to update 3 long before this (it came out in June 2012).
The only problem is rainbow tables. Storage is getting to the point where it's becoming feasible to store all possible hashes and the strings that generate them. For 64-byte hashes and 64-character maximum string length, 4 1TB hard drives will let you store roughly 32 billion hashes. Binary search takes worst-case 29 comparisons on that. So, for under a grand I can build a NAS box that'll let me take 32 billion possible passwords, pre-compute the hashes of them and turn cracking any password into an exercise in disk seeks. If it's in my list, I can crack it in at most the time it takes to do 29 seeks of the disk heads.
More expensive hashes only help you there if you make them so expensive it becomes burdensome for the sites to use them too, because that's the only way to make it infeasible to pre-compute the hashes.
winapp.ini is the internal file CCleaner uses to store it's cleaning rules. It follows the basic standard Windows INI file syntax. The entries in each section are specific to CCleaner, but appear to be fairly obvious just looking at the file without any further documentation.
winapp2.ini is an external file read by CCleaner to import additional (non-Piriform) cleaning rules. It's intended use is to let people other than Piriform add rules to CCleaner. The full documentation on it's syntax is available (without needing to agree to any terms) at http://forum.piriform.com/index.php?showtopic=32310. This file uses the exact same syntax as winapp.ini.
So from what I can tell from this, the contents of winapp2.ini are by definition not the property of Piriform and Piriform wouldn't have any legal right to dictate who can use them. That right would rest with the authors of the entries. Piriform's contention here is that mere use of the syntax is a violation of terms, and as I noted I can get the documentation without needing to agree to any terms. So while I'd be consulting a lawyer, my first reaction would be to respond "Please identify the date on which you believe I agreed to your terms of service, and the documentation you believe supports this contention." as that's probably the first question my lawyer's going to want answered anyway. Frankly to me the demand smacks of "Your product's taking business away from CCleaner, and we don't like it and want you to stop it.". Which is fine, but falls short of the legal basis needed to force someone else to shut down their business.
The biggest problem isn't that the applications don't disclose what they're accessing. There's also the problem that they don't disclose in detail. "May access the network", yeah, but for what? Knowing that it needs network access doesn't do me any good if I don't know what it needs it for or what it intends to do with it. Ditto "may access the SD card". Is it going to access it to store it's own data, or is it going to access it to scan other data?
And finally, even if all that's resolved, disclosure does no good when applications give you a take-it-or-leave-it approach: either give them 100% of everything they want or don't install them, even when a lot of what they want isn't required for them to run. The free version of a to-do list, for instance, would need network access to receive and display ads, but why would the paid-for ad-free version need it? Only to sync to a service like Google or Apple, and then only when the user chose to sync to a service. An IM program needs network access to run, without that it's kind of pointless. But access to my contacts? That may make it convenient, but my IM program does not need to see my phone's contact list to do it's job. At most it needs access to it's own contact list, which it would be getting from the IM servers when it logs on (otherwise things wouldn't stay in sync between clients). But still you're faced with either giving the IM program unrestricted access to something it doesn't need or not being able to use it at all. What's needed is disclosure of exactly why the program needs access and of why, if that access is required to install/run, the program cannot function without that access. Note that for that IM program, "It can't function without access to the contact list because I'm too lazy to write the code to maintain an app-specific contacts list." would be a perfectly acceptable disclosure. The reason doesn't have to be good, merely honest. Penalties for failure to follow the requirements? Well, you're making a fraudulent statement about your product. We already have penalties on the books for that.
I don't want a refrigerator that orders food when I'm running low. The definitions of how low is too low and what food I want to order are just too fuzzy and variable.
But, I'd want the refrigerator to be able to tell me what the temperature in the compartments is, whether the door's open or closed, that sort of thing. And maybe send an alert to my phone or via e-mail or to a system tray app if the door stays open too long (somebody forgot to close it right) or the temperature goes above what I've set it for and stays there (something's wrong and the food's thawing). And of course the basic warning app that alerts me if it isn't getting reports from the refrigerator (as in a power outage) and I need to see whether it's just the network out or something more major I have to do something about. Ditto for the oven: fancy automatic cooking is a big no, but being able to see what burners/ovens are on/off, what the oven temperature is, how long it's been on, and control those things remotely, that might be nice. Or the dishwasher: when was it started, has it finished running, is it's door closed.
Of course the big problem is security. I may want to see and control my appliances, but I don't want anybody outside the household (and maybe not even everybody inside the household) doing the same. To me this stuff falls into the SCADA category, things that while they may be networked they should not be on a public network. Wireless for instance would be right out. And wouldn't be needed anyway. Appliances need wiring right from the start, for power and gas and water. So include Ethernet wiring with the runs and bring it all to a central switch where it can be connected to the home network. If I were doing it I'd actually place it on a third network interface in the router, one dedicated only to home automation that could be accessed by the other local networks but was blocked from the WAN interface.
I suspect I should worry that my standard requirement for a router is 4 network interfaces.
But am I getting more success? I put a lot of time and effort and money into creating the product and setting up the business. And just when I'm beginning to see a return on that investment, that's when I'm most likely to get cut off. So I'm now out all that investment, and while I may have recouped some of it I'm probably looking at a dead loss of at least 50% of my investment. I would've been better off taking the money and putting it in a 12-month CD.
If the devil owns the dance hall and I know he's going to throw me out in the cold the moment I get a girl to dance with me, why should I even bother? I'll end up out in the cold either way, and the time I don't waste dealing with the devil I can spend talking to the girls who're tired of dealing with the lounge-lizard dance-hall owner who won't let 'em so much as look at anyone else without him cutting in.
Why would you ever design a product that's completely and utterly dependent on a service provided by someone else, especially someone else who you view as a competitor or who may down the road view you as a competitor, without an iron-clad, air-tight contract guaranteeing exactly what services they'll provide you and providing scorched-earth-level penalties for their failure to provide service according to the agreed-upon terms? Anything less is pretty much a guarantee that they'll pull the rug out from under you as soon as they think it'll be to their advantage. I'm not a business type or some super startup guru, just a lowly techie, but even I can figure that one out. Gleh, what do they teach in school these days? That the Universe is all rainbows and unicorns and that everybody plays nice all the time?
I believe it's site-by-site, when you first get the warning you can select to always allow or always deny for this site or allow it for this visit only. What I'd like is to have that domain-by-domain, so I can allow Flash from the site but deny it for random ad networks that place ads on the site.
What'll happen is the studios will continue to sue and subpoena the information for the machines that they see connecting to the torrent. They'll argue that it's the owners of those machines responsible for any use of their machines by others. They'll continue to use these tactics as long as the courts make it cheap for them to file and lose. That won't end until the courts start ruling that the studios know they don't have grounds for these suits and start dismissing them with prejudice and sanctioning the plaintiffs without a defendant having to do anything. Maybe the courts starting to refuse to let the plaintiffs withdraw their claims after a defendant's responded, forcing the plaintiffs to face an adverse judgement and sanctions, might stop them too, but my money's on the studios in that case betting that too few defendants will have the resources to gamble on winning that show-down.
Yes, and that's why #1 exists: to insure that an employer can't fire an H1-B hire the moment they realize the guy's gotten a better offer. Under current rules they can do that and force the H1-B out of the country before he can accept and get the paperwork processed. The grace period makes that kind of shenanigans on the part of the current employer impossible.
Processes would be irrelevant, since each one has it's own address space (the exploit works on the process level, not down on physical memory). And with NOP slides and other tricks, you don't need to pin down the location to the byte. Allocate one large block that'll be forced into the end of memory (start too large and work down until it succeeds, it'll have been allocated at the end of the heap because that's the only place that has a single contiguous block big enough open), allocate smaller blocks until the allocation fails (you've now filled up the heap), then resize your big block down enough to open up a hole for the DLL (it'll be loaded immediately after your big block since that's where the hole was opened up). The only real trick is chopping up the low portion of the heap and leaving enough small blocks there that most normal allocation will be happening below your big block while the only hole big enough for the DLL is above the big block, and it's not like that's all that challenging a programming problem.
And the amusing thing is that the x86 architecture allows you to make this sort of exploit physically impossible (at least without cracking ring 0 first). Separate code, heap and stack and place the heap and stack in non-executable segments, and any attempt to try this kind of thing just results in the kernel getting a memory access exception and terminating the offending process.
And this exploit wasn't obvious from the start? When the heap and dynamically-loaded code share the same address space, this vulnerability always exists. We knew this 30 years ago. It took someone this long to apply it?
How about we agree to that cap increase, but only if H1-B visas have two conditions attached:
1. The visa is only valid as long as the applicant is employed. If he's unemployed for more than 30 days, the visa is no longer valid.
2. The visa is granted to the employee, not the company, and goes with the employee if he accepts another job.
Companies want to bring in foreign applicants because they can get them cheaper than hiring locally (otherwise, why go through the hassle?). Change the economic rules so they can't low-ball salaries without risking other companies poaching their employees with better offers and I'll bet H1-Bs become a lot less popular.
Except that that would be offset by the Texas employer offering a much lower salary than I'd get in California. So my money wouldn't go further, because I'd be taking a 25% pay cut making the move just because salaries in Texas are lower. And that's just not enough to make up for having to deal with eg. Rick Perry.
That's fine, if you're a salesman. I'm a tech guy. I don't want to spend half my working time chasing down new leads and selling my services to others. That's on top of the fact that I'd need to double my income just to stay even getting my own benefits (assuming I even can get something equivalent to what I have now). And if I moved to somewhere other than California, I'd have to deal with dealing with the kind of business owner who wants me to not have any kind of recourse against him. What, you thought he'd treat contractors differently than employees? Hah. Hah. It is to laugh.
As an employee, why would I want to work in states like Texas or Arizona that provide much less in the way of protections for workers? One of the reasons I like working in California is the laws that give me some leverage when dealing with employers, and protections and safety nets when said employer folds due to dumb decisions by management.
And as an employer, why would I want to set up business in a state where my pool of workers is limited to the kind who all they have to offer is their willingness to accept that lack of protection? One of the reasons tech companies locate in California is that that's where the people they need/want to hire are. If I set up business in Texas or Arizona, I do so knowing that the best employees, the ones I'd most want to have, aren't going to be willing to relocate there. I can't see that being a winning strategy long-term.
Slashdot Mirror
No thanks. As a software developer who has to deal with coders, they're literally more trouble than they're worth. To get good code out of them I have to nail things down so explicitly and in such detail that I could've written the code myself in the time it took to write the instructions for them. I nearly have to write the code anyway just to figure out all the stuff I need to give them instructions on. And if I don't give them instructions in that much detail, their lack of analytical ability means they churn out code that doesn't quite do what it's supposed to or does things in ways that conflict with what the rest of the system needs. I either have to spend time re-writing their code, or I have to spend 10x as much time down the road working around the brokenness in their code when I'm trying to do maintenance and enhancement. The kind of code a pure coder would be good for writing, is the kind of code I go find a library for.
Don't teach the kids how to code. Teach them how to program. That means teaching them to think about the problem, determine requirements, clarify requirements (I'm working on one now where it's taking literally days to tease out of the person exactly what they actually want, it's repetitions of my restating what he said and him going "That sounds right, except for..." and then outlining a new thing the software has to do that he hadn't mentioned before), evaluate approaches and settle on a basic design and outline for the software, and finally document the requirements and design. And then once the code's written it has to be tested and debugged, which is another skill set entirely. Plus, while coding you have to think about what tools are available in the language, what libraries are out there, and how they integrate with your code. Often that affects the design of the software, and you need to understand that and learn how to think ahead during the design stage so your design works with the tools you'll need to use while coding.
Actual coding is the smallest part of the job. Critical thinking, analytical skills, general problem-solving, research, all that is far more important to the job than merely knowing how to crank out code.
Ask any writer. They'll tell you that the actual physical act of typing out a book is the easy part, it's just time-consuming. The hard parts are all the research and working out the actual story before you sit down to start typing.
There's always jamming. Drones can't fly without a signal from their controller, and controllers can't fly the drones without a return signal from the drone. Frequency-hopping makes jamming harder, but one thing works against it: distance. The jammers on a competing fighter are a lot closer than the drone's base, and since signal strength varies as the square of distance the jammers can put more power on target easier than the base can. To give you an example you can try, think about how loudly you'd need to talk to drown out someone yelling from half a mile away.
And then there's situational awareness. Think for a minute about the relatively small screens drone pilots have to watch the camera feeds on, and the relatively low resolution of the video. They show only a very small cone in the direction the camera's facing. That's fine for a ground-attack drone, but a fighter pilot has to be watching virtually an entire sphere. It'll be very easy for a stealthy opposing fighter to sneak up on a drone from a direction the drone's pilot isn't watching. And even if the pilot does see the incoming enemy, he may not identify that speck of static in the image as an enemy fighter. To top it off, once an enemy launches a missile the drone pilot's going to have a very hard time scanning and locating the missile track to start evading. The camera doesn't pan fast enough, doesn't show a wide enough area and doesn't have a high enough resolution to nail down the missile in the few seconds the pilot has to start evading.
Before we start deploying drone fighters, they need to go through Red Flag first. Take them out to the range and put them in a real dogfight against real pilots who aren't required to abide by artificial restrictions on what they can do (beyond "don't bend the bird"). When they can hold their own there, then they're ready for the battlefield.
Exactly. Now, answer me this: you've decided that you can't afford that large up-front capital expense and having that capacity sitting around unused to deal with the occasional large spike in demand. So why is your cloud provider not following exactly the same business logic that you find sound? Why are they not trying to avoid exactly the same large capital expenditure that you're trying to avoid? ISPs, cel phone carriers, airlines, they all oversubscribe for good business reasons. So why do those reasons not apply to your cloud provider the same as they apply everywhere else?
I've lost count of how many times I've heard someone go "But this is different!". The number of times it really has been different? I can count those on my fingers, using only one hand, and still not run out of fingers.
And you think the cloud works differently? It's just that someone else is buying all that hardware to have sitting around idle until you need it. You hope. But, being a business, I'll bet one of their policies is to not buy more hardware than their projected needs, to avoid having any more sitting around idle than they absolutely have to to cover their own short-term needs. Anything else increases their costs without providing any revenue, so as a business they're going to avoid it just like you are.
What makes it work is that they have so many customers that when one needs more capacity they can take a bit away from everybody else and each customer's share will be so small they won't notice. With a large number of customers, hopefully not too many will need a lot more capacity at the same time. What could possibly go wrong?
My problem with those SLAs is that they're for a credit for a fraction of the cost of the service for that month. Which is fine if your business doesn't depend on the service and you suffer no disruption when the service is down. But if you're hosting a Web site on the service, or using it for anything business-critical? The cost of the service is going to be the smallest part of the cost to you of the disruption (that's why you went with the service after all, because it was so much cheaper than doing it in-house). The SLA doesn't cover you for lost sales, lost business, lost customers, the cost of employees sitting around idle because the systems they need to do their jobs aren't working...
For me, I don't care whether the site honors that header or not. If they're going to abuse tracking, they're not likely to suddenly come over all ethical and change their servers to not track. What the DNT header does is give a standard, recognized signal present in every single browser request that I do not consent to tracking. It's like the fence with the locked gates and "Private Property - No Trespassing" signs around a property: it's not going to keep trespassers out, but it's a clear and more importantly legally-recognized demarcation. If they jump over the fence onto my land and get in trouble because of being there, the court's going to look at the fact the land was clearly posted and tell them "Sorry, we don't accept your claim that you didn't know it was private property.". With the DNT header, no Web site can claim they didn't know I didn't consent to tracking. They can't claim implicit consent, because there's explicit non-consent in the very request they serviced. And this is why the advertisers are making such a play to get the DNT header dismissed and abandoned. Up to now they've taken the position of "You must consent as a condition of access, you accessed so we can assume your consent.". As long as there's no standard way of saying "I do not consent.", they can get away with that. But with a standard DNT header they can't argue that it's infeasible to check every possible way of not consenting. There's just one, and it's not ambiguous. The counter-argument of "If they don't want to allow access to those who don't consent, why did they not simply return an HTTP error when they saw the DNT header?" becomes rather more convincing.
The secret the advertisers don't want to state up front is that they don't want to require consent to tracking. They just want to track everybody whether they consent or not. Anything that provides a clear, unambiguous message to them about consent or lack thereof is a threat to that position, because it makes it harder for them to argue a basis for their assuming consent.
And a message to every Web-site and ad-network operator out there: if you're serious, stop whining and configure your servers to return 403 Forbidden to every request with the DNT header set. It's not that hard.
A likely explanation is that the user's running an older update of RHEL 6 (it's currently on update 3) that RH isn't providing updates for anymore. I could make a case for ceasing to support older updates, because they aren't getting security patches anymore and users really should be applying the regular updates from RH which, if they were, would've transitioned their systems to update 3 long before this (it came out in June 2012).
Oh, kind of like the ShockWatch labels we used all the time on shipments then?
The only problem is rainbow tables. Storage is getting to the point where it's becoming feasible to store all possible hashes and the strings that generate them. For 64-byte hashes and 64-character maximum string length, 4 1TB hard drives will let you store roughly 32 billion hashes. Binary search takes worst-case 29 comparisons on that. So, for under a grand I can build a NAS box that'll let me take 32 billion possible passwords, pre-compute the hashes of them and turn cracking any password into an exercise in disk seeks. If it's in my list, I can crack it in at most the time it takes to do 29 seeks of the disk heads.
More expensive hashes only help you there if you make them so expensive it becomes burdensome for the sites to use them too, because that's the only way to make it infeasible to pre-compute the hashes.
winapp.ini is the internal file CCleaner uses to store it's cleaning rules. It follows the basic standard Windows INI file syntax. The entries in each section are specific to CCleaner, but appear to be fairly obvious just looking at the file without any further documentation.
winapp2.ini is an external file read by CCleaner to import additional (non-Piriform) cleaning rules. It's intended use is to let people other than Piriform add rules to CCleaner. The full documentation on it's syntax is available (without needing to agree to any terms) at http://forum.piriform.com/index.php?showtopic=32310. This file uses the exact same syntax as winapp.ini.
So from what I can tell from this, the contents of winapp2.ini are by definition not the property of Piriform and Piriform wouldn't have any legal right to dictate who can use them. That right would rest with the authors of the entries. Piriform's contention here is that mere use of the syntax is a violation of terms, and as I noted I can get the documentation without needing to agree to any terms. So while I'd be consulting a lawyer, my first reaction would be to respond "Please identify the date on which you believe I agreed to your terms of service, and the documentation you believe supports this contention." as that's probably the first question my lawyer's going to want answered anyway. Frankly to me the demand smacks of "Your product's taking business away from CCleaner, and we don't like it and want you to stop it.". Which is fine, but falls short of the legal basis needed to force someone else to shut down their business.
The biggest problem isn't that the applications don't disclose what they're accessing. There's also the problem that they don't disclose in detail. "May access the network", yeah, but for what? Knowing that it needs network access doesn't do me any good if I don't know what it needs it for or what it intends to do with it. Ditto "may access the SD card". Is it going to access it to store it's own data, or is it going to access it to scan other data?
And finally, even if all that's resolved, disclosure does no good when applications give you a take-it-or-leave-it approach: either give them 100% of everything they want or don't install them, even when a lot of what they want isn't required for them to run. The free version of a to-do list, for instance, would need network access to receive and display ads, but why would the paid-for ad-free version need it? Only to sync to a service like Google or Apple, and then only when the user chose to sync to a service. An IM program needs network access to run, without that it's kind of pointless. But access to my contacts? That may make it convenient, but my IM program does not need to see my phone's contact list to do it's job. At most it needs access to it's own contact list, which it would be getting from the IM servers when it logs on (otherwise things wouldn't stay in sync between clients). But still you're faced with either giving the IM program unrestricted access to something it doesn't need or not being able to use it at all. What's needed is disclosure of exactly why the program needs access and of why, if that access is required to install/run, the program cannot function without that access. Note that for that IM program, "It can't function without access to the contact list because I'm too lazy to write the code to maintain an app-specific contacts list." would be a perfectly acceptable disclosure. The reason doesn't have to be good, merely honest. Penalties for failure to follow the requirements? Well, you're making a fraudulent statement about your product. We already have penalties on the books for that.
I don't want a refrigerator that orders food when I'm running low. The definitions of how low is too low and what food I want to order are just too fuzzy and variable.
But, I'd want the refrigerator to be able to tell me what the temperature in the compartments is, whether the door's open or closed, that sort of thing. And maybe send an alert to my phone or via e-mail or to a system tray app if the door stays open too long (somebody forgot to close it right) or the temperature goes above what I've set it for and stays there (something's wrong and the food's thawing). And of course the basic warning app that alerts me if it isn't getting reports from the refrigerator (as in a power outage) and I need to see whether it's just the network out or something more major I have to do something about. Ditto for the oven: fancy automatic cooking is a big no, but being able to see what burners/ovens are on/off, what the oven temperature is, how long it's been on, and control those things remotely, that might be nice. Or the dishwasher: when was it started, has it finished running, is it's door closed.
Of course the big problem is security. I may want to see and control my appliances, but I don't want anybody outside the household (and maybe not even everybody inside the household) doing the same. To me this stuff falls into the SCADA category, things that while they may be networked they should not be on a public network. Wireless for instance would be right out. And wouldn't be needed anyway. Appliances need wiring right from the start, for power and gas and water. So include Ethernet wiring with the runs and bring it all to a central switch where it can be connected to the home network. If I were doing it I'd actually place it on a third network interface in the router, one dedicated only to home automation that could be accessed by the other local networks but was blocked from the WAN interface.
I suspect I should worry that my standard requirement for a router is 4 network interfaces.
But am I getting more success? I put a lot of time and effort and money into creating the product and setting up the business. And just when I'm beginning to see a return on that investment, that's when I'm most likely to get cut off. So I'm now out all that investment, and while I may have recouped some of it I'm probably looking at a dead loss of at least 50% of my investment. I would've been better off taking the money and putting it in a 12-month CD.
If the devil owns the dance hall and I know he's going to throw me out in the cold the moment I get a girl to dance with me, why should I even bother? I'll end up out in the cold either way, and the time I don't waste dealing with the devil I can spend talking to the girls who're tired of dealing with the lounge-lizard dance-hall owner who won't let 'em so much as look at anyone else without him cutting in.
Because they want an R&D division to come up with profitable new ideas for them?
Why would you ever design a product that's completely and utterly dependent on a service provided by someone else, especially someone else who you view as a competitor or who may down the road view you as a competitor, without an iron-clad, air-tight contract guaranteeing exactly what services they'll provide you and providing scorched-earth-level penalties for their failure to provide service according to the agreed-upon terms? Anything less is pretty much a guarantee that they'll pull the rug out from under you as soon as they think it'll be to their advantage. I'm not a business type or some super startup guru, just a lowly techie, but even I can figure that one out. Gleh, what do they teach in school these days? That the Universe is all rainbows and unicorns and that everybody plays nice all the time?
I believe it's site-by-site, when you first get the warning you can select to always allow or always deny for this site or allow it for this visit only. What I'd like is to have that domain-by-domain, so I can allow Flash from the site but deny it for random ad networks that place ads on the site.
What'll happen is the studios will continue to sue and subpoena the information for the machines that they see connecting to the torrent. They'll argue that it's the owners of those machines responsible for any use of their machines by others. They'll continue to use these tactics as long as the courts make it cheap for them to file and lose. That won't end until the courts start ruling that the studios know they don't have grounds for these suits and start dismissing them with prejudice and sanctioning the plaintiffs without a defendant having to do anything. Maybe the courts starting to refuse to let the plaintiffs withdraw their claims after a defendant's responded, forcing the plaintiffs to face an adverse judgement and sanctions, might stop them too, but my money's on the studios in that case betting that too few defendants will have the resources to gamble on winning that show-down.
Yes, and that's why #1 exists: to insure that an employer can't fire an H1-B hire the moment they realize the guy's gotten a better offer. Under current rules they can do that and force the H1-B out of the country before he can accept and get the paperwork processed. The grace period makes that kind of shenanigans on the part of the current employer impossible.
Processes would be irrelevant, since each one has it's own address space (the exploit works on the process level, not down on physical memory). And with NOP slides and other tricks, you don't need to pin down the location to the byte. Allocate one large block that'll be forced into the end of memory (start too large and work down until it succeeds, it'll have been allocated at the end of the heap because that's the only place that has a single contiguous block big enough open), allocate smaller blocks until the allocation fails (you've now filled up the heap), then resize your big block down enough to open up a hole for the DLL (it'll be loaded immediately after your big block since that's where the hole was opened up). The only real trick is chopping up the low portion of the heap and leaving enough small blocks there that most normal allocation will be happening below your big block while the only hole big enough for the DLL is above the big block, and it's not like that's all that challenging a programming problem.
And the amusing thing is that the x86 architecture allows you to make this sort of exploit physically impossible (at least without cracking ring 0 first). Separate code, heap and stack and place the heap and stack in non-executable segments, and any attempt to try this kind of thing just results in the kernel getting a memory access exception and terminating the offending process.
And this exploit wasn't obvious from the start? When the heap and dynamically-loaded code share the same address space, this vulnerability always exists. We knew this 30 years ago. It took someone this long to apply it?
How about we agree to that cap increase, but only if H1-B visas have two conditions attached:
1. The visa is only valid as long as the applicant is employed. If he's unemployed for more than 30 days, the visa is no longer valid.
2. The visa is granted to the employee, not the company, and goes with the employee if he accepts another job.
Companies want to bring in foreign applicants because they can get them cheaper than hiring locally (otherwise, why go through the hassle?). Change the economic rules so they can't low-ball salaries without risking other companies poaching their employees with better offers and I'll bet H1-Bs become a lot less popular.
Except that that would be offset by the Texas employer offering a much lower salary than I'd get in California. So my money wouldn't go further, because I'd be taking a 25% pay cut making the move just because salaries in Texas are lower. And that's just not enough to make up for having to deal with eg. Rick Perry.
That's fine, if you're a salesman. I'm a tech guy. I don't want to spend half my working time chasing down new leads and selling my services to others. That's on top of the fact that I'd need to double my income just to stay even getting my own benefits (assuming I even can get something equivalent to what I have now). And if I moved to somewhere other than California, I'd have to deal with dealing with the kind of business owner who wants me to not have any kind of recourse against him. What, you thought he'd treat contractors differently than employees? Hah. Hah. It is to laugh.
As an employee, why would I want to work in states like Texas or Arizona that provide much less in the way of protections for workers? One of the reasons I like working in California is the laws that give me some leverage when dealing with employers, and protections and safety nets when said employer folds due to dumb decisions by management.
And as an employer, why would I want to set up business in a state where my pool of workers is limited to the kind who all they have to offer is their willingness to accept that lack of protection? One of the reasons tech companies locate in California is that that's where the people they need/want to hire are. If I set up business in Texas or Arizona, I do so knowing that the best employees, the ones I'd most want to have, aren't going to be willing to relocate there. I can't see that being a winning strategy long-term.