The distinction between a buggy application, and a malicious application that "asks really nicely" to run as system, is moot. The malicious programmer will purposefully use buggy methods to get the jvm to run at system, exactly because he can then drop shit anywhere he wants. Qed.
I want the jvm to have a restriction that says it can NEVER be invoked above a limited super user I define.
As for the silent invokation, I again refer you to buggy browsers. IE is especially nasty this way. (I don't use it btw.) A process hijack in the browser to call the jre to run the.jar, would be halted, if the jre obeyed a little checkbox that says "always prompt". That's all I want there. An optional checkbox.
As for the visualvm listed above, does that come stock? I doubt it does...
Probably-- I find the environment that java applications run under to be opaque, and impossible to monitor or sanely control.
Granted, the last time I allowed myself to install the JRE was many many years ago. The application wasn't terribly important, but was necessary for what I needed, becaue there weren't any alternatives, and had the ability to open and save files. I noted that it could open and save files in places that my user did not have authority to do. When I checked the task manager, the jvm was running at a higher authority level than my user. This might have been because it needed to be installed as an actual admin, and the system automatically gave it admin privs. Regardless, that sunk it.
The fact that I can't get a list of what is running insde in a painless fashion, and can't give a global restriction on what the jre and jvm can touch, means I won't ever install it again.
The day that Oracle comes out and says "we obey local security, and have global options you can enforce, along with a way to see what the VM is running, as well as an option to forbid silent invokations" is the day I will consider installing it again.
I distrust the jvm, because it is very difficult to lock it down.
Desktop app developers want access to the local FS. This is because they want to do something useful, like being an office suite. You can't save files, if you don't have FS access, of course!
I can't selectively authorize the JVM to have access to specific areas with real authority. Certainly not on a windows system, where the JVM runs with system level authority. (Basically at root!) Even without the browser plugin, a driveby download script that exploits another hole in the browser can drop an applet.jar, and call the JVM to run it. The applet can then generate the rest of the malicious package, and because I can't restrict its access sanely, it can put its payload anywhere it damned well wants. Because it can spawn silently, I never see this happen.
This is especially problematical when the.jar is signed by a compromised CA.
I expect it to obey restrictions I put it under, and to not run constantly behind my back. Just like it isn't a good idea to leave unmonitored servlets open on standard ports, I don't feel it is trustworthy to leave a VM running all the time, and would expect that people who claim to be professional programmers would comprehend that, and let me put restrictions on when and how the VM runs.
But no. Java wants to put hentai tentacles in, and I don't like that. That's for starters.
Also, despite the may claims to the contrary, I have actually seen java applications access areas they aren't supposed to have access to. That alone makes me nervous about what is running inside the VM.
That the VM doesn't provide me with good tools to see what really is running inside it, and kill naghty processes, is the third strike.
If I can be reasonably sure that nothing naughty is running in there, such as on an isolated intranet, I am fine leaving it running.
With the exception of a dvr, most of those devices are low RAM, and lack a persistent writable data store, meaning a simple power off would unzombify them.
Last I checked, the desktop JVM will grant a writable datastore to appliations that request it, and even hold it persistently.
Perhaps if there were better tools to see what is running inside the jvm, and being able to terminate processes, as well as being better able to restrict what priviledges and access methods the JVM can attempt. I don't like running a magic box that welds the lid on by default.
Not being able to do those things, or worse, having the VM ignore settings you do set because the application asked realy nicely, is not going to make me trust the VM. Java integrates itself pretty deeply on the host environment to do the things it does, and it isn't a trivial matter to ensure its safeness.
Agreed! Client side execution is the problem! But, where would you expect it to run otherwise? On the server? Congrats, you just pointed a bullseye on big iron! One that can potentially run general purpose programs, and not just a simple script parser!
The problem with java, is that it is standardized, and everywhere. This makes it desirable to target. It needs alternatives, and lots of them, with heavy market penetration.
My issue is with the demand for it t be ubiquitous, everywhere, on everything, and easily tapped.
Keep it in a box. Please. Don't make me have to install it just because you didn't feel like learing any other architectures, when in reality, there are only 4 major ones in existence right now. (*nix, *bsd, Windows, and javaVM)
I don't want it to be easy for you to run things on my computer. That's the whole fucking point.
That is actually precisely the point. Write once, execute anywhere being demanded for its ease of deployment is what produces the unified attack surface that malware writers find desirable.
The malware writer wants to get the most bang for his time spent developing too.
By refusing to accept less than the easy button, the same easy button you make use of, they make use of, and make use of VERY VERY heavily.
I would rather not use your software, if you demand the easy button. I would prefer a broken port that does not present a unified attack surface, than install a bullseye on my desktop, that says "put payload here! Garanteed to run!"
Just like in nature, a monoculture breeds weakness, by presenting a unified mechanism for disease, without an alternative defense. Yes, it's much easier to develop for a standardized VM, with a standardized behavior, and a standardized library. The malware writers clearly think so too.
Putting up with multiplatform support foibles is a small price to pay, for forcing malware writers to do the same.
The very problem with java, is also its very reason for being. It is a universal machine, with a garanteed configuration inside it.
A malware writer loves java for the same reasons you do: it is write once, run anywhere.
The issue is insisting that everything be run from an unsecured end point, such as an internet connected environment. Putting java on the internet, and on everyone's desktop is what the very problem is.
Flash has the exact same problem. Developers are suffering from battered wife syndrome here.
"But I *LOVE* java! I just wish it didn't have the security problems it does!"
You love java, because it allows you to write once, and execute anywhere. You hate java, because it allows attackers to write one, and execute anywhere.
Do the math, and accept that write once, execute anywhere being ubiquitous, has a price.
No question. Java is a very valuable and useful tool.
But it needs to stay away from the high risk environment of the desktop.
Like I said, I like the idea of java. It really is a good idea, and if java was just more discrete about where it tried to dangle its little toes, I would have zero problem with it.
But when it serves as a universal attack vector in the desktop space, there is a serious problem, and it needs to be dealt with. I feel the best solution there is to Just Say No.
I refuse to install the JDK and browser plugins on any desktop system that also touches the internet. The risk is just too damned high.
Java still shines on handheld devices, like tablets and phones, and on settop devices, like DRVs and cable boxes. An application written for the JVM can theoretically run on any architecture that has a suitable JVM implementation. That's the whole point. A device maker can use whatever chip-du-jour is the cheapest that year, and at least in theory not break all their app support, because all they have to do is make sure the JVM works.
This means a cable company can write a DVR applet for a cable box, and regardess of what horror lies inside as the bare metal, expect their already written package to run without going back and hunting down weird bugs.
But most hackers aren't interested in your cable box, or your DVR. They want something they can use to brute force passwords with, send email to others through, force into a ddos, or just use to plain straight up steal personal data with.
In short, malicious hackers want your desktop. So, if you want to keep Java as a useful tool, KEEP JAVA OFF THE DESKTOP.
Actually implementing best practices, and using portable libraries. (Like, not taking things like byte order for granted, not taking system behaviors for granted, etc.)
Oh, but that means you need to learn C, and not some platform specific language. My bad./snark
I like the *idea* of java.... but I don't like java.
It has been my experience, even way back when the JVM was owned by SUN, and when MS tried their crazy IE only "not really a real JVM but we say it is!" Bull--- that the JVM was a festering turd, that was slow, carried around a lot of baggage, and was a vector through wich malicious programs could be executed in secret due to its bugs.
Granted, that is just an anecdote. So, here's some old, tinned bugs from days of yore... clicky.
As far as I can tell, Java has always been a very attractive target for malefactors who want to run malicious executable code on remote systems, because the innate abstraction provided by the JVM makes it an ideal incubator for that malware. As such, malefactors have consistently looked for, found, and exploited holes in Java to accomplish their nefarious tasks, despite the JVM dev team's best efforts.
In short, Java has always been a security risk. The question I have always asked myself is if the benefits of that security risk outweigh the benefits. So far, my answer has always been "no." When it comes to desktop computing. For the originally intended ecosystem that Java was made for, (things like portable computers, set top boxes, and custom computing devices) java is a godsend that makes development time get spent more efficiently. For a mostly monolithic desktop hardware space, java doesn't make nearly as much sense, and carries with it a very large attack surface.
In short, I would rather do without your software, than expose myself to java's attack surface, if you refuse to write your software in a properly portable fashion, and choose to rely exclusively on the JVM.
If you need cross platform support, use cross platform libraries, and compile platform appropriate executables from your codebase. Maintaining platform agnosticism through writing exclusively portable code will force you to write better code anyway.
Leave Java in the ecosystem it belongs in: one off hardware implentations, novelty devices, and low power computing platforms. Bringing java kicking and screaming to the desktop ecosystem makes it too big of a target for malefactors, and only exposes your own unwillingness to practice best practices when writing your software.
A typical electric space heater comes in 3 ratings.
500W 1000W 1500W
That said, I found a cute little 200W one that barely feels warm even after running for hours at walmart that is intended for use on cubicle farm desks.
It really *IS* 200W at peak. I have run it successfully for hours on a 400W DC plug power inverter meant for a laptop during a winter camping trip. My impression is that the ceramic heating core heats efficiently, but that it has a rather guttless fan.
If they used something like that on the remote controlled outlet, I doubt it would cause a fire.
My motivator for purchasing a phone is not about image, but about utility. Specifically, I want a phone that is sufficiently popular to have networked effects of a greater community; For example, support for CyanogenMod, and other community produced enhancements.
Thus, the reason for purchasing the handset is not "because it looks cool, and I'm a wannabe", but because "I can get waaaaaaaaaaaay more bang for my buck than the handset maker realizes"
typically, as a function of availability, the support for devices follows the trend of "hipness", but that does not equate with my interest. Correlation is not causation. It is merely a consequence of what gets worked on by the community, because the hipper/trendier devices sell more, and have a larger userbase. it is part of a feedback cycle.
The reasons for purchasing the device are quite simple:
1) I want to be able to use the device for more than the manufacturer intends.
2) I want the device now/at all. (some are carrier exclusives in the US, thanks to BS import restrictions and laws, and I dont feel like waiting 7 to 10 business days and paying additional shipping and insurance on an international package for other types of phone, when I can get it today.)
3) I want to keep a lower service bill by owning the phone.
The intention is that I will retain my current plan, and am not contemplating leaving the carrier I am currently using, because I am currently satisfied with the service I am now receiving, and have no indications that the service will be terminated for reasons beyond my control, such as a corporate restructure. (EG, the carrier is a healthy company, that reports profits, and has a vibrant user base with coverage in my use area.)
The hypothetical situation did not in any way imply that I was dissatisfied with the CURRENT service, nor that I was paranoid that the service would be changed. In fact, the exact opposite is implied.
I gave the hypothetical situation from the standpoint of a partially informed, and somewhat savvy buyer. One who doesnt comprehend about SIM locking, and isnt concerned by it, since they dont intend to switch, nor to sell the phone. They own their phone for purely financial reasons.
Down the line, their carrier gets bought out-- (Say, NEXTEL customer in the past, bought by SPRINT-- for a historical context.) As a consequence, they get the nastygram in the mail saying that their service has been automatically upgraded, please agree to the new ToS, and expect anal violations in the form of overage charges, roaming charges, and charges for services that used to be free, and no, it is non-negotiable.
This customer calls the company, informs them that they are *NOT* interested in their new offerings, does NOT want to be automatically upgraded, and wishes to cancel service, since they are not a subsidized subscriber, and should not have to pay any ETFs, or other fees-- and wants an unlock code for their handset.
The carrier flatly says no, because it is against their corporate policy.
Given that the user:
1) does not wish to use the service of the carrier branded on their phone.
2) does indeed OWN the phone, OUTRIGHT, without any entanglements.
under what legal justification does that carrier have the right to sue said owner for seeking to unlock his or her handset his or herself?
Firstly, it requires that the purchaser be psychic, or paranoid. The user purchased the handset with the intention that it should perform a specific function. (Work with the plan the user currently has.) It does this for a time. The user then has the ToS pulled out from under them, and gets forced into a different service offering, due to the restructuring. The device is no longer fit for the purchased function, and the user has no desire to use it with the offered service. What rational basis does the carrier have to prosecute the legal owner of the phone, for wishing to do something to the phone that the user legally owns, and which the carrier has no real legal rights to, given that the user expressly does NOT wish to use their service?
The phone will be locked by default, because the default state of phones sold in the store, is the locked condition. Assume for a moment that you are not buying the phone outright because you want to re-sell it later, but because you simply don't want a contract, and want a lower monthly bill that reflects this fact.
Because the option to use a different carrier is *NOT* your primary motivator for buying the phone outright, it is not high on your list of priorities when buying the phone. Your reason for buying the phone from the store is pure convenience; you can windowshop for the phone from the brick and mortar store, and get the phone that same day. Also, some phones are carrier exclusive, and only come branded/locked inside the US.
Your argument basically boils down to "If you were stupid enough not to demand that the clerk unlock it for you immediately after purchase, you are are simply an idiot. I expect you to be informed as a customer, and to capitulate to bullshit laws that walk all over First Sale, and just accept the fact that you have no rights nor recourse as a consumer. Nevermind that the clerk may simply refuse to unlock it for you. In which case, you shouldnt buy it from a brick and mortar store, even though it is highly possible that because you have no implicit rights in terms of who controls your handset, even when you buy it outright, that you have no guarantees of being able to even legally purchase an unlocked phone of the type you want, and in fact, will likely run into a situation down the road where it is not desirable nor profitable for carriers to permit the sale of such items to begin with."
In short, your answer is bullshit, and I reject it heartily.
Say I walk into a phone store. In this case, let's say T-mobile.
I say I want a shiny new galaxy series smartphone, to replace my aging android froyo device. They eagerly wish to sign me onto a subsidized plan.
I tell them that I am already happy with my monthly refilled no contract plan, and that I have the 1K in my pocket right now to just buy the phone. They whinge a little by telling me they won't replace it if lost, stolen, or damaged, but transact the purchase.
I leave the store. I fucking ***OWN*** the phone.
Let's say that a few years later, the previously prevented ATT+T-mobile merger bullshit happens again, but this time, let's say it is sprint, or similar evil, and not ATT. Rather than be sprint's little bitch, I decide that I want to unlock my handset, and jump ship to ATT.
Uhm, that's what the fast HUFFYUV codec is for. Lossless, fast video codec. Sure, the filesize will be out of control on the capture, but it *WONT* introduce more block artifacts. It's freaking part of FDDShow's plugin pack for goodness sake! It can capture RGB formats just fine.
Just have a decent capture rig, and off you go.
I can capture a live source in huffyuv just fine without frame drops, and get a high quality input stream for an h264 encode run. Because it's a lossless format, you can bake your subs on without introducing artifacts of doom. Only ONE h264 pass needed, for final release.
But a good deal of that could be handled better, by making DF a multithread aware application, by putting some process tasks into different threads, like say-- dwarven thoughts and happiness calculations, or fluid mechanics calculations.
DF will liquify one of the cores on a multicore system, and leave all the others untouched.
For any large scale atmospheric organisms, you would need a very nutrient dense atmosphere.
Earth's atmosphere is not terrifically nutrient dense; the vast majority of nutritional sources are terrestrial, and what nutritional materials are present in the upper atmosphere gets up there through limited interactions with the surface.
This would be in sharp contrast to a nutrient dense atmosphere, like that of a gas giant rich in water vapor and CO2 with many bars of pressure. In such circumstances, said atmosphere would have more in common with an ocean, and would be able to support larger lifeforms, both because the density of the atmosphere means more displacement is possible (much like how whales live in earth's oceans), and because more photosynthetic organisms per cubic centimeter could be sustained due to the increased availability of raw materials.
Earth's atmosphere makes it very hard for something bigger than a microbe to stay purpetually suspended on the gas currents present within it, and its low pressure and density make it nutrient poor at higher altitudes. That's why only extremophile microbes live there.
Slashdot Mirror
The distinction between a buggy application, and a malicious application that "asks really nicely" to run as system, is moot. The malicious programmer will purposefully use buggy methods to get the jvm to run at system, exactly because he can then drop shit anywhere he wants. Qed.
I want the jvm to have a restriction that says it can NEVER be invoked above a limited super user I define.
As for the silent invokation, I again refer you to buggy browsers. IE is especially nasty this way. (I don't use it btw.) A process hijack in the browser to call the jre to run the .jar, would be halted, if the jre obeyed a little checkbox that says "always prompt". That's all I want there. An optional checkbox.
As for the visualvm listed above, does that come stock? I doubt it does...
No, locally.
I tested it even. Created a folder, set access privs to deny anyone access to it, except system.
The applet running was able to go inside the folder, and save a file just fine.
That is a nono. A big turd smelling nono.
Probably-- I find the environment that java applications run under to be opaque, and impossible to monitor or sanely control.
Granted, the last time I allowed myself to install the JRE was many many years ago. The application wasn't terribly important, but was necessary for what I needed, becaue there weren't any alternatives, and had the ability to open and save files. I noted that it could open and save files in places that my user did not have authority to do. When I checked the task manager, the jvm was running at a higher authority level than my user. This might have been because it needed to be installed as an actual admin, and the system automatically gave it admin privs. Regardless, that sunk it.
The fact that I can't get a list of what is running insde in a painless fashion, and can't give a global restriction on what the jre and jvm can touch, means I won't ever install it again.
The day that Oracle comes out and says "we obey local security, and have global options you can enforce, along with a way to see what the VM is running, as well as an option to forbid silent invokations" is the day I will consider installing it again.
It's my system, and it will run MY way.
I distrust the jvm, because it is very difficult to lock it down.
Desktop app developers want access to the local FS. This is because they want to do something useful, like being an office suite. You can't save files, if you don't have FS access, of course!
I can't selectively authorize the JVM to have access to specific areas with real authority. Certainly not on a windows system, where the JVM runs with system level authority. (Basically at root!) Even without the browser plugin, a driveby download script that exploits another hole in the browser can drop an applet .jar, and call the JVM to run it. The applet can then generate the rest of the malicious package, and because I can't restrict its access sanely, it can put its payload anywhere it damned well wants. Because it can spawn silently, I never see this happen.
This is especially problematical when the .jar is signed by a compromised CA.
As for what I expect it to do;
I expect it to obey restrictions I put it under, and to not run constantly behind my back. Just like it isn't a good idea to leave unmonitored servlets open on standard ports, I don't feel it is trustworthy to leave a VM running all the time, and would expect that people who claim to be professional programmers would comprehend that, and let me put restrictions on when and how the VM runs.
But no. Java wants to put hentai tentacles in, and I don't like that. That's for starters.
Also, despite the may claims to the contrary, I have actually seen java applications access areas they aren't supposed to have access to. That alone makes me nervous about what is running inside the VM.
That the VM doesn't provide me with good tools to see what really is running inside it, and kill naghty processes, is the third strike.
If I can be reasonably sure that nothing naughty is running in there, such as on an isolated intranet, I am fine leaving it running.
Otherwise, no.
....you would be surprised at the number of java "desktop applications" that won't work with the standard JRE, and demand JDK functionality.
Seriously.
With the exception of a dvr, most of those devices are low RAM, and lack a persistent writable data store, meaning a simple power off would unzombify them.
Last I checked, the desktop JVM will grant a writable datastore to appliations that request it, and even hold it persistently.
Perhaps if there were better tools to see what is running inside the jvm, and being able to terminate processes, as well as being better able to restrict what priviledges and access methods the JVM can attempt. I don't like running a magic box that welds the lid on by default.
Not being able to do those things, or worse, having the VM ignore settings you do set because the application asked realy nicely, is not going to make me trust the VM. Java integrates itself pretty deeply on the host environment to do the things it does, and it isn't a trivial matter to ensure its safeness.
Agreed! Client side execution is the problem! But, where would you expect it to run otherwise? On the server? Congrats, you just pointed a bullseye on big iron! One that can potentially run general purpose programs, and not just a simple script parser!
The problem with java, is that it is standardized, and everywhere. This makes it desirable to target. It needs alternatives, and lots of them, with heavy market penetration.
My issue is not with java.
My issue is with the demand for it t be ubiquitous, everywhere, on everything, and easily tapped.
Keep it in a box. Please. Don't make me have to install it just because you didn't feel like learing any other architectures, when in reality, there are only 4 major ones in existence right now. (*nix, *bsd, Windows, and javaVM)
I don't want it to be easy for you to run things on my computer. That's the whole fucking point.
And, low and behold, what is the single largest vector for malware these days?
Why, the unified VM that everyone is too lazy to not use, of course!
Yeesh.
That is actually precisely the point. Write once, execute anywhere being demanded for its ease of deployment is what produces the unified attack surface that malware writers find desirable.
The malware writer wants to get the most bang for his time spent developing too.
By refusing to accept less than the easy button, the same easy button you make use of, they make use of, and make use of VERY VERY heavily.
I would rather not use your software, if you demand the easy button. I would prefer a broken port that does not present a unified attack surface, than install a bullseye on my desktop, that says "put payload here! Garanteed to run!"
Just like in nature, a monoculture breeds weakness, by presenting a unified mechanism for disease, without an alternative defense. Yes, it's much easier to develop for a standardized VM, with a standardized behavior, and a standardized library. The malware writers clearly think so too.
Putting up with multiplatform support foibles is a small price to pay, for forcing malware writers to do the same.
*sigh*.
The very problem with java, is also its very reason for being. It is a universal machine, with a garanteed configuration inside it.
A malware writer loves java for the same reasons you do: it is write once, run anywhere.
The issue is insisting that everything be run from an unsecured end point, such as an internet connected environment. Putting java on the internet, and on everyone's desktop is what the very problem is.
Flash has the exact same problem.
Developers are suffering from battered wife syndrome here.
"But I *LOVE* java! I just wish it didn't have the security problems it does!"
You love java, because it allows you to write once, and execute anywhere. You hate java, because it allows attackers to write one, and execute anywhere.
Do the math, and accept that write once, execute anywhere being ubiquitous, has a price.
No question. Java is a very valuable and useful tool.
But it needs to stay away from the high risk environment of the desktop.
Like I said, I like the idea of java. It really is a good idea, and if java was just more discrete about where it tried to dangle its little toes, I would have zero problem with it.
But when it serves as a universal attack vector in the desktop space, there is a serious problem, and it needs to be dealt with. I feel the best solution there is to Just Say No.
I refuse to install the JDK and browser plugins on any desktop system that also touches the internet. The risk is just too damned high.
Java still shines on handheld devices, like tablets and phones, and on settop devices, like DRVs and cable boxes. An application written for the JVM can theoretically run on any architecture that has a suitable JVM implementation. That's the whole point. A device maker can use whatever chip-du-jour is the cheapest that year, and at least in theory not break all their app support, because all they have to do is make sure the JVM works.
This means a cable company can write a DVR applet for a cable box, and regardess of what horror lies inside as the bare metal, expect their already written package to run without going back and hunting down weird bugs.
But most hackers aren't interested in your cable box, or your DVR. They want something they can use to brute force passwords with, send email to others through, force into a ddos, or just use to plain straight up steal personal data with.
In short, malicious hackers want your desktop. So, if you want to keep Java as a useful tool, KEEP JAVA OFF THE DESKTOP.
It's really just that simple.
Actually implementing best practices, and using portable libraries. (Like, not taking things like byte order for granted, not taking system behaviors for granted, etc.)
Oh, but that means you need to learn C, and not some platform specific language. My bad. /snark
I like the *idea* of java.... but I don't like java.
It has been my experience, even way back when the JVM was owned by SUN, and when MS tried their crazy IE only "not really a real JVM but we say it is!" Bull--- that the JVM was a festering turd, that was slow, carried around a lot of baggage, and was a vector through wich malicious programs could be executed in secret due to its bugs.
Granted, that is just an anecdote. So, here's some old, tinned bugs from days of yore... clicky.
As far as I can tell, Java has always been a very attractive target for malefactors who want to run malicious executable code on remote systems, because the innate abstraction provided by the JVM makes it an ideal incubator for that malware. As such, malefactors have consistently looked for, found, and exploited holes in Java to accomplish their nefarious tasks, despite the JVM dev team's best efforts.
In short, Java has always been a security risk. The question I have always asked myself is if the benefits of that security risk outweigh the benefits. So far, my answer has always been "no." When it comes to desktop computing. For the originally intended ecosystem that Java was made for, (things like portable computers, set top boxes, and custom computing devices) java is a godsend that makes development time get spent more efficiently. For a mostly monolithic desktop hardware space, java doesn't make nearly as much sense, and carries with it a very large attack surface.
In short, I would rather do without your software, than expose myself to java's attack surface, if you refuse to write your software in a properly portable fashion, and choose to rely exclusively on the JVM.
If you need cross platform support, use cross platform libraries, and compile platform appropriate executables from your codebase. Maintaining platform agnosticism through writing exclusively portable code will force you to write better code anyway.
Leave Java in the ecosystem it belongs in: one off hardware implentations, novelty devices, and low power computing platforms. Bringing java kicking and screaming to the desktop ecosystem makes it too big of a target for malefactors, and only exposes your own unwillingness to practice best practices when writing your software.
A typical electric space heater comes in 3 ratings.
500W
1000W
1500W
That said, I found a cute little 200W one that barely feels warm even after running for hours at walmart that is intended for use on cubicle farm desks.
It really *IS* 200W at peak. I have run it successfully for hours on a 400W DC plug power inverter meant for a laptop during a winter camping trip. My impression is that the ceramic heating core heats efficiently, but that it has a rather guttless fan.
If they used something like that on the remote controlled outlet, I doubt it would cause a fire.
My motivator for purchasing a phone is not about image, but about utility. Specifically, I want a phone that is sufficiently popular to have networked effects of a greater community; For example, support for CyanogenMod, and other community produced enhancements.
Thus, the reason for purchasing the handset is not "because it looks cool, and I'm a wannabe", but because "I can get waaaaaaaaaaaay more bang for my buck than the handset maker realizes"
typically, as a function of availability, the support for devices follows the trend of "hipness", but that does not equate with my interest. Correlation is not causation. It is merely a consequence of what gets worked on by the community, because the hipper/trendier devices sell more, and have a larger userbase. it is part of a feedback cycle.
The reasons for purchasing the device are quite simple:
1) I want to be able to use the device for more than the manufacturer intends.
2) I want the device now/at all. (some are carrier exclusives in the US, thanks to BS import restrictions and laws, and I dont feel like waiting 7 to 10 business days and paying additional shipping and insurance on an international package for other types of phone, when I can get it today.)
3) I want to keep a lower service bill by owning the phone.
The intention is that I will retain my current plan, and am not contemplating leaving the carrier I am currently using, because I am currently satisfied with the service I am now receiving, and have no indications that the service will be terminated for reasons beyond my control, such as a corporate restructure. (EG, the carrier is a healthy company, that reports profits, and has a vibrant user base with coverage in my use area.)
The hypothetical situation did not in any way imply that I was dissatisfied with the CURRENT service, nor that I was paranoid that the service would be changed. In fact, the exact opposite is implied.
I gave the hypothetical situation from the standpoint of a partially informed, and somewhat savvy buyer. One who doesnt comprehend about SIM locking, and isnt concerned by it, since they dont intend to switch, nor to sell the phone. They own their phone for purely financial reasons.
Down the line, their carrier gets bought out-- (Say, NEXTEL customer in the past, bought by SPRINT-- for a historical context.) As a consequence, they get the nastygram in the mail saying that their service has been automatically upgraded, please agree to the new ToS, and expect anal violations in the form of overage charges, roaming charges, and charges for services that used to be free, and no, it is non-negotiable.
This customer calls the company, informs them that they are *NOT* interested in their new offerings, does NOT want to be automatically upgraded, and wishes to cancel service, since they are not a subsidized subscriber, and should not have to pay any ETFs, or other fees-- and wants an unlock code for their handset.
The carrier flatly says no, because it is against their corporate policy.
Given that the user:
1) does not wish to use the service of the carrier branded on their phone.
2) does indeed OWN the phone, OUTRIGHT, without any entanglements.
under what legal justification does that carrier have the right to sue said owner for seeking to unlock his or her handset his or herself?
That was the actual question.
This runs afoul of several key elements.
Firstly, it requires that the purchaser be psychic, or paranoid. The user purchased the handset with the intention that it should perform a specific function. (Work with the plan the user currently has.) It does this for a time. The user then has the ToS pulled out from under them, and gets forced into a different service offering, due to the restructuring. The device is no longer fit for the purchased function, and the user has no desire to use it with the offered service. What rational basis does the carrier have to prosecute the legal owner of the phone, for wishing to do something to the phone that the user legally owns, and which the carrier has no real legal rights to, given that the user expressly does NOT wish to use their service?
The phone will be locked by default, because the default state of phones sold in the store, is the locked condition. Assume for a moment that you are not buying the phone outright because you want to re-sell it later, but because you simply don't want a contract, and want a lower monthly bill that reflects this fact.
Because the option to use a different carrier is *NOT* your primary motivator for buying the phone outright, it is not high on your list of priorities when buying the phone. Your reason for buying the phone from the store is pure convenience; you can windowshop for the phone from the brick and mortar store, and get the phone that same day. Also, some phones are carrier exclusive, and only come branded/locked inside the US.
Your argument basically boils down to "If you were stupid enough not to demand that the clerk unlock it for you immediately after purchase, you are are simply an idiot. I expect you to be informed as a customer, and to capitulate to bullshit laws that walk all over First Sale, and just accept the fact that you have no rights nor recourse as a consumer. Nevermind that the clerk may simply refuse to unlock it for you. In which case, you shouldnt buy it from a brick and mortar store, even though it is highly possible that because you have no implicit rights in terms of who controls your handset, even when you buy it outright, that you have no guarantees of being able to even legally purchase an unlocked phone of the type you want, and in fact, will likely run into a situation down the road where it is not desirable nor profitable for carriers to permit the sale of such items to begin with."
In short, your answer is bullshit, and I reject it heartily.
Ok, here's one for you.
Say I walk into a phone store. In this case, let's say T-mobile.
I say I want a shiny new galaxy series smartphone, to replace my aging android froyo device. They eagerly wish to sign me onto a subsidized plan.
I tell them that I am already happy with my monthly refilled no contract plan, and that I have the 1K in my pocket right now to just buy the phone. They whinge a little by telling me they won't replace it if lost, stolen, or damaged, but transact the purchase.
I leave the store. I fucking ***OWN*** the phone.
Let's say that a few years later, the previously prevented ATT+T-mobile merger bullshit happens again, but this time, let's say it is sprint, or similar evil, and not ATT. Rather than be sprint's little bitch, I decide that I want to unlock my handset, and jump ship to ATT.
Sprint says NO, we own you now.
How do you suggest I proceed?
Uhm, that's what the fast HUFFYUV codec is for. Lossless, fast video codec. Sure, the filesize will be out of control on the capture, but it *WONT* introduce more block artifacts. It's freaking part of FDDShow's plugin pack for goodness sake! It can capture RGB formats just fine.
Just have a decent capture rig, and off you go.
I can capture a live source in huffyuv just fine without frame drops, and get a high quality input stream for an h264 encode run. Because it's a lossless format, you can bake your subs on without introducing artifacts of doom. Only ONE h264 pass needed, for final release.
No joke!
But a good deal of that could be handled better, by making DF a multithread aware application, by putting some process tasks into different threads, like say-- dwarven thoughts and happiness calculations, or fluid mechanics calculations.
DF will liquify one of the cores on a multicore system, and leave all the others untouched.
For any large scale atmospheric organisms, you would need a very nutrient dense atmosphere.
Earth's atmosphere is not terrifically nutrient dense; the vast majority of nutritional sources are terrestrial, and what nutritional materials are present in the upper atmosphere gets up there through limited interactions with the surface.
This would be in sharp contrast to a nutrient dense atmosphere, like that of a gas giant rich in water vapor and CO2 with many bars of pressure. In such circumstances, said atmosphere would have more in common with an ocean, and would be able to support larger lifeforms, both because the density of the atmosphere means more displacement is possible (much like how whales live in earth's oceans), and because more photosynthetic organisms per cubic centimeter could be sustained due to the increased availability of raw materials.
Earth's atmosphere makes it very hard for something bigger than a microbe to stay purpetually suspended on the gas currents present within it, and its low pressure and density make it nutrient poor at higher altitudes. That's why only extremophile microbes live there.