Somebody please mod parent up! It needs to be +5 Informative.
First thing I thought of was the Borland version (Winsight), and this is exactly how you figure this kind of nonsense out. These apps actually enumerate all current window handles and will give you owning pids, parent/child windows, message queues, etc. If you don't already have a Borland IDE license, Borland now offers free (beer) and trial versions of their products, just dl a windows version and it ought to come with this tool.
If not, I also found another similar standalone app called Winspector (not to be confused w/ Borland's Winspector, which does something different) at http://www.windows-spy.com/, but I have not used it and can't vouch for it.
Heh, yeah, esp. considering I was talking about a different distro:) I downloaded several "tiny" distros, including a micro distro that was most likely descended from muLinux (which I think I'll probably end up using for my own purposes). Do you think DSL-N is even necessary for the OP's purposes tho? DSL should suffice, maybe even something smaller, as long as it has PPP?
Oops, I'm describing one of the many micro distros out there (I forget which one, but I have a feeling it was derived from muLinux). Damn Small Linux (DSL) is a step above these micro distros - a little more robust and a little heftier (weighing in at a whopping 50 MB and 128 MR RAM I think). For your case, I think just about any stable tiny (or micro) distribution that supports PPP should do. Some more tiny linux distros here.
I dunno, I ran Damn Small in a VM to try it out and it's that: small, fast, simple. Might work for what you're doing. It boots from 2 x 1.44 MB floppies, CD, USB pen drive, etc., and it requires no HDD and very little RAM. It includes a web browser (sorry, don't recall which one), supports PPP, and I'd guess you shouldn't have much trouble installing any extra apps you need. Only bad things I can think of are that the version I tried out didn't include mkfs (not too difficult to work around) and I think you have to jump through a few hoops to get the source code (stuff five bucks in an envelope, tho I didn't search very hard for the source:). damnsmalllinux.org
Heh, I've since figured out how to do it by hand (worked out something pretty similar to Newton's method on my own), but I've never learned the long division version. Pretty slick.:) It's kind of thing that ought to be taught in school, seeing as it's 100% accurate for numbers with rational roots, and it really is easy.
I guess sometimes reading the post you're replying to before posting is also a good idea.
FMFP (you can figure that one out) --- Hmm, we've been dealing with this in the Gulf for a while.... there's a pretty scientific assessment of the phenomenon (in the gulf at least) here [noaa.gov]
The "IIRC, though, wind actually helps by mixing the water, so global warming shouldn't really enter into this picture" part, however, does reference to TFA... And isn't this discussion over anyway?
We were taught to do it by hand but not in any kind of useful way, and I seriously believe I'd have been better off not learning it! Granted we got an answer, but it was not exactly graceful or mathematically rigorous. "Ok, class, the square root of 2 is greater than one but less than 2, let's see if it's 1.5... (Square 1.5). Hmm, no, too large. How about 1.2? (Square 1.2) No. How about 1.3? (Square 1.3) No. How about 1.4? (Square 1.4) Still too small, but now we know it's bigger than 1.4 and smaller than 1.5. Let's try 1.45..." ad nauseum. After you got to just 2 or 3 digits, you've filled up an entire sheet of notebook paper and chances are you'd made a mistake along the way anyway. Well, that's public school for ya.
I think the OP just meant other groups, IRA, McVeigh, etc., fit the traditional definition of terrorism, in that they use terror tactics to scare civilians/government by targeting govt/military targets. Civilians, however, are not the (intended) target of the violence. Islamic Fascists, OTOH, actually target civilians these days. Of course, there are probably many other reasons the IRA wouldn't do that (suicide is a sin, etc.).
Allowing the feces to compost though it can then be used for fertilizer then chemical fertilizers wouldn't need to be used so much.
In this case, I don't think there's a difference whether the nitrates come from, and IIRC, composting actually increases this by taking nitrogen from the air.
Also if they were allowed freerange, they could so in one location or field one year then moved to another the following year. The second year a covercrop could be sown, then the third grains or vegetables can be growth on it, without needing more fertilizers. Actually this is how some organic farms operate but the big agrobusiness farms would probably frown on it.
Agreed. Any time somebody studies this sort of thing, it always comes back to crop rotation as being ideal. I think I read somewhere that it works because that is how ecologies work, one mix of life takes over and sets the stage for another to take over, ad infinitum. A lot of people don't realize it, but ecosystems can actually migrate. I've heard of people timelapsing a particular stretch of land and seeing, for example, a prairie "march" across a desert, or a forest "march" across a savannah. Really weird.
why don't they get together and sue the farmers upstream.
I think there are three problems with that: first, jurisdiction. It's hard to say what state, much less which country, the actionable offense occurred in. And if the Dead Zone is in international waters, that's not anybody's jurisdiction...
Second, even if you solve the jurisdiction problem, you still have the problem of naming the defendents. The only farms without lawyers savvy enough to have it immediately tossed out of court are probably the independent family farms, and they're probably not even responsible. This is why agencies like the EPA exist, because it is much easier to say, "They harm the environment, that hurts everybody, so we bring The People vs. So-and-so".
The biggest problem is that this isn't pollution, otherwise the EPA would have stepped in a long time ago. Nitrogen, nitrates and phosphates are fertilizer, which is why pig manure can cause a dead zone. I don't think anybody's going to hold a farm responsible for polluting the environment because they used manure for fertilizer, and the only difference between chemical fertilizers and manure is that the cheaper version is made of feces.
Hmm, we've been dealing with this in the Gulf for a while. It's recurrant - it goes away, then comes back the next year, and is caused by too much algae, which is basically fed by nitrogen rich runoff from ground water. IIRC, though, wind actually helps by mixing the water, so global warming shouldn't really enter into this picture. Not to say the article didn't quote somebody saying that, or that different climates won't affect things, but that's just what I heard. For anybody interested, there's a pretty scientific assessment of the phenomenon (in the gulf at least) here (I don't think anybody's linked to this yet, apologies if this is a dupe). Anyway, don't panic, Oregonians, you'll survive! Cheers.
Hi again, I already replied to most of this in another comment, but there a couple things I wanted to reply to.
Let me put it this way -- I would much rather have one dominant, secure OS than many insecure ones. This is true for the same reason most games are linear -- it's better to have one good story than an infinite number of bad ones.
First, I don't see Linux as one operating system, I see it as many, and this is part of its strength. Windows adapts too, but Linux adapts better because there are more strains. As for one dominant, secure OS, that's what my post was about - I think the two are mutually incompatible goals. Being the dominant OS is going to attract the efforts of malware authors, who will focus on the exploits available to all unpatched systems. I honestly believe that Windows and Linux would be in opposite (though probably less pronounced, because OSS is generally more secure) situations when it comes to vulnerabilities and exploits if Linux had a 90% marketshare, because 90% of the bad guys would be working on exploiting that system rather than Windows. And not all the bad guys are script kiddies - some of them really know what they're doing, and would have no trouble picking through Linux (and with an OSS model, they could even intentionally introduce vulnerabilities directly into the source).
This ignores the security implications, too -- booting to an app means the app has full control of the machine, even moreso than a root user on a Unix.
:) You are the first person to catch this! I was actually surprised nobody mentioned it earlier. However, with physical access to the computer, you can pretty much do whatever you want to the machine (with the obvious exception of accessing encrpyted filesystems, or doing any real damage to a dumb terminal, etc., but I'm not talking about those cases, so I'll save you the trouble of pointing that out). As long as booting to an application is restricted to bootable media inserted into a physical drive, you haven't compromised security any more than it already is by giving the user physical access to the hardware in the first place. Allowing an app to reboot the computer and start itself as the OS, though, is a huge risk.
Anyway, I've really got to run... If you haven't read Out of Control I definitely recommend it, it's a little dated, but still very good. cheers.
Hey, I read your other comment but this one is easier to reply to so here goes. Hope you don't mind.
First, the word you're looking for here is "emulation", not "virtualization", since you're now talking about running code for a different arch. It's important that you understand the difference, because emulation slows things down a ton.
Virtualization is, IMO, a proper subset of emulation, although a lot of people get confused between the two and use the terms interchangeably, since an emulated machine is often called a virtual machine (say, for instance, the J2RE). Yes, there are two different things going on at the hardware level here, but an OS capable of doing what TFA is talking about shouldn't have too much trouble supporting non-native architectures.
Second, what's your point here? Why is an emulator that runs Java bytecode as if a Java machine really existed better than just shipping the JVM? Go look it up -- JVM stands for Java Virtual Machine. You already can distribute your Java bytecode as if it were an executable, and tell people to run it on the JVM..NET takes this a step further -- you can distribute a.NET assembly (equivalent of Java bytecode) as a.exe file, and if.NET is installed, Windows will recognize your.exe file as a.NET program, and run it in the.NET VM. Thus, you can double-click on the.exe as if it were a Windows executable -- no need for Joe User to realize I can do the same thing on Linux as if it were a Linux executable (assuming I set it up that way first). What's more, Linux has been doing this with scripts for ages -- download a.pl file, and the OS (or your shell, not sure which) will see it as a Perl script, and run it through Perl.
How all this works isn't exactly magic to most of the people here, myself included, but to a lot of my friends and family, it is magic and what they want to know is, "Why does this work, but that doesn't?" "Just download the JVM, install it with admin rights, and then download and run my app," is easy enough for you to say, but not so easy for my wife to actually do. However, you're right, it will run slower, so perhaps Java was not the best example. There are, however, cases where emulation of different architecture would make sense, and an OS capable of taking full advantage of VT should have no problem emulating other classes of machine, even if it is a little slower (and remember, JIT-compilation and executable caches exist now, so frequently traveled execution paths need not execute any slower than native code).
What's more, the JVM is superior to your approach in that Java bytecode, running under the JVM, can be compiled JIT (just-in-time) to the host hardware, at which point it's no longer emulation.
See above. What's to prevent other emulated bytecode from being JIT-compiled in exactly the same way with exactly the same benefits? Perhaps a better way to suggest what I'm talking about would be to adopt a Java or.NET style platform that recognized different bytecodes and could JIT-compile them. Virtualization is often used as a blanket term that includes emulation so I went ahead and used it that way (though mathematically, I think it's the other way around). Whether or not you think this would be stoopid, this is the way the market's been going for the last couple of years, so you might as well try to think ahead.
Perhaps the most important thing to note, though, is this: This sort of fictional, speculatory operating system that has the potential to change how the most basic OS levels function doesn't actually exist, and the article is set four or so years in the future. We're talking fantasy anyway, so why not
Are you in the habit of downloading updates and patches for all your programs every week?
I run Windows as my host operating system, so yes:(
Granted, if the library patch breaks a critical application, either all of your programs remain vulnerable or you go through the trouble of relinking the single application that broke. However, in UNIX, that shouldn't be terribly difficult, just a matter of altering LD_LIBRARY_PATH.
Good point. In a VM, the risk is not as pronounced, though it is certainly still there any time you have a Mail This Document To a Recipient, etc.
I guess I ought to clarify a few things. First, I am not saying statically linked libraries are superior to shared libraries. In most cases, shared makes more sense. In some cases, when relaxed security is an option (such as in a VM), it may make sense to swap out shared components for custom, static linked components (and static linking is faster). DOOM 3, for instance, does not need a firewall if it only listens on one port. It does not need a complicated IP stack if it only handles one kind of transport protocol. It doesn't need DNS if it connects to a static IP, etc. In this case, statically linking to a fast, trim IP stack would be useful replacement for the bloated (by comparison) IP stack that is probably included in an OS. I ought to also note that in this regard, there is no benefit in doing things this way if the application is not bootable, since all device access in the VM will of course be routed through the OS anyway.
I should also note that physical access to a PC is still the ultimate authority when it comes to access. With the right disk and access to the physical machine, you can pretty much get into any PC, so it makes no sense to restrict what an application in a VM can do, or to deny a VM application access to real physical components if you choose to load it that way.
Finally, I ought to tie this back to my original post: in a VM-based OS, you can have a more diverse ecology of software. You don't need to worry about security vulnerabilities as much if everybody is statically linking to different libraries because the more different versions exist, the less likely they are to be exploited, esp. if exploits are kept limited to the VM in which they occurred. You get both damage control and fewer damaging events.
Would the publisher need to sell a separate edition for each make and model of video card?
I don't see why they'd need to. This article is entirely speculatory, and it'd be a big feat to do all this, but I remember booting to DOS games that had their own drivers. As long as the OS exposed critical files like the kernel and drivers via a method accessible to both the real machine and not just VMs (e.g., a local partition), then I would think any publisher that could get a game to boot in a VM would do their best to get it to boot on the real thing (real h/w = faster game = better experience = ??? = profit!).
No, statically-linked apps aren't nice when one of the things statically linked has a security hole.
You are correct. If all your apps link to the same security hole, you're boned. Of course, if they're statically linked, only the applications are exposed to exploits, not the system, esp. if they're running in a VM. If you use shared libraries, then every application that shares that library has a hole until it's patched, and it's not the application that's compromised, it's the OS. I admit it's easier to patch a single file rather than several dozen, or even several hundred, but when you patch it, do you know which apps will make the transition gracefully and which will crash and burn?
Don't get me wrong, I prefer shared libraries, as long as strict versioning is enforced. It's just that some apps (notably, games) make use of shared libraries and are very sensitive to changes in those libraries, and it's nice to have a realistic and secure alternative when warranted.
I suspect you're just trolling, but what the hey, I'm not exactly busy at the moment...
Yeah, right... Except that they invented OSes for a reason...
"Graphical interfaces for applications? Windows? Hey, they invented a console interface for a reason!" Same argument, same answer: Hardware couldn't handle it. Now it can. And this way is better.
If I understood correctly your posts, much work will be duplicated (once for the host, twice for the app) which isn't practical. OSes are there to avoid reinventing the wheel in every app.
For instance, most developers don't want to develop a network stack for every net-using app they develop.
True. Code re-use is good, and this may be why MS didn't sound too keen on the idea. Somewhere (either the/. story header or TFA itself) mentioned multiple partitions. More likely, just make shared libraries available on a virtual drive and you don't need to reinvent the wheel - you have access to the same copy everybody else uses. Or, you could stick to a thin-client OS and just add the shared components you need as redist packages (this is not exactly foreign Windows - it's just that MS can't seem to decide what exactly they want their OS to be). This would have you duplicating things between applications, but not between application & OS.
Statical linked libraries aren't nice if you don't have much RAM.
Which is why Blackberries don't virtualize. Modern PCs with tons of RAM and virtualizing chipsets can handle it. Static linking (or at least strict versioning) puts an end to DLL Hell, and if you're that worried about it, hosts can share all or part of a filesystem with a VM.
"Cross-plataform plataforms"? If you mean something like Java and.Net... well, it's done already!
Exactly my point - why reinvent the wheel? I had two points to this, but I didn't state either because I thought they were obvious. Guess not. First, with good VM support and a VM built like an operating system rather than an application or service, you can load the VM into any VM that can run the hardware that "inner" VM is designed to run on. For example, a.NET runtime host could be run in a virtual Windows environment, or Java in a virtual Linux (or any other) environment. Nothing too stunning there.
The second and more intriguing idea is that you might even be able to virtualize bytecode for which no hardware actually exists, hence why I mentioned.NET and Java. Rather than sticking to runtime hosts, pop them into a VM that virtualizes their run-time environment and you're set. Instead of x86, you're running, say, j86 (that's a dumb pun). Your machine code no longer has to be a Windows or Linux executable, it can be Java bytecode (no need for J2RE) or MSIL (no need for an RTH or JIT-compiler*). That would be pretty damn slick, AFAIC.
* I feel compelled to mention that while virtualization might improve the performance of Java, it probably won't improve.NET in the long run. After a few passes, when the JIT-compiler builds up enough native code in the executable cache, I suspect the native.NET app in a RTH will outperform the virtualized, no-RTH version.
While I think you've got a great concept there, have you tried using any 3d app in a virtualized OS?
In short, no. Hardware virtualization (as in supported by the chipset, not virtualizing the hardware) has me hoping that the performance degredation I see from just simple 2d blitting won't carry over to a virtualized game. However, my point had more to do with booting straight into a "bootable" game, bypassing the OS alltogether. If it runs on the same architecture as the host OS that is virtualizing it, then the host OS is not actually required (except for drivers, etc., but these could be exposed via a dedicated partition). Also, I thought it worth mentioning that virtual machines can be allowed direct access to hardware. Since graphics are offloaded to a GPU, you don't have to virtualize the GPU, even if you can't boot straight to the game and instead have to run it in a VM.
As for standard GUI principles - things change. 90% of the people out there are used to the Windows GUI, so while it may not be ideal, people are familiar enough with it. Combine that with the Actually Just Works of OS X (after 10+ years of Windows, I became usefully familiar with OS X in literally a few hours), I think we have some decent guidelines.
I'm sure you know, but I state it because other people may read this too: GUI standards lower learning curves. The fact that you learned OS X in a few hours is a testament to good GUI design in both Mac OS X and Windows (oops, mod me down to -1 Complimented Windows;). However, I'm withdrawing my complaint about GUIs - developers already abuse GUI design principles just fine without virtualization:)
There would need to be a standardized virtual 3D video card. I don't see that happening any time soon.
VMs can allow access to physical hardware, but I was actually referring to boot-to-game at the machine level, e.g., Halo OS, or Source OS. The host OS can expose what it needs to as partitions and bootable software running on the same equipment as the host operating system could bypass the operating system and boot straight to the application. Either way, though, no virtual 3d card required.
Kevin Kelly's Out of Control got me thinking about this a while back. Although the book is a little dated, it is all about network economies and their similarities to ecological systems, and I realized that evolution is at work when it comes to platform adoption. Greater than 90% of desktops run Windows, so there's no variety in the PC platform genepool. Just like inbred populations, this PC pool is unhealthy: it can't adapt and infections run rampant because all specimens are susceptible to the same illnesses.
Of course, who's going to change to another platform when there's no software out there? (No flames please - try to remember perception is everything, and ask yourself whether an average user realizes alternatives exist.) Virtualization, I think, is a good answer to this. I like the idea of "booting" to an application like in the pre-DOS days, and if your games run no x86/x64 architecture, you could bypass the OS altogether to get the most out of games by just booting straight into Halo 4 or HalfLife 3. I also like the end of the API: we can go back to the days of static linked libraries (no version conflicts, ever!) and headers and just build our own OSes from scratch to run in a VM. Since you can virtualize anything, even VMs, you can get cross-platform apps and cross-platform platforms (Java,.NET, etc.) and consumers don't have to worry about physical hardware or their underlying OS components, apart from cost and performance considerations. As far as their apps go, everything could, theoretically, work the same on any system (whether business decisions will allow this to happen, we'll just have to see). In fact, my only worry about this is how to allow for a standard GUI on such a system (but since nobody, not even Microsoft, follows GUI principles these days anyway, it probably doesn't matter).
This is, IMO, a far superior way to do things than how they're done now. So, okay, then, OSS community, please get to work so you will be finished before MS is. Thank you.
Vivaldi (the idiot mafia boss): What is this, Benedict? First you're my friend, now you turn a 360 on me? Benedict (his henchman): 180, you stupid, spaghetti-slurping cretin! 180! If it was a 360, I'd go completely around and end up back where I started! Vivaldi:... [confused] What? Benedict: Trust me. [Shoots Vivaldi.]
Everybody gives Majora's Mask such a hard time too. I admit it could have been better. That fish guy you play who's also a rock star? That was dumb. And it seemed short with only four real dungeons, but it was a good game. Those dungeons are about 3 times as big as the ones in OoT, so only 4 is really like 10 or 12 dungeons in OoT (and there are quite a few mini-dungeons on top of that). The idea of having 3 "days" to beat the game or start over -- that was pressure... especially that very first day in Clock Town. Now that you mention it, I do wish they had a hard mode like they do in Shadow of the Colossus. I played OoT: Master Quest, but it was only tougher puzzles and most of them didn't make any sense. I want to fight somebody that can fight back, not shoot a slingshot at a cow in a wall. I don't get it.
Does it still count as cheating if you make it harder?:)
Not in my book. I'm playing CoD2 in Veteran mode. 3-4 shots from small round (Luger, MP40) = death. 1-2 shots from larger rounds (rifles, MP44, MG-42) = death. 1 anti-tank (rocket, 88mm, etc.) or a head shot = death. Makes you think twice about poking your head out from cover. And no quicksave in that game:)
Slashdot Mirror
Somebody please mod parent up! It needs to be +5 Informative.
First thing I thought of was the Borland version (Winsight), and this is exactly how you figure this kind of nonsense out. These apps actually enumerate all current window handles and will give you owning pids, parent/child windows, message queues, etc. If you don't already have a Borland IDE license, Borland now offers free (beer) and trial versions of their products, just dl a windows version and it ought to come with this tool.
If not, I also found another similar standalone app called Winspector (not to be confused w/ Borland's Winspector, which does something different) at http://www.windows-spy.com/, but I have not used it and can't vouch for it.
Heh, yeah, esp. considering I was talking about a different distro :) I downloaded several "tiny" distros, including a micro distro that was most likely descended from muLinux (which I think I'll probably end up using for my own purposes). Do you think DSL-N is even necessary for the OP's purposes tho? DSL should suffice, maybe even something smaller, as long as it has PPP?
Oops, I'm describing one of the many micro distros out there (I forget which one, but I have a feeling it was derived from muLinux). Damn Small Linux (DSL) is a step above these micro distros - a little more robust and a little heftier (weighing in at a whopping 50 MB and 128 MR RAM I think). For your case, I think just about any stable tiny (or micro) distribution that supports PPP should do. Some more tiny linux distros here.
I dunno, I ran Damn Small in a VM to try it out and it's that: small, fast, simple. Might work for what you're doing. It boots from 2 x 1.44 MB floppies, CD, USB pen drive, etc., and it requires no HDD and very little RAM. It includes a web browser (sorry, don't recall which one), supports PPP, and I'd guess you shouldn't have much trouble installing any extra apps you need. Only bad things I can think of are that the version I tried out didn't include mkfs (not too difficult to work around) and I think you have to jump through a few hoops to get the source code (stuff five bucks in an envelope, tho I didn't search very hard for the source :). damnsmalllinux.org
Heh, I've since figured out how to do it by hand (worked out something pretty similar to Newton's method on my own), but I've never learned the long division version. Pretty slick. :) It's kind of thing that ought to be taught in school, seeing as it's 100% accurate for numbers with rational roots, and it really is easy.
I guess sometimes reading the post you're replying to before posting is also a good idea.
... there's a pretty scientific assessment of the phenomenon (in the gulf at least) here [noaa.gov]
FMFP (you can figure that one out) ---
Hmm, we've been dealing with this in the Gulf for a while.
The "IIRC, though, wind actually helps by mixing the water, so global warming shouldn't really enter into this picture" part, however, does reference to TFA... And isn't this discussion over anyway?
Grr, you're technically correct, which is all that counts in math!
That's more the point I was trying to make :)
We were taught to do it by hand but not in any kind of useful way, and I seriously believe I'd have been better off not learning it! Granted we got an answer, but it was not exactly graceful or mathematically rigorous. "Ok, class, the square root of 2 is greater than one but less than 2, let's see if it's 1.5... (Square 1.5). Hmm, no, too large. How about 1.2? (Square 1.2) No. How about 1.3? (Square 1.3) No. How about 1.4? (Square 1.4) Still too small, but now we know it's bigger than 1.4 and smaller than 1.5. Let's try 1.45 ..." ad nauseum. After you got to just 2 or 3 digits, you've filled up an entire sheet of notebook paper and chances are you'd made a mistake along the way anyway. Well, that's public school for ya.
What the hell is wrong with you? Who said anything about any of these attacks being legitimate?
I think the OP just meant other groups, IRA, McVeigh, etc., fit the traditional definition of terrorism, in that they use terror tactics to scare civilians/government by targeting govt/military targets. Civilians, however, are not the (intended) target of the violence. Islamic Fascists, OTOH, actually target civilians these days. Of course, there are probably many other reasons the IRA wouldn't do that (suicide is a sin, etc.).
I don't mean to be pedantic, but I think you meant to say, "There were fewer than five errors in that post."
In this case, I don't think there's a difference whether the nitrates come from, and IIRC, composting actually increases this by taking nitrogen from the air.
Agreed. Any time somebody studies this sort of thing, it always comes back to crop rotation as being ideal. I think I read somewhere that it works because that is how ecologies work, one mix of life takes over and sets the stage for another to take over, ad infinitum. A lot of people don't realize it, but ecosystems can actually migrate. I've heard of people timelapsing a particular stretch of land and seeing, for example, a prairie "march" across a desert, or a forest "march" across a savannah. Really weird.
I think there are three problems with that: first, jurisdiction. It's hard to say what state, much less which country, the actionable offense occurred in. And if the Dead Zone is in international waters, that's not anybody's jurisdiction...
Second, even if you solve the jurisdiction problem, you still have the problem of naming the defendents. The only farms without lawyers savvy enough to have it immediately tossed out of court are probably the independent family farms, and they're probably not even responsible. This is why agencies like the EPA exist, because it is much easier to say, "They harm the environment, that hurts everybody, so we bring The People vs. So-and-so".
The biggest problem is that this isn't pollution, otherwise the EPA would have stepped in a long time ago. Nitrogen, nitrates and phosphates are fertilizer, which is why pig manure can cause a dead zone. I don't think anybody's going to hold a farm responsible for polluting the environment because they used manure for fertilizer, and the only difference between chemical fertilizers and manure is that the cheaper version is made of feces.
Hmm, we've been dealing with this in the Gulf for a while. It's recurrant - it goes away, then comes back the next year, and is caused by too much algae, which is basically fed by nitrogen rich runoff from ground water. IIRC, though, wind actually helps by mixing the water, so global warming shouldn't really enter into this picture. Not to say the article didn't quote somebody saying that, or that different climates won't affect things, but that's just what I heard. For anybody interested, there's a pretty scientific assessment of the phenomenon (in the gulf at least) here (I don't think anybody's linked to this yet, apologies if this is a dupe). Anyway, don't panic, Oregonians, you'll survive! Cheers.
Hi again, I already replied to most of this in another comment, but there a couple things I wanted to reply to.
First, I don't see Linux as one operating system, I see it as many, and this is part of its strength. Windows adapts too, but Linux adapts better because there are more strains. As for one dominant, secure OS, that's what my post was about - I think the two are mutually incompatible goals. Being the dominant OS is going to attract the efforts of malware authors, who will focus on the exploits available to all unpatched systems. I honestly believe that Windows and Linux would be in opposite (though probably less pronounced, because OSS is generally more secure) situations when it comes to vulnerabilities and exploits if Linux had a 90% marketshare, because 90% of the bad guys would be working on exploiting that system rather than Windows. And not all the bad guys are script kiddies - some of them really know what they're doing, and would have no trouble picking through Linux (and with an OSS model, they could even intentionally introduce vulnerabilities directly into the source).
Anyway, I've really got to run... If you haven't read Out of Control I definitely recommend it, it's a little dated, but still very good. cheers.
Hey, I read your other comment but this one is easier to reply to so here goes. Hope you don't mind.
Virtualization is, IMO, a proper subset of emulation, although a lot of people get confused between the two and use the terms interchangeably, since an emulated machine is often called a virtual machine (say, for instance, the J2RE). Yes, there are two different things going on at the hardware level here, but an OS capable of doing what TFA is talking about shouldn't have too much trouble supporting non-native architectures.
How all this works isn't exactly magic to most of the people here, myself included, but to a lot of my friends and family, it is magic and what they want to know is, "Why does this work, but that doesn't?" "Just download the JVM, install it with admin rights, and then download and run my app," is easy enough for you to say, but not so easy for my wife to actually do. However, you're right, it will run slower, so perhaps Java was not the best example. There are, however, cases where emulation of different architecture would make sense, and an OS capable of taking full advantage of VT should have no problem emulating other classes of machine, even if it is a little slower (and remember, JIT-compilation and executable caches exist now, so frequently traveled execution paths need not execute any slower than native code).
See above. What's to prevent other emulated bytecode from being JIT-compiled in exactly the same way with exactly the same benefits? Perhaps a better way to suggest what I'm talking about would be to adopt a Java or .NET style platform that recognized different bytecodes and could JIT-compile them. Virtualization is often used as a blanket term that includes emulation so I went ahead and used it that way (though mathematically, I think it's the other way around). Whether or not you think this would be stoopid, this is the way the market's been going for the last couple of years, so you might as well try to think ahead.
Perhaps the most important thing to note, though, is this: This sort of fictional, speculatory operating system that has the potential to change how the most basic OS levels function doesn't actually exist, and the article is set four or so years in the future. We're talking fantasy anyway, so why not
I run Windows as my host operating system, so yes :(
Good point. In a VM, the risk is not as pronounced, though it is certainly still there any time you have a Mail This Document To a Recipient, etc.
I guess I ought to clarify a few things. First, I am not saying statically linked libraries are superior to shared libraries. In most cases, shared makes more sense. In some cases, when relaxed security is an option (such as in a VM), it may make sense to swap out shared components for custom, static linked components (and static linking is faster). DOOM 3, for instance, does not need a firewall if it only listens on one port. It does not need a complicated IP stack if it only handles one kind of transport protocol. It doesn't need DNS if it connects to a static IP, etc. In this case, statically linking to a fast, trim IP stack would be useful replacement for the bloated (by comparison) IP stack that is probably included in an OS. I ought to also note that in this regard, there is no benefit in doing things this way if the application is not bootable, since all device access in the VM will of course be routed through the OS anyway.
I should also note that physical access to a PC is still the ultimate authority when it comes to access. With the right disk and access to the physical machine, you can pretty much get into any PC, so it makes no sense to restrict what an application in a VM can do, or to deny a VM application access to real physical components if you choose to load it that way.
Finally, I ought to tie this back to my original post: in a VM-based OS, you can have a more diverse ecology of software. You don't need to worry about security vulnerabilities as much if everybody is statically linking to different libraries because the more different versions exist, the less likely they are to be exploited, esp. if exploits are kept limited to the VM in which they occurred. You get both damage control and fewer damaging events.
I don't see why they'd need to. This article is entirely speculatory, and it'd be a big feat to do all this, but I remember booting to DOS games that had their own drivers. As long as the OS exposed critical files like the kernel and drivers via a method accessible to both the real machine and not just VMs (e.g., a local partition), then I would think any publisher that could get a game to boot in a VM would do their best to get it to boot on the real thing (real h/w = faster game = better experience = ??? = profit!).
You are correct. If all your apps link to the same security hole, you're boned. Of course, if they're statically linked, only the applications are exposed to exploits, not the system, esp. if they're running in a VM. If you use shared libraries, then every application that shares that library has a hole until it's patched, and it's not the application that's compromised, it's the OS. I admit it's easier to patch a single file rather than several dozen, or even several hundred, but when you patch it, do you know which apps will make the transition gracefully and which will crash and burn?
Don't get me wrong, I prefer shared libraries, as long as strict versioning is enforced. It's just that some apps (notably, games) make use of shared libraries and are very sensitive to changes in those libraries, and it's nice to have a realistic and secure alternative when warranted.
I suspect you're just trolling, but what the hey, I'm not exactly busy at the moment...
"Graphical interfaces for applications? Windows? Hey, they invented a console interface for a reason!" Same argument, same answer: Hardware couldn't handle it. Now it can. And this way is better.
True. Code re-use is good, and this may be why MS didn't sound too keen on the idea. Somewhere (either the /. story header or TFA itself) mentioned multiple partitions. More likely, just make shared libraries available on a virtual drive and you don't need to reinvent the wheel - you have access to the same copy everybody else uses. Or, you could stick to a thin-client OS and just add the shared components you need as redist packages (this is not exactly foreign Windows - it's just that MS can't seem to decide what exactly they want their OS to be). This would have you duplicating things between applications, but not between application & OS.
Which is why Blackberries don't virtualize. Modern PCs with tons of RAM and virtualizing chipsets can handle it. Static linking (or at least strict versioning) puts an end to DLL Hell, and if you're that worried about it, hosts can share all or part of a filesystem with a VM.
Exactly my point - why reinvent the wheel? I had two points to this, but I didn't state either because I thought they were obvious. Guess not. First, with good VM support and a VM built like an operating system rather than an application or service, you can load the VM into any VM that can run the hardware that "inner" VM is designed to run on. For example, a .NET runtime host could be run in a virtual Windows environment, or Java in a virtual Linux (or any other) environment. Nothing too stunning there.
The second and more intriguing idea is that you might even be able to virtualize bytecode for which no hardware actually exists, hence why I mentioned .NET and Java. Rather than sticking to runtime hosts, pop them into a VM that virtualizes their run-time environment and you're set. Instead of x86, you're running, say, j86 (that's a dumb pun). Your machine code no longer has to be a Windows or Linux executable, it can be Java bytecode (no need for J2RE) or MSIL (no need for an RTH or JIT-compiler*). That would be pretty damn slick, AFAIC.
* I feel compelled to mention that while virtualization might improve the performance of Java, it probably won't improve .NET in the long run. After a few passes, when the JIT-compiler builds up enough native code in the executable cache, I suspect the native .NET app in a RTH will outperform the virtualized, no-RTH version.
In short, no. Hardware virtualization (as in supported by the chipset, not virtualizing the hardware) has me hoping that the performance degredation I see from just simple 2d blitting won't carry over to a virtualized game. However, my point had more to do with booting straight into a "bootable" game, bypassing the OS alltogether. If it runs on the same architecture as the host OS that is virtualizing it, then the host OS is not actually required (except for drivers, etc., but these could be exposed via a dedicated partition). Also, I thought it worth mentioning that virtual machines can be allowed direct access to hardware. Since graphics are offloaded to a GPU, you don't have to virtualize the GPU, even if you can't boot straight to the game and instead have to run it in a VM.
I'm sure you know, but I state it because other people may read this too: GUI standards lower learning curves. The fact that you learned OS X in a few hours is a testament to good GUI design in both Mac OS X and Windows (oops, mod me down to -1 Complimented Windows ;). However, I'm withdrawing my complaint about GUIs - developers already abuse GUI design principles just fine without virtualization :)
VMs can allow access to physical hardware, but I was actually referring to boot-to-game at the machine level, e.g., Halo OS, or Source OS. The host OS can expose what it needs to as partitions and bootable software running on the same equipment as the host operating system could bypass the operating system and boot straight to the application. Either way, though, no virtual 3d card required.
Kevin Kelly's Out of Control got me thinking about this a while back. Although the book is a little dated, it is all about network economies and their similarities to ecological systems, and I realized that evolution is at work when it comes to platform adoption. Greater than 90% of desktops run Windows, so there's no variety in the PC platform genepool. Just like inbred populations, this PC pool is unhealthy: it can't adapt and infections run rampant because all specimens are susceptible to the same illnesses.
Of course, who's going to change to another platform when there's no software out there? (No flames please - try to remember perception is everything, and ask yourself whether an average user realizes alternatives exist.) Virtualization, I think, is a good answer to this. I like the idea of "booting" to an application like in the pre-DOS days, and if your games run no x86/x64 architecture, you could bypass the OS altogether to get the most out of games by just booting straight into Halo 4 or HalfLife 3. I also like the end of the API: we can go back to the days of static linked libraries (no version conflicts, ever!) and headers and just build our own OSes from scratch to run in a VM. Since you can virtualize anything, even VMs, you can get cross-platform apps and cross-platform platforms (Java, .NET, etc.) and consumers don't have to worry about physical hardware or their underlying OS components, apart from cost and performance considerations. As far as their apps go, everything could, theoretically, work the same on any system (whether business decisions will allow this to happen, we'll just have to see). In fact, my only worry about this is how to allow for a standard GUI on such a system (but since nobody, not even Microsoft, follows GUI principles these days anyway, it probably doesn't matter).
This is, IMO, a far superior way to do things than how they're done now. So, okay, then, OSS community, please get to work so you will be finished before MS is. Thank you.
dang. you beat me to it :)
Everybody gives Majora's Mask such a hard time too. I admit it could have been better. That fish guy you play who's also a rock star? That was dumb. And it seemed short with only four real dungeons, but it was a good game. Those dungeons are about 3 times as big as the ones in OoT, so only 4 is really like 10 or 12 dungeons in OoT (and there are quite a few mini-dungeons on top of that). The idea of having 3 "days" to beat the game or start over -- that was pressure... especially that very first day in Clock Town. Now that you mention it, I do wish they had a hard mode like they do in Shadow of the Colossus. I played OoT: Master Quest, but it was only tougher puzzles and most of them didn't make any sense. I want to fight somebody that can fight back, not shoot a slingshot at a cow in a wall. I don't get it.
Not in my book. I'm playing CoD2 in Veteran mode. 3-4 shots from small round (Luger, MP40) = death. 1-2 shots from larger rounds (rifles, MP44, MG-42) = death. 1 anti-tank (rocket, 88mm, etc.) or a head shot = death. Makes you think twice about poking your head out from cover. And no quicksave in that game :)