If homosexuality is a choice then hetrosexuality is a choice. Inform us please, as to the exact nature, date, and composition of your choice.
Also, as per your thesis statement, "There are the homosexuals, there are the homophobes and there are those who don't really care", your demonstrate interest enough to propose a position, and you aledge hetrosexuality, so which of your three classes are you left to occupy? [cheap shot but it had to be done... 8-)]
In point of fact homosexuality is not "exactly tht kind of gene that would be weeded out" (etc) because of "kin selection" [look it up]. The existence of a non-breeding sibling in social animals increases the probability of survival of the offspring of the breeding sibling(s) by correcting the ratio of providers-and-protectors over ofspring.
The trait becomes useless if it exceeds a small but persistent percentage of the population. So that 6-to-10 percent gay ratio works out about right.
Taking a simple model (numbers from the top of the head, not a "real" source). If each adult can bring two children to adulthood, then a couple can bring four to adult hood. A non-breeding sibling brings the number to six. but one out of 10 will be non-breeding so a hetrosexual-only population will outperform in the long run.
BUT...
Stress the population (war, dificult hunting, bad economy) so that each adult looses say ten percent of their child-rearing contribution. Their reduced net output is 3.6. Then a hetrosexual couple only raises three children to adult hood (the.6 for the last child isn't enough because you can't have eight-tenths of a surviving child). The couple with the additional gay sibling has an output of 5.4 adults. In two such generations, with a 10% non-breeding (gay) rate, the non-breeding gene nets one more breeding adult (you loose one of the ten to being gay, in particular you are presumed to luck-into that gay sibling in the first decendent generation, but you get the more-than two or more-than-three 8-).
The numbers work out more evenly for larger groups such as tribes and extended familes as the above rounds off inexcusaibly.
In times of hardship, and indeed in any time other than that of abundance, Kin Selection, in a stable breeding population ("enough" adults to start with, whatever enough means in the context) the occasional extra provider and care-giver will cause the wiht-the-gay-gene population to croud out the withouts.
In smaller (less-stable) populations where there are "not enough" adults everybody *must* breed to keep the population near stable. There is a good argument for this being the root requirement in Jewish (and hence Christian) tradition that all men must marry. The earily tribesmen/practitioners were woefully out numbered so they needed the short-term enforced breeding.
So, if you have the gene in their you get better population growth in lean years when there are plenty of adults, and when there arn't plenty of adults you add the social stigma/requirement so that you keep even.
So the combination of the gene and the prohibition are nearly unbeatable for maintaining the gene in the population.
Actually there is a persuasive argument for Homosexuality, or at least the capacity for homosexuality, as a genetic trait.
The fundamental mechanism is called "Kin Selection". By raising the ratio of adults over children you increase the probability that the children will survive. Given a competitive group of consumers, such as two families or tribes hunting and gathering from the same range, as the pickings get thinner the family with the larger number of providers is more likely to be able to provide for a given number of children.
The same features go for safety issues (waging war, fleeing disaster).
Even more so, should I attract an adult same-sex partner to my family for the cost of raising one child to adult my family gets two adult providers/protectors.
In terms of the choice-or-not question, I'd say "not choice" but also "not deterministic". Most of the people who weigh in on the issue only consider their own perspective and then presume that everyone else is the same deep down inside. This is why gay people often give bisexuals a ration of crap because the gay person may have _claimed_ bisexuality as a social buffer so then they presume that all persons who claim bisexuality "are just fooling themselves with denial." This is turn is as much crap as the straight guy knowing that "gay stuff is gross and would be an awful lot of effort so gay people are doing it on purpose."
When you set the invective aside and take an honest real-world look, I'd say that there are three set-levels in the brain. Opposite-sex attraction, same-sex attraction, and overall libido. I think each person is born with a sort of probable maximum for each of these levels as a genetic feature. _Then_ life circumstance and learning let/make the person realize some actual level for each of those set-levels. People who exclusively have same-sex or only have opposite-sex are simply predestined, those who have non-trivial potential in both _could_ go either way or both.
It is obvious to straight-only people that there was virtually no way for them to have been raised gay.
It is equally obvious to gay-only people that there was virtually no way for them to have been raised straight.
Why neither group has been able to recognize this truth about the other group is beyond me.
On the third hand, the some-of-each group, when raised "too straight" or "to gay" (or not 8-) get all convinced that _everyone_ ought to be able to chose the way they did Because That's How It Works(tm), and you get either Ex-Gays, Fundy Homophobe Ministers, or aggressive "every straight boy is really gay too" jerk-offs.
If everybody involved would really come to understand that other people are really and actually different inside their heads, the whole question would be self-answering and moot.
If the system in quesiton (e.g. windows, linux, whatever) had a "recondition" call, that would return an executable pointer/handle/whatever given a data pointer/handle/whtever. And _if_ that call were smart enougt to _never_ convert suspect pointers/handles. Then most buffer-overrun exploits would be impossible.
Consider (vapid psudo-code):
Ptr = SpecialMalloc(size,MMU_CONVERTABLE_LATER); if (JIT(SourceBuffer,PTR)) {
FcntPtr = DataToCode(Ptr);
if (FcntPtr) (*FcntPtr)(); }
Now is this completely unexploitable? Probably not, but probably _damn_ close if the only thing exploit can do is overrun the return area of the stack.
Now add on the "potential fact" (e.g. make the design decision) that if the DataToCode() function is only available if it is linked in to the program in the first place (or the executable is flagged in a particular way etc), and the door to bogus-stack-return-call-pathing is shut for virtually all programs that didn't start life as JIT compilers anyway.
The ibid for runtime linking is similar but tricker. I'll leave it largely as an exercise.
The "trick" to closing off the stack fidigeting attack would actually be in constraining the calling conventions. For possible instance, if DataToCode() *ONLY* takes arguments from the stack and SpecialMalloc() *ONLY* returns values in registers (or whatever), that is, as long as the communication between the two parts requries something more than a forth-like sequence of crafted library invocations, you raise the bar to a virtually impossible height.
To whit, the buffer overrun would have to be into a buffer that was already know to have been specially allocated, OR there would have to be coincidentally existing code stream at a well-known static location in the executable that would allocate a special buffer, copy the overran buffer into the special buffer, and then convert and execute that buffer. Not impossible but highly unlikely.
Meanwhile, what is the burden to the JIT compiler writer? Two syscall-equivelants and the restriction that you may only use heap buffers allocated in a spesific way. Neither of these costs are prohibitive.
To the dynamic linker question again, the prohibitions would end up being something like only being able to convert read-only mapped regions of otherwise-identifiably-executable files. (e.g. execute-bit set on *NIX,.exe or.dll etc on windows, and so forth). Since you don't want your shared libraries opened for writing anyway, and the ELR/.DLL-esque files are already going to need special handling anyway, these restrinctions are hardly onerous.
See, nothing lost, expenses quite trivial, protections quite significant and remaining exposure very small.
The *very* *first* thing a virus has to do, before it can 'modify the EXE on the disk', is get itself into memory and run. If the virus cannot get itself run in the first place, then it can't ever modify the EXEs.
The only ways a virus can get itself run involve exploiting human stupidity or flaws in already running code.
Of the "flaws in running code" there are essentially two variants. The first is the route where the program in question is *designed* to run arbitrary code, and obviously that isn't going to be affected by the NX bit.
The second exploit is the rampant data handling flaw where data that happens to be a code image is crafted into memory and then the flow-of-control of the exploited program is coerced into executing that data. This is the vector that liberal application of NX closes off.
So... (class...?) if you stop the initial intrusion of the virus you block the virus before its reproductive stage.
So with all the no-duh out of the way...
The "classic vrius" acutally *did* modify executable code in memory all the time. In particular the DOS/earily-Windows viruses "usually" patched the command.com exe-loader to re-write the EXE files when they were opened for use. That is, the classic virus (as opposed ot the modern "virus" that really just installes itself) couldn't afford to just modify every program on the disk (which could take unbounded time and data) so it only attacked the programs you used by inserting itself when an uninfected program was launched. It just used the open facilities of the loader to manipulate the file in question. This increased the probability of infecting common programs while never having to include the file-handle management code implicit in doing directory searches and explicit in decoding the EXE header.
Of course, part of the reason that modern windows viruses are so easy to write is that windows already "includes" all the file management code (and communication code, and memory management etc) "for free" to every single executing entity, so the viral payload no longer has to be very tight to remain small enough to be effective.
Further, if the system then *implements* the various memory management options such that no block of memory is ever writeable if it is executable (and vice versa), the most common method of modifying existing executables (by mapping the files into memory and modifying them) could be "greatly reduced". No, not eleminated, but reduced. Consider how much narrower the vulnerabilities of a windows system would be if the windows core facilities that manage and manipulate EXEs were "quite resistent" to ever letting an executable file (.exe,.dll,.cpl,.fot, etc ad nausium) be opened or mapped for writing?
Don't mistake my position. I don't beleive that NX is some sort of miriacle. It's another useful tool in the box. The fact that windows is completely unprepared to leverage the technology is problematic. But if used properly it could be a huge help with actuall viruses.
The "real virus problem" is, however, dwarfed into obscurity by the flawed programs and human stupidity problems. But those arn't, strictly speaking, tied to the word "virus".
I know it is, but as it is being discussed in the surrounding articles as (virtually pure) buffer overrun protection, that distinction isn't obvious.
You need to remeber your audience, and acknowledge that the other participants are trying to be aware of the audience as well, before you make your little dismissive quips...
You presume much, like that I *recommend* removing/usr/bin. I am just talking about how the proposed system would effectively work.
It's easy to gain-say things wihtout being at all spesific, and you have done so.
How exactly is making the *NIX system's command presentation self-assembling based on the installed packages "a humongous step backward"? (Since it _NEVER_ did that before, it would, at most be a "humongous" step in the wrong direction in your humble opinion.)
How exactly is making the common system areas self-correcting and agressively consistent with the installed base "[making] Unix Not Worth Using Any More"?
The facts are simple. If the core of the system facilities presented in the system directories like/usr/bin is *supposed* to be the set of all properly installed facilities, why is it bad to compose directories like/usr/bin based on a survey of the installed packages?
Nothing in this prevents or usurps the ability to add packages, nor simple programs placed in well defined common searchable directories. (Hence the/usr/local/bin psudo-standard where non-system programs that arn't supposed to mix into/usr/bin are supposed to go anyway).
The system is supposed to be extensible and functional, nowhere is it desireable for the system to become "Littered With Crap Of Dubious And Untracable Origin, Liberally Mixed With Leftovers From Improper Upgrades And Incomplete Uninstalls."
Because we all know *NIXis only worth using if you can have bogus random executables from old, spurious, and known compromised software left around to make a mess. [Anybody who has ever dealt with a conflicing install where/bin/sbin/usr/bin and/usr/sbin all have different versions of some command X in them, knows the joys of garbage-filled system directory.]
And _HOW_ can a reasonable person (as I will momentarily presume you to be) state that a tool that keeps common facilities consistent for all users and subsystems be biased towards "Unix for a single-user PC" exactly? Consistency, predictability, and lack-of-mysterious-binaries is *more* important in a Shared or Service-Providing installation than it would *EVER* be in a single-user system.
Do you have no grounding what so ever in fault tollerance? How about system recovery? Planned maintenance? Contractually guaranteed/limited down time? Package Migration? System certification? Compartmentalized testing? System Assurance?
Aparently you have no real understanding of how significantly useful it would be to be able to audit individual packages on a system and then "know with certanty" that when a package was removed or replaced, that the old package was completely removed and the new package was completely instanciated.
Do you not understand at all why Windows, poluted as it is with arbitrarily versioned multiple copies of the same DLL in directories all over the box is "bad", and how "uninstalling" a package and having it leave config files and dlls all over the box is _worse_?
In the same way that adding modules to the kernel using a consistent interface is good, having application groups and subsystems added to the whole computer as consistent modules would be good.
Nobody is trying to take your toys and leave.
I'm talking about being able to make CONSISTENT, CONTAINABLE, and REVERSABLE maintence of the *NIX system practical and "reasonably priced" in performance and administrative effort.
That you apparently find the "toss everything in the sandbox and lets play" aproach (we currently have) as looking forward paints you as the toy-system advocate here.
Given that, in common parlance, most people don't know the differences between the various exploits "virus" is as good a word as any.
And if the NX bit were used for more than the stack, then it could protect against a lot of (non-trojan) viral activity too.
Lets face it most viruses today aren't even viruses. They are trojans, worms, and human-engeneering exploits. How often do you see an actual virus? You know a program that writes its code into another program. It's actually getting kind of rare. Now days it is whole applications delivering themselves to your computer through email and exploiting the existing code of crap like IE and Outlook by just telling those programs to run the evil code. Most exploits today are applets and packages.
All But Gone are the days of rewritten exe headers wiht appended code fragments, and programs appending themselves to other programs in memory.
Quite frankly if all the non-code memory regions in my computer were non-execute down to the very last GDI region and printer buffer, the classic virus would be dead. The IE hacks and the trojans and the worms would still be here because certian stupid programs will do arbitrarily complex things at the behest of remote entities, but that isn't a virus. Thats bad design comming home to roost.
Yes, there are reasons that people don't want to reboot a production server. I ahve operated and then administrated production machines in varios settings since the mid seventies. I've worked five-nines government contracts. I know about down time.
No, you don't "have to reboot to execute something from a removable media."
You reboot when you want to fundimentally replace a package. (And maybe not even then if the facility were written correctly and had the necessary tools to determine that a full reboot weren't necessary and a hot recomposition could be performed.)
[note: all version nubmers chosen arbitrarily, as example, not to reference existing verions particularly]
The core idea is that what we think of today as the backbone of *NIX is a static pile of doo-doo that gets poluted too easily. If, instead, everything were safely ensconsed in it own directory and "properly documented" its own dependencies to the outside world via a parseable file full of directives. (e.g. a file that said "needs binutils, needs fileutils 2.8" etc) it would be easy for a tool to "compose" things like/etc and/bin and/lib (completely out of symlinks and bind mounts, e.g. no copying and no duplication) to satisfy those dependencies.
The most obvious time to do this (and the one time it is mandatory) is during reboot. Reboot is also ideal to prevent the race condition where, lets say, you were replacing binutils 2.10 with 2.30 and you didn't want to worry about the mixing the output of both because someone was compiling just when you made the change.
The first version of this facility would certianly be reboot-centric. See my other comment(s) in this thread for a longer example of the possiblities including things like MakePrivateRoot as a chroot-like command that compose-and-chroot-and-exec(s) a process in its own limited and custom environment. (yes, it would be expensive, but the fact that it would be possible is significant.)
What the system and the/etc directory have in common should be fairly obvious. My intent is obliterate/etc as a static entity. Most packages should have their own configurations instead of bonus directories in/etc. So when you put in SSH version 2.2 the entirity of the ssh, config and all, would be in/apps/ssh/2.2 (so/apps/ssh/2.2/config). Of course, some things [like SSH oddly enough 8-)] might rank "config packages" to share the config between versions. Sounds unnecessarily complicated until SSH 11 comes along and has incompatable configs to prior versions. When you started up --with-ssh-11 your _effective_/etc/ssh would be composed from one sourece, when --with-ssh-2 your _effective_/etc/ssh would be from somewhere else completely. This would be controled by the dependency files/language. And so forth.
Dont think about this statically. The static and pollutable/etc and/bin are the essential problem. If these directories were composed into existence at each boot from disparate persistent sources based entirely on dependency requirements, then they couldn't get polluted over time because they would regularly be recreated from whole cloth.
The point about the removable devices is different. It's not a limit, its a feature. In a situation where machines are loaned-out to individuals (as in computer labs at schools, and cyber caffes) it is _normal_ for people to lug in whole drives full of their own work and plug in. If the core system was set up to compose-in-at-boot the external drive, while the core packages and configs were frozen on a read-only drive [think read-only via jumpers not permissions], then the core machines woudl be "automatically customized" by the portable media, but they coudln't ever be "compromised" by them. So the school in question provides the base machine and the 20 or so pac
You, indeed, don't see. You are thinking to statically.
There would be nothing in/usr/bin of any consequence. In fact if you were to do a "rm -rf/usr/bin/*" (or whatever) and then reboot, the runtime composer would build the "correct" contents for the directories from the "real" package locations. The same thing would happen if you went in and deleted the package directory with a simple rm.
That is, the use directories in the running system would "always" be built on demand.
The programs themsleves, along with thier supporting data and configurations would each live in their own private arenas, completely separated from their peers.
Now the common use directories would only even need to exsist to accomodate the casual owner, and the real programs would be in their priavte areas for more spesific uses.
Think about it from the other direction. (this is not a _practical_ example) Start with a tree of directories like/app/lib/glibc/{version_number,...} with no/etc/ld.so.conf or/etc/ld.so.cache. you would have/app/lib/glibc/XX/ld.so.(conf,cache). The very act of compiling applicaitons with a gcc that was set up to use the version-spesific/app/lib/glibc/xx/lib/ld-linux.so loader decouples the resulting executable from/lib/usr/lib and/etc/ld.so.*. (I do this on a current product where I have/alt/3.4 and/alt/2.95.3 to support some things with gcc build preferences and library versions.)
Now extrapolate that. Imagine a system where there is a not-really-root directory tree containing nothing but package and package group directories and a composer program. There is another not-really-root directory tree with the per-user stuff that we think of as/home. When "off", the computer doesn't have any storage media anywhere on it with/bin/usr/bin/lib/usr/lib/etc or/home or anthing that we currently consider to be central to a linux system.
At power on, rather than running "init" (or as init if you like) the composer is invoked. The system not-really-root is mounted and a TMPFS is mounted. The TMPFS is filled, populated with the aggregate runtime "composed" from the current configuration and available packages. This includes the bound-mounts of configuration data, and user data directories, and the composition of the startup scripts (a-la/etc/rc.d) and the selective inclusion of just about anything else needed.
Then you rotate that TMPFS in as the real root and exec the init program in that context.
Now, that takes a bunch of time. So take the theoretical TMPFS-based version and cache it in a regular file system. You still have to do the bind-mounts but you only have to recompse a directory like/bin (or whatever) if the first pass of the composer decides that something actually needs recomposition.
Next, non-permiscuous environments can easily be created (for things like chroot-ed rsh sessions etc) because the programs "really aren't" co-mingled to begin with. The "typical"/usr/bin doesn't really have anything in it but a bunch of references to the real home of whatever.
Consider, then, upgrading something like your binutils. Your current set of commands lives in/apps/binutils-2.10, you make a the new binutils in/apps/binutils/2.12 (yes, it deliberately doesn't matter that the names are not strictly orthogonal.) All of the config files point point inside the acutal/apps/watever/... directory for each version. [that is, the config files don't say/lib/whatever, they say/apps/binutils/2.12/lib/whatever and so forth] The magic is tha
I'd rather like to see (and have done some trivial work on creating) a system where the entirity of each application program/suite/whatever is put in a separate directory all under a particular root (like/opt). At each start-up a "runtime composer" goes in a stats the root. If it has been updated since the composition flag file, then the composer gives a real run at building the system directories out of the application suite directories.
The tricky part is to have a dependency language or something, so that the startup ordering and run-level preferences can be figured out. Its not insurmountable but it is non-trivial.
So anyway, packages that don't have all the requsite dependencies installed are "factored out" and a new bin and lib and etc directory is built out with simlinks and such. (Basically remove *all* the symlinks from the composed directory that don't point to things in the composed config, then add the missing links, which is a completely functional set-theory operation.)
Anyway, you get the "better parts" of an installer scheme with a "remove that directory" uninstall semantic. Installations are just an "un-tar and reboot".
One of the features that could be included are searching removable media (thumb drives) for packages that are to factor in to the currently composed runtime. Conser things like a read-only drive with the core system and the thumb-drive inclusion so that people (think students at school and cyber-cafes) with their own personality media could reuse interchangable core systems.
The big problems I see are:
Whining from the "must boot faster" crowd. Whining from the "shouldn't have to reboot to install" crowd. Needing a well designed dependency language and parser. The security model needs some tweaking in general to allow for non-priviliged packages to be used in non-priviliged ways.
The system is fairly simple once you get away from thinking that UNIX's usage of/etc was godhead.
The actual ideal is to have the root file system be a tmpfs (etc) where you would build the core directory structure at each boot. Using "mount --bind", symlinks, and a tiny semantic initialization block (e.g. to make/tmp,/proc,/sys,/dev and/dev/hd??) you should be able to compose a complete environment very fast.
You could even pass kernel version, boot media and/or a few other things (like invocation parameters and language choice) into the composer script to potentially have a completely different effective root for any number of variant purposes. For instance a kernel developer could have a root template for "normal use" and for "testing the new build" on the same machine. Generic constructs like --no-packagename would exclude particular packages at boot time. That sort of thing.
Basically we need to "throw off the opressive chains of having one statically preconfigured/etc directory."/etc is the Achilles Heel of every *NIX system.
Why in the name of all that's holly, is it "insightful" that this guy mentions the latest shiny-object world-heart-bleeding destraction as an (implicitly) good reason to ignore the future?
What is being done there is admirable, what is being done elsewhere to directly help those there is worthwhile.
What is being EXPLOITED there by our self-important media and then LANGUISHED over by all the hand-wringers and tragedy-borrowers is DISPICABLE.
Look! Misery on TV! Get the popcorn and screw the future!.
Makes me want to puke.
Death and distruction is not a spectator sport and those who treat it like one are consigned to a very special level of LIMBO. Not even hell for you folks. Limbo. All you get is a CNN News Ticker that repeats every moment of pain you borrowed from people all over the world while the main picture is a continuous loop of the speaches of every politition you ever voted for, and a window to exit limbo can be opened if you can spot the truth behind the invective while feeling a genuine emotion. You'll never escape.
This is your doom you slugs...
(The author above *may* have just been making the point that the world populace is too easily destracted whenever the opertunity to "safely feel horror" comes along. Maybe. So maybe all the "hear hear" replies below deserve the diatribe. But crossing the one issue with the other here in this forum is blame enough to deserve a mod-point butt-kicking.)
It is *SAD* that you imagine that somehow people can only think about and care about one thing at a time. Your statement seems to imply that it is bad in this next destracting "time" of emergency and human suffering, for anybody to pay attention to the future of anything.
That's stupid.
One can, and a reasonable person should, give creedence to what is important, but never to the exclusion of what *else* is important.
Quite frankly, no matter how much coverage is given to the flooding and such, there is not one useful action that will be brought about by lament. It's not like there is just one eye and one heart functioning on the entire planet. That each shiny bright tradegy can derail people from seeing to the business of the future is _galling_.
Oooohhh can't protect our civil liberties, some people died. Can't watch out for the economic interests of the world, some more people died.
The rampant drive of some persons to _memorialize_ the misfortune of strangers at the expense of reasonable attention to every other aspect of life is disheartening.
Suffer On Polly, but don't expect the world to stop so that you have time to mourn strangers and slave your bleeding heart. The people on the secene are working to fix what can be fixed and salvage what can be salvaged. The people disposed to act are acting, and relief is on the way.
But the rest of the world isn't supposed to stop and stare while the nefarious and bull-headed make off with the future.
Don't be a lookie-lou. Stop slowing down for every road-side accident. Act, or don't act, but stop telling everybody else to stop.
This isn't a contest for "biggest heart on the prarie".
It's _SAD_ that nobody remembers things like Michael Jordan's comback. 2500 dead people, while tragic, *SHOULDN'T* have undermined the entire functioning of our society. That it *DID* is what is behind all those "the terrorists won" comments you have been failing to process.
So there was a wave in the ocean, and people died, why _precisely_ is that supposed to mean that we shoudln't pay attention to the United States' ongoing war to economically ruin other countries software industries?
Part of having some perspective is knowing when _not_ to be destracted just because you can empathize.
Its like all the memorials that pop up whenever anything hits the news. A cop is shot in Newcastle WA, hundereds of people show up to lay flowers on the sceen. Maybe fifteen of these people knew the guy. WTF? All those people "traumatized" over the death of Princess Di. WTF again? It's not that hard to understand.
Bad things happen all the time. People die all the time. How many people have been "clensed" in Africa in the last month? How many have died of AIDS there in the last year? Why don't you know? But the splashy (forgive the pun) images on TV have you all a-twitter and you watch the death-toll like a sporting event, with each count on the big board being another chance to wring your hands and suffer along with the rest of the audience.
It's sick.
I am deathly ill over your "happiness" that the world "isn't" paying attntion to patents now that it has a shiny death-match to watch on TV. It's short sighted and dispicable of you.
The crossection of the world that wants to bleed over every single pinprick is literally killing the rest of us.
Well, they wanted a chunk of our economy, and we wanted to make sure we didn't ship all of our money over there in terms of off-shoring. Now "everybody wins".
The economic colonialism of the US will "take back India for the West" and while tomorrow is India, we may get the rest of the world sometime shortly there after... if not for Poland... 8-)
The facts are simple, countries can sell off their economic future for small cash bribes today, and they seem willing to do so. They _believe_, because they were told, that these software patents are how the US got our IT industry. That belief needs must be cold comfort in the years ahead.
You can't really blame the US or its most important corporate citizens. They understand at a visceral level that the "software patent" is a huge mistake, but their two choices are to admit that the money spent so far needs to be tossed out and the software patent regime overturned OR they have to get the rest of the world to make the same mistake to re-level the playing field. The patents represent tangible power so they are unwilling to un-make the mistake, and instead have, by anonymous consent, decided that the best bet is make sure the rest of the world is equally plagued.
I am put in mind of the monkey trap. You build a box that a monkey can barely put its hand into, then put a nut in the box, the monkey reaches in and grabs the nut and then cannot get its nut-filled fist back out of the hole. The monkey could be free if it just let go of the nut, but it is biologically incapable of doing that. Its instincts are not wired up to sacrifice the nut to save its life. Its a short-comming in the whole essence of monkey-hood.
In our scenario, the companies are the monkeys, the law and its trappings are the box, software patents are the nut. Unfortunately the "IP Holding Company" is the guy with the gun who is coming to shoot the monkey dead if the monkey doesn't just starve to death first.
We have these other countries just begging for us to tell them how to put nuts in their boxes, and for no apparent reason too boot.
If you let the stupid people here get away with it...
Let's face it, the whole problem disapears if there is an option where the start-time of a later program interrupts an earlier one.
I have run into this on several (older) PVR products/projects like the ATI PVR for the Radeon/Radeon Pro All-In-Wonder and media center. It would "miss" a later program because it couldn't switch over to it while it was cleaning up an earlier one. So an hour at 9 couldn't be recorded if you just recorded an hour at 8.
It's not that hard to see that you have to switch, wind up what you've got going, and then start the new thing and just be as fast as possible to minimize loss.
If I chose a show that runs from 8:00 to 9:02 and another that runs from 9:00 to 10:02 then It shoudl be "unacceptable" for the second one to just get dropped. Either the recording shoudl start two minutes late, or the first show should be cut off by two minutes (as my choice).
A reference as to the issues of placing a multiple generation farm onto the grid.
http://library.abb.com/GLOBAL/SCOT/SCOT289.nsf/V er ityDisplay/29D24AC36EEACC6A85256D2E003F2E6E/$File/ WindPanelPaperPart2.pdf
Granted, with wind, the rate-of-change and frequency-of-change is more substantial compared to the sterling engine system (just because of persistence of heat compared to wind etc).
This was found with a quick google, so it may be less than perfect as a reference.
But section III-B sounds very like the power profiling issues that the solar generation system guy was describing.
===
Again, defaulting to what we have learned from wind power.
http://www.nrel.gov/docs/fy00osti/28409.pdf
"There is a concern that distributed generation must trip off-line quickly when the substation feeder breaker opens to clear a fault on the distribution line. If the generation doesn't trip off before the feeder breaker recloses, then it could cause damage to the distributed generation in some cases. The length of time allowed for a wind turbine to detect the resulting loss of the grid and then trip off is short; it may be an issue for some types of large wind turbines. There is also a concern that if the substation feeder breaker opens with no fault on the line, then the distributed generation must also trip off to avoid creating an "island" served by the distributed generation. This could possibly require some protective relaying functions to be added to wind turbines that are connected to distribution feeders. Generally, a wind turbine would trip off line if the substation breaker opens, but it is possible that it might not trip within a few seconds."
So the relevant standards (as they emerge) are pretty much going to require that these power sources be self-isolating. And you arn't going to want to re-pay the startup current costs after a trip, nor are you going to want to lose the power generated during a falt. That says "intermediate stage with storage media" to me. The referenced paper also briefly touches on stability requirements and sync/sourcing.
===
On the issue of your degree. Arguing to authority. (and almost certianly outside of your field of expertise, since I didn't hear you calaiming to have built (been involved in building) a 20,000-independent-unit sync-alt generation station.)
===
The capacitors you seem to feel I have "magical faith" in, in _my_ head don't have a meaningful inductive impact on the grid as I am proposing them as a power resivour _behind_ the inverters that would then drive the power out onto the grid. Once you propose/introduce that level of isolation you gain a degree of freedom in the method and particulars of the individual generators.
Actually, _you_ should read the article. The small units will have the sync-alts, but when the farm gets to their target size they hope to get on the long distance grid at the very-high voltages.
"From 2007 to 2010, the program proposes mass-producing dishes to create a 20,000-dish farm supplying 230,000 V of long-haul power from its own substation directly connected to the grid."
This was the point at which the whole rising power thing becomes an issue in terms of a sustained, steadily increasing supply.
But at this point they also have the 10-amps for a few seconds cost per unit to come online.
Plus the "electronics" arn't going to effectively be able to put power onto the grid until the station has got a little head. Besides, there is no way in hell you want to have 20,000 sync-alt generators directly connected to the grid in one place. So the station is going to have to come up and stabalize itself anyway, just like _every_ _other_ non-trivial power source on the grid.
So the one problem solves (could solve) the other.
Bring the first dishes on-sun and power the second and subsequent through their startup (for large values of first and second 8-), the system comes online while off the grid, more-or-less as fast as possible, then cuts in just like a regular plant.
Yes there will be these mysterious electronics of which you speak and my poor caveman brain can hardly comprehend... But they are going to need a big ass bank of capacitors in there somewhere to get themsleves up to operating voltages and menaingful power levels. Elsewise the system couldn't meaningfully participate on (and protect itself from etc) the long-haul grid, and they'd be stuck at six-and-forty (dishes-to-houses 8-).
Among other things, they probably *wont* use sync-alts bare to the grid because of the reactive power that would soak up. (That would twenty _thousand_ field coil groups!) (e.g. the wind-farm delema). Were I to bet I'd bet on a farm of single independent generators or small clusters of same, near-term rectifiers "just before" a mighty bank of capacitors, and then the step-up electronics to drive the power from the capacitors onto the grid. There wouldn't be that much heating or loss either since, overall, the voltage and current profiles of the "ready" bank would remain relatively constant over any 10 second period so without much flux(*) there wouldn't be that much heat. (* yes, many caveats apply, but not in this forum. 8-)
Being hungry for every watt isn't the same as being able or willing to soak up "bad" power. And given the startup amperage, even in batches of a few milliseconds, 20,000 times is not a neighborly thing to do.
"In the crapper" and "Runs once out of ten tries" are "quality standards" just not excessively hard to achieve.
Yea, that sounds funny, but I am not joking. If you have ever worked with government or mission critical systems you know that there are whole ranges of "quality standards" that properly hinge on all sorts of factors and properly "only go so far".
You have been conditioned to see those two words and automagically think nine-nines-of-uptime or zero-errors or whatever. But those words are _MEANINGLESS_.
The article and the proposal is a bunch of Market Speak.
In point of fact each program/project/routine has some (possibly unspoken) quality standard to which it is being crafted. And the web site/company in question is also being crafted to the PHB set.
The questions really are:
1) does this organizatino propose quality requirements that are more-exacting than the Open Software systems they expect to sell and support, and if so, will they be spending the time and money to raise those projects/programs to those standards or will they just bitch in some mailing list?
1a) Aproach? 1b) Participation? 1c) Remedies?
2) Is this just pandering to control-freakery or does the group in question have a participation model in mind? Does that model presage a "we (you people) need a licensing organization (us) to certify you as good open source"?
3) What resources is this organization/company expecting to "plunder" in their start-up period? Given that they don't list products and projects, they clearly don't plan to hire a group of experts before setting up shop. This infers that they will either shovel a lot of very fluid finincials in different directions at the drop of a dime; or serve up stock distributions with their sticker on them; or they plan to try to coerce the OS bug tracking and review process. In the latter case they probably have no idea about how little power random people have in coercing OS workers into individual agendas.
So far, my vote is, "no, we don't need you to come in and try to lubricate OS, it's working fine without your vision and you'll just give it a bad name once you finish fleecing your dupes."
The problem is, somewhat simply, that the "workspaces" to which you refer are not a feature of the X windows service. They are a feature of the window manager you have chosen to use. The "workspaceness" is acheived by realizing and unrealizing (showing and hiding) and moving windows about on the screen.
The DISPLAY value only has "server" and "screen" sections. So there is no way to communicate this "workspace" to the application.
You start an application on the _SCREEN_, that being the only screen you likely have. When the window is finally realized your window manager assigns it to the "active workspace" because that is the one that is active when the window "finally arrives."
So you have a bad case of operator impatience, and the workspace feature is so nicely and seamlessly presented by your window manager that you have been led to beleive it is a facility as opposed to a visual convention. Good for your programmer.
An exceptional window manager (note, not "application" as in Mozilla or Word or Open Office, but window manager as in KDE-WM of Gnome-WM or Motif or whatever) might be able to be configured to "know" that you want a given application to show up in a given "workspace". [e.g. like Hydravision(tm) for ATI addapters in Windows(tm).]
The problem is one of disconnect.
You click on an icon to start an application and the fork-and-exec take place and things are off and running. You switch "workspaces" but the application may not even have gotten around to calling the init routine for the X library yet, let alone contacting the display server and allocating a top-level (if invisible) window. There is no way for the window manager (or X) to associate the application that is "just connecting to the server" with the button-press of a few moments ago as the contexts are completely disjunct.
As an added example case, an application that will realize/show/"un-hide" itself in some circumstance may apear to skip around from "workspace" to workspace. Some window managers may be smart enough to take the realize-notification, see that it is for a window "on another workspace" and immediately un-realize the window before you see it or it really gets drawn.
But the virtual display surfaces you know as workspaces are just an illusion, so you really cannot blame arbitrary apps for "failing to work" with a particular (if useful and wholesome) smoke-and-mirror effect.
Hydro, it turns out, is not that great a deal. It does work, but most of the dams built in the last fifty years are nearly at the end of their lifecycle due to silting.
The envrionmental impacts are also more serious than originally thought.
The salmon issues here in the north-west UAS are bad enough, but without the regular release of non-trivial fractions of the flow at near-flood proportions lots of down-stream habatat just disapears.
One dam can stop 90% of the silt-flow of a river, which can improvish a heck of a lot of wetlands, cause rivers to "straighten" which increases the flash-flooding potential in down-stream areas, and which can fill the resivour with mud instead of water in fairly short order.
Hydro works, but it seriously needs to be re-thought if it is to be sustained.
Remembering that the actual heat isn't going very far, the cooling isn't *that* interesting.
We arn't reflecting the heat off into space (a la snow-cover), we are reflecting it to a heat sink about 20 feet off the ground.
The heat passes through that heat-sink and into the air. The air temprature will probably *rise* during the day because the ground isn't soaking it up _directly_. Any given square-inch of ground will be in shdow for about two extra hours a day per dish (wild-ass geuss from just looking at the thing) and will be subject to the shadows of three dishes max. So any given square inch will be "shaded" for half the day.
A good bit of that heat will get back into the ground anyway.
The net environmental impact would be about the same as for sparse tree cover (But without the water use and with a dissimilar habatat provision).
Soil water retention would go up just a tiny bit.
The most liekly impact woudl be changes in midle-size air masses within a range of about.5 to 2 times the size of the farm. The thermal might cast a rain shadow but not for more than twice (?) the length of the chord distance that the prevailing wind passes over the farm.
So worst case, (total wog again here) about the same climatological impact as if say one-third the same area were covered with "water that couldn't evaporate" or concrete sculptures of trees.
A similar area covered with buildings would probably be worse in general. It would be the classic "downtown effect" (where it is hotter downtown during the day and colder downtown at night).
Slashdot Mirror
If homosexuality is a choice then hetrosexuality is a choice. Inform us please, as to the exact nature, date, and composition of your choice.
.6 for the last child isn't enough because you can't have eight-tenths of a surviving child). The couple with the additional gay sibling has an output of 5.4 adults. In two such generations, with a 10% non-breeding (gay) rate, the non-breeding gene nets one more breeding adult (you loose one of the ten to being gay, in particular you are presumed to luck-into that gay sibling in the first decendent generation, but you get the more-than two or more-than-three 8-).
Also, as per your thesis statement, "There are the homosexuals, there are the homophobes and there are those who don't really care", your demonstrate interest enough to propose a position, and you aledge hetrosexuality, so which of your three classes are you left to occupy? [cheap shot but it had to be done... 8-)]
In point of fact homosexuality is not "exactly tht kind of gene that would be weeded out" (etc) because of "kin selection" [look it up]. The existence of a non-breeding sibling in social animals increases the probability of survival of the offspring of the breeding sibling(s) by correcting the ratio of providers-and-protectors over ofspring.
The trait becomes useless if it exceeds a small but persistent percentage of the population. So that 6-to-10 percent gay ratio works out about right.
Taking a simple model (numbers from the top of the head, not a "real" source). If each adult can bring two children to adulthood, then a couple can bring four to adult hood. A non-breeding sibling brings the number to six. but one out of 10 will be non-breeding so a hetrosexual-only population will outperform in the long run.
BUT...
Stress the population (war, dificult hunting, bad economy) so that each adult looses say ten percent of their child-rearing contribution. Their reduced net output is 3.6. Then a hetrosexual couple only raises three children to adult hood (the
The numbers work out more evenly for larger groups such as tribes and extended familes as the above rounds off inexcusaibly.
In times of hardship, and indeed in any time other than that of abundance, Kin Selection, in a stable breeding population ("enough" adults to start with, whatever enough means in the context) the occasional extra provider and care-giver will cause the wiht-the-gay-gene population to croud out the withouts.
In smaller (less-stable) populations where there are "not enough" adults everybody *must* breed to keep the population near stable. There is a good argument for this being the root requirement in Jewish (and hence Christian) tradition that all men must marry. The earily tribesmen/practitioners were woefully out numbered so they needed the short-term enforced breeding.
So, if you have the gene in their you get better population growth in lean years when there are plenty of adults, and when there arn't plenty of adults you add the social stigma/requirement so that you keep even.
So the combination of the gene and the prohibition are nearly unbeatable for maintaining the gene in the population.
Actually there is a persuasive argument for Homosexuality, or at least the capacity for homosexuality, as a genetic trait.
The fundamental mechanism is called "Kin Selection". By raising the ratio of adults over children you increase the probability that the children will survive. Given a competitive group of consumers, such as two families or tribes hunting and gathering from the same range, as the pickings get thinner the family with the larger number of providers is more likely to be able to provide for a given number of children.
The same features go for safety issues (waging war, fleeing disaster).
Even more so, should I attract an adult same-sex partner to my family for the cost of raising one child to adult my family gets two adult providers/protectors.
In terms of the choice-or-not question, I'd say "not choice" but also "not deterministic". Most of the people who weigh in on the issue only consider their own perspective and then presume that everyone else is the same deep down inside. This is why gay people often give bisexuals a ration of crap because the gay person may have _claimed_ bisexuality as a social buffer so then they presume that all persons who claim bisexuality "are just fooling themselves with denial." This is turn is as much crap as the straight guy knowing that "gay stuff is gross and would be an awful lot of effort so gay people are doing it on purpose."
When you set the invective aside and take an honest real-world look, I'd say that there are three set-levels in the brain. Opposite-sex attraction, same-sex attraction, and overall libido. I think each person is born with a sort of probable maximum for each of these levels as a genetic feature. _Then_ life circumstance and learning let/make the person realize some actual level for each of those set-levels. People who exclusively have same-sex or only have opposite-sex are simply predestined, those who have non-trivial potential in both _could_ go either way or both.
It is obvious to straight-only people that there was virtually no way for them to have been raised gay.
It is equally obvious to gay-only people that there was virtually no way for them to have been raised straight.
Why neither group has been able to recognize this truth about the other group is beyond me.
On the third hand, the some-of-each group, when raised "too straight" or "to gay" (or not 8-) get all convinced that _everyone_ ought to be able to chose the way they did Because That's How It Works(tm), and you get either Ex-Gays, Fundy Homophobe Ministers, or aggressive "every straight boy is really gay too" jerk-offs.
If everybody involved would really come to understand that other people are really and actually different inside their heads, the whole question would be self-answering and moot.
Unless, of course, the thief is simply hungry and was trying to steal your Pizza...
Not particularly difficult at all really.
.exe or .dll etc on windows, and so forth). Since you don't want your shared libraries opened for writing anyway, and the ELR/.DLL-esque files are already going to need special handling anyway, these restrinctions are hardly onerous.
If the system in quesiton (e.g. windows, linux, whatever) had a "recondition" call, that would return an executable pointer/handle/whatever given a data pointer/handle/whtever. And _if_ that call were smart enougt to _never_ convert suspect pointers/handles. Then most buffer-overrun exploits would be impossible.
Consider (vapid psudo-code):
Ptr = SpecialMalloc(size,MMU_CONVERTABLE_LATER);
if (JIT(SourceBuffer,PTR)) {
FcntPtr = DataToCode(Ptr);
if (FcntPtr) (*FcntPtr)();
}
Now is this completely unexploitable? Probably not, but probably _damn_ close if the only thing exploit can do is overrun the return area of the stack.
Now add on the "potential fact" (e.g. make the design decision) that if the DataToCode() function is only available if it is linked in to the program in the first place (or the executable is flagged in a particular way etc), and the door to bogus-stack-return-call-pathing is shut for virtually all programs that didn't start life as JIT compilers anyway.
The ibid for runtime linking is similar but tricker. I'll leave it largely as an exercise.
The "trick" to closing off the stack fidigeting attack would actually be in constraining the calling conventions. For possible instance, if DataToCode() *ONLY* takes arguments from the stack and SpecialMalloc() *ONLY* returns values in registers (or whatever), that is, as long as the communication between the two parts requries something more than a forth-like sequence of crafted library invocations, you raise the bar to a virtually impossible height.
To whit, the buffer overrun would have to be into a buffer that was already know to have been specially allocated, OR there would have to be coincidentally existing code stream at a well-known static location in the executable that would allocate a special buffer, copy the overran buffer into the special buffer, and then convert and execute that buffer. Not impossible but highly unlikely.
Meanwhile, what is the burden to the JIT compiler writer? Two syscall-equivelants and the restriction that you may only use heap buffers allocated in a spesific way. Neither of these costs are prohibitive.
To the dynamic linker question again, the prohibitions would end up being something like only being able to convert read-only mapped regions of otherwise-identifiably-executable files. (e.g. execute-bit set on *NIX,
See, nothing lost, expenses quite trivial, protections quite significant and remaining exposure very small.
Everything would work rather handily.
"How I Figure"...
.dll, .cpl, .fot, etc ad nausium) be opened or mapped for writing?
The *very* *first* thing a virus has to do, before it can 'modify the EXE on the disk', is get itself into memory and run. If the virus cannot get itself run in the first place, then it can't ever modify the EXEs.
The only ways a virus can get itself run involve exploiting human stupidity or flaws in already running code.
Of the "flaws in running code" there are essentially two variants. The first is the route where the program in question is *designed* to run arbitrary code, and obviously that isn't going to be affected by the NX bit.
The second exploit is the rampant data handling flaw where data that happens to be a code image is crafted into memory and then the flow-of-control of the exploited program is coerced into executing that data. This is the vector that liberal application of NX closes off.
So... (class...?) if you stop the initial intrusion of the virus you block the virus before its reproductive stage.
So with all the no-duh out of the way...
The "classic vrius" acutally *did* modify executable code in memory all the time. In particular the DOS/earily-Windows viruses "usually" patched the command.com exe-loader to re-write the EXE files when they were opened for use. That is, the classic virus (as opposed ot the modern "virus" that really just installes itself) couldn't afford to just modify every program on the disk (which could take unbounded time and data) so it only attacked the programs you used by inserting itself when an uninfected program was launched. It just used the open facilities of the loader to manipulate the file in question. This increased the probability of infecting common programs while never having to include the file-handle management code implicit in doing directory searches and explicit in decoding the EXE header.
Of course, part of the reason that modern windows viruses are so easy to write is that windows already "includes" all the file management code (and communication code, and memory management etc) "for free" to every single executing entity, so the viral payload no longer has to be very tight to remain small enough to be effective.
Further, if the system then *implements* the various memory management options such that no block of memory is ever writeable if it is executable (and vice versa), the most common method of modifying existing executables (by mapping the files into memory and modifying them) could be "greatly reduced". No, not eleminated, but reduced. Consider how much narrower the vulnerabilities of a windows system would be if the windows core facilities that manage and manipulate EXEs were "quite resistent" to ever letting an executable file (.exe,
Don't mistake my position. I don't beleive that NX is some sort of miriacle. It's another useful tool in the box. The fact that windows is completely unprepared to leverage the technology is problematic. But if used properly it could be a huge help with actuall viruses.
The "real virus problem" is, however, dwarfed into obscurity by the flawed programs and human stupidity problems. But those arn't, strictly speaking, tied to the word "virus".
/sigh...
I know it is, but as it is being discussed in the surrounding articles as (virtually pure) buffer overrun protection, that distinction isn't obvious.
You need to remeber your audience, and acknowledge that the other participants are trying to be aware of the audience as well, before you make your little dismissive quips...
You presume much, like that I *recommend* removing /usr/bin. I am just talking about how the proposed system would effectively work.
/usr/bin is *supposed* to be the set of all properly installed facilities, why is it bad to compose directories like /usr/bin based on a survey of the installed packages?
/usr/local/bin psudo-standard where non-system programs that arn't supposed to mix into /usr/bin are supposed to go anyway).
/bin /sbin /usr/bin and /usr/sbin all have different versions of some command X in them, knows the joys of garbage-filled system directory.]
It's easy to gain-say things wihtout being at all spesific, and you have done so.
How exactly is making the *NIX system's command presentation self-assembling based on the installed packages "a humongous step backward"? (Since it _NEVER_ did that before, it would, at most be a "humongous" step in the wrong direction in your humble opinion.)
How exactly is making the common system areas self-correcting and agressively consistent with the installed base "[making] Unix Not Worth Using Any More"?
The facts are simple. If the core of the system facilities presented in the system directories like
Nothing in this prevents or usurps the ability to add packages, nor simple programs placed in well defined common searchable directories. (Hence the
The system is supposed to be extensible and functional, nowhere is it desireable for the system to become "Littered With Crap Of Dubious And Untracable Origin, Liberally Mixed With Leftovers From Improper Upgrades And Incomplete Uninstalls."
Because we all know *NIXis only worth using if you can have bogus random executables from old, spurious, and known compromised software left around to make a mess. [Anybody who has ever dealt with a conflicing install where
And _HOW_ can a reasonable person (as I will momentarily presume you to be) state that a tool that keeps common facilities consistent for all users and subsystems be biased towards "Unix for a single-user PC" exactly? Consistency, predictability, and lack-of-mysterious-binaries is *more* important in a Shared or Service-Providing installation than it would *EVER* be in a single-user system.
Do you have no grounding what so ever in fault tollerance? How about system recovery? Planned maintenance? Contractually guaranteed/limited down time? Package Migration? System certification? Compartmentalized testing? System Assurance?
Aparently you have no real understanding of how significantly useful it would be to be able to audit individual packages on a system and then "know with certanty" that when a package was removed or replaced, that the old package was completely removed and the new package was completely instanciated.
Do you not understand at all why Windows, poluted as it is with arbitrarily versioned multiple copies of the same DLL in directories all over the box is "bad", and how "uninstalling" a package and having it leave config files and dlls all over the box is _worse_?
In the same way that adding modules to the kernel using a consistent interface is good, having application groups and subsystems added to the whole computer as consistent modules would be good.
Nobody is trying to take your toys and leave.
I'm talking about being able to make CONSISTENT, CONTAINABLE, and REVERSABLE maintence of the *NIX system practical and "reasonably priced" in performance and administrative effort.
That you apparently find the "toss everything in the sandbox and lets play" aproach (we currently have) as looking forward paints you as the toy-system advocate here.
Given that, in common parlance, most people don't know the differences between the various exploits "virus" is as good a word as any.
And if the NX bit were used for more than the stack, then it could protect against a lot of (non-trojan) viral activity too.
Lets face it most viruses today aren't even viruses. They are trojans, worms, and human-engeneering exploits. How often do you see an actual virus? You know a program that writes its code into another program. It's actually getting kind of rare. Now days it is whole applications delivering themselves to your computer through email and exploiting the existing code of crap like IE and Outlook by just telling those programs to run the evil code. Most exploits today are applets and packages.
All But Gone are the days of rewritten exe headers wiht appended code fragments, and programs appending themselves to other programs in memory.
Quite frankly if all the non-code memory regions in my computer were non-execute down to the very last GDI region and printer buffer, the classic virus would be dead. The IE hacks and the trojans and the worms would still be here because certian stupid programs will do arbitrarily complex things at the behest of remote entities, but that isn't a virus. Thats bad design comming home to roost.
Yes, there are reasons that people don't want to reboot a production server. I ahve operated and then administrated production machines in varios settings since the mid seventies. I've worked five-nines government contracts. I know about down time.
/etc and /bin and /lib (completely out of symlinks and bind mounts, e.g. no copying and no duplication) to satisfy those dependencies.
/etc directory have in common should be fairly obvious. My intent is obliterate /etc as a static entity. Most packages should have their own configurations instead of bonus directories in /etc. So when you put in SSH version 2.2 the entirity of the ssh, config and all, would be in /apps/ssh/2.2 (so /apps/ssh/2.2/config). Of course, some things [like SSH oddly enough 8-)] might rank "config packages" to share the config between versions. Sounds unnecessarily complicated until SSH 11 comes along and has incompatable configs to prior versions. When you started up --with-ssh-11 your _effective_ /etc/ssh would be composed from one sourece, when --with-ssh-2 your _effective_ /etc/ssh would be from somewhere else completely. This would be controled by the dependency files/language. And so forth.
/etc and /bin are the essential problem. If these directories were composed into existence at each boot from disparate persistent sources based entirely on dependency requirements, then they couldn't get polluted over time because they would regularly be recreated from whole cloth.
No, you don't "have to reboot to execute something from a removable media."
You reboot when you want to fundimentally replace a package. (And maybe not even then if the facility were written correctly and had the necessary tools to determine that a full reboot weren't necessary and a hot recomposition could be performed.)
[note: all version nubmers chosen arbitrarily, as example, not to reference existing verions particularly]
The core idea is that what we think of today as the backbone of *NIX is a static pile of doo-doo that gets poluted too easily. If, instead, everything were safely ensconsed in it own directory and "properly documented" its own dependencies to the outside world via a parseable file full of directives. (e.g. a file that said "needs binutils, needs fileutils 2.8" etc) it would be easy for a tool to "compose" things like
The most obvious time to do this (and the one time it is mandatory) is during reboot. Reboot is also ideal to prevent the race condition where, lets say, you were replacing binutils 2.10 with 2.30 and you didn't want to worry about the mixing the output of both because someone was compiling just when you made the change.
The first version of this facility would certianly be reboot-centric. See my other comment(s) in this thread for a longer example of the possiblities including things like MakePrivateRoot as a chroot-like command that compose-and-chroot-and-exec(s) a process in its own limited and custom environment. (yes, it would be expensive, but the fact that it would be possible is significant.)
What the system and the
Dont think about this statically. The static and pollutable
The point about the removable devices is different. It's not a limit, its a feature. In a situation where machines are loaned-out to individuals (as in computer labs at schools, and cyber caffes) it is _normal_ for people to lug in whole drives full of their own work and plug in. If the core system was set up to compose-in-at-boot the external drive, while the core packages and configs were frozen on a read-only drive [think read-only via jumpers not permissions], then the core machines woudl be "automatically customized" by the portable media, but they coudln't ever be "compromised" by them. So the school in question provides the base machine and the 20 or so pac
You, indeed, don't see. You are thinking to statically.
/usr/bin of any consequence. In fact if you were to do a "rm -rf /usr/bin/*" (or whatever) and then reboot, the runtime composer would build the "correct" contents for the directories from the "real" package locations. The same thing would happen if you went in and deleted the package directory with a simple rm.
/app/lib/glibc/{version_number,...} with no /etc/ld.so.conf or /etc/ld.so.cache. you would have /app/lib/glibc/XX/ld.so.(conf,cache). The very act of compiling applicaitons with a gcc that was set up to use the version-spesific /app/lib/glibc/xx/lib/ld-linux.so loader decouples the resulting executable from /lib /usr/lib and /etc/ld.so.*. (I do this on a current product where I have /alt/3.4 and /alt/2.95.3 to support some things with gcc build preferences and library versions.)
/home. When "off", the computer doesn't have any storage media anywhere on it with /bin /usr/bin /lib /usr/lib /etc or /home or anthing that we currently consider to be central to a linux system.
/etc/rc.d) and the selective inclusion of just about anything else needed.
/bin (or whatever) if the first pass of the composer decides that something actually needs recomposition.
/usr/bin doesn't really have anything in it but a bunch of references to the real home of whatever.
/apps/binutils-2.10, you make a the new binutils in /apps/binutils/2.12 (yes, it deliberately doesn't matter that the names are not strictly orthogonal.) All of the config files point point inside the acutal /apps/watever/... directory for each version. [that is, the config files don't say /lib/whatever, they say /apps/binutils/2.12/lib/whatever and so forth] The magic is tha
There would be nothing in
That is, the use directories in the running system would "always" be built on demand.
The programs themsleves, along with thier supporting data and configurations would each live in their own private arenas, completely separated from their peers.
Now the common use directories would only even need to exsist to accomodate the casual owner, and the real programs would be in their priavte areas for more spesific uses.
Think about it from the other direction. (this is not a _practical_ example) Start with a tree of directories like
Now extrapolate that. Imagine a system where there is a not-really-root directory tree containing nothing but package and package group directories and a composer program. There is another not-really-root directory tree with the per-user stuff that we think of as
At power on, rather than running "init" (or as init if you like) the composer is invoked. The system not-really-root is mounted and a TMPFS is mounted. The TMPFS is filled, populated with the aggregate runtime "composed" from the current configuration and available packages. This includes the bound-mounts of configuration data, and user data directories, and the composition of the startup scripts (a-la
Then you rotate that TMPFS in as the real root and exec the init program in that context.
Now, that takes a bunch of time. So take the theoretical TMPFS-based version and cache it in a regular file system. You still have to do the bind-mounts but you only have to recompse a directory like
Next, non-permiscuous environments can easily be created (for things like chroot-ed rsh sessions etc) because the programs "really aren't" co-mingled to begin with. The "typical"
Consider, then, upgrading something like your binutils. Your current set of commands lives in
I'd rather like to see (and have done some trivial work on creating) a system where the entirity of each application program/suite/whatever is put in a separate directory all under a particular root (like /opt). At each start-up a "runtime composer" goes in a stats the root. If it has been updated since the composition flag file, then the composer gives a real run at building the system directories out of the application suite directories.
/etc was godhead.
/tmp, /proc, /sys, /dev and /dev/hd??) you should be able to compose a complete environment very fast.
/etc directory." /etc is the Achilles Heel of every *NIX system.
The tricky part is to have a dependency language or something, so that the startup ordering and run-level preferences can be figured out. Its not insurmountable but it is non-trivial.
So anyway, packages that don't have all the requsite dependencies installed are "factored out" and a new bin and lib and etc directory is built out with simlinks and such. (Basically remove *all* the symlinks from the composed directory that don't point to things in the composed config, then add the missing links, which is a completely functional set-theory operation.)
Anyway, you get the "better parts" of an installer scheme with a "remove that directory" uninstall semantic. Installations are just an "un-tar and reboot".
One of the features that could be included are searching removable media (thumb drives) for packages that are to factor in to the currently composed runtime. Conser things like a read-only drive with the core system and the thumb-drive inclusion so that people (think students at school and cyber-cafes) with their own personality media could reuse interchangable core systems.
The big problems I see are:
Whining from the "must boot faster" crowd.
Whining from the "shouldn't have to reboot to install" crowd.
Needing a well designed dependency language and parser.
The security model needs some tweaking in general to allow for non-priviliged packages to be used in non-priviliged ways.
The system is fairly simple once you get away from thinking that UNIX's usage of
The actual ideal is to have the root file system be a tmpfs (etc) where you would build the core directory structure at each boot. Using "mount --bind", symlinks, and a tiny semantic initialization block (e.g. to make
You could even pass kernel version, boot media and/or a few other things (like invocation parameters and language choice) into the composer script to potentially have a completely different effective root for any number of variant purposes. For instance a kernel developer could have a root template for "normal use" and for "testing the new build" on the same machine. Generic constructs like --no-packagename would exclude particular packages at boot time. That sort of thing.
Basically we need to "throw off the opressive chains of having one statically preconfigured
Why in the name of all that's holly, is it "insightful" that this guy mentions the latest shiny-object world-heart-bleeding destraction as an (implicitly) good reason to ignore the future?
What is being done there is admirable, what is being done elsewhere to directly help those there is worthwhile.
What is being EXPLOITED there by our self-important media and then LANGUISHED over by all the hand-wringers and tragedy-borrowers is DISPICABLE.
Look! Misery on TV! Get the popcorn and screw the future!.
Makes me want to puke.
Death and distruction is not a spectator sport and those who treat it like one are consigned to a very special level of LIMBO. Not even hell for you folks. Limbo. All you get is a CNN News Ticker that repeats every moment of pain you borrowed from people all over the world while the main picture is a continuous loop of the speaches of every politition you ever voted for, and a window to exit limbo can be opened if you can spot the truth behind the invective while feeling a genuine emotion. You'll never escape.
This is your doom you slugs...
(The author above *may* have just been making the point that the world populace is too easily destracted whenever the opertunity to "safely feel horror" comes along. Maybe. So maybe all the "hear hear" replies below deserve the diatribe. But crossing the one issue with the other here in this forum is blame enough to deserve a mod-point butt-kicking.)
(IMHO of course 8-)
How the hell is that "informative"?
How is the grandparent "interesting"?
It's a bunch of road-accident staring, hand wringing, ignore the future because tragedy is on TV BULL CRAP.
(IMHO of course 8-)
And meta-moderators? Kill the "informative" people, they don't deserve a vote... 8-)
It is *SAD* that you imagine that somehow people can only think about and care about one thing at a time. Your statement seems to imply that it is bad in this next destracting "time" of emergency and human suffering, for anybody to pay attention to the future of anything.
That's stupid.
One can, and a reasonable person should, give creedence to what is important, but never to the exclusion of what *else* is important.
Quite frankly, no matter how much coverage is given to the flooding and such, there is not one useful action that will be brought about by lament. It's not like there is just one eye and one heart functioning on the entire planet. That each shiny bright tradegy can derail people from seeing to the business of the future is _galling_.
Oooohhh can't protect our civil liberties, some people died. Can't watch out for the economic interests of the world, some more people died.
The rampant drive of some persons to _memorialize_ the misfortune of strangers at the expense of reasonable attention to every other aspect of life is disheartening.
Suffer On Polly, but don't expect the world to stop so that you have time to mourn strangers and slave your bleeding heart. The people on the secene are working to fix what can be fixed and salvage what can be salvaged. The people disposed to act are acting, and relief is on the way.
But the rest of the world isn't supposed to stop and stare while the nefarious and bull-headed make off with the future.
Don't be a lookie-lou.
Stop slowing down for every road-side accident.
Act, or don't act, but stop telling everybody else to stop.
This isn't a contest for "biggest heart on the prarie".
It's _SAD_ that nobody remembers things like Michael Jordan's comback. 2500 dead people, while tragic, *SHOULDN'T* have undermined the entire functioning of our society. That it *DID* is what is behind all those "the terrorists won" comments you have been failing to process.
So there was a wave in the ocean, and people died, why _precisely_ is that supposed to mean that we shoudln't pay attention to the United States' ongoing war to economically ruin other countries software industries?
Part of having some perspective is knowing when _not_ to be destracted just because you can empathize.
Its like all the memorials that pop up whenever anything hits the news. A cop is shot in Newcastle WA, hundereds of people show up to lay flowers on the sceen. Maybe fifteen of these people knew the guy. WTF? All those people "traumatized" over the death of Princess Di. WTF again? It's not that hard to understand.
Bad things happen all the time. People die all the time. How many people have been "clensed" in Africa in the last month? How many have died of AIDS there in the last year? Why don't you know? But the splashy (forgive the pun) images on TV have you all a-twitter and you watch the death-toll like a sporting event, with each count on the big board being another chance to wring your hands and suffer along with the rest of the audience.
It's sick.
I am deathly ill over your "happiness" that the world "isn't" paying attntion to patents now that it has a shiny death-match to watch on TV. It's short sighted and dispicable of you.
The crossection of the world that wants to bleed over every single pinprick is literally killing the rest of us.
Well, they wanted a chunk of our economy, and we wanted to make sure we didn't ship all of our money over there in terms of off-shoring. Now "everybody wins".
The economic colonialism of the US will "take back India for the West" and while tomorrow is India, we may get the rest of the world sometime shortly there after... if not for Poland... 8-)
The facts are simple, countries can sell off their economic future for small cash bribes today, and they seem willing to do so. They _believe_, because they were told, that these software patents are how the US got our IT industry. That belief needs must be cold comfort in the years ahead.
You can't really blame the US or its most important corporate citizens. They understand at a visceral level that the "software patent" is a huge mistake, but their two choices are to admit that the money spent so far needs to be tossed out and the software patent regime overturned OR they have to get the rest of the world to make the same mistake to re-level the playing field. The patents represent tangible power so they are unwilling to un-make the mistake, and instead have, by anonymous consent, decided that the best bet is make sure the rest of the world is equally plagued.
I am put in mind of the monkey trap. You build a box that a monkey can barely put its hand into, then put a nut in the box, the monkey reaches in and grabs the nut and then cannot get its nut-filled fist back out of the hole. The monkey could be free if it just let go of the nut, but it is biologically incapable of doing that. Its instincts are not wired up to sacrifice the nut to save its life. Its a short-comming in the whole essence of monkey-hood.
In our scenario, the companies are the monkeys, the law and its trappings are the box, software patents are the nut. Unfortunately the "IP Holding Company" is the guy with the gun who is coming to shoot the monkey dead if the monkey doesn't just starve to death first.
We have these other countries just begging for us to tell them how to put nuts in their boxes, and for no apparent reason too boot.
If you let the stupid people here get away with it...
All your software future are belong to U.S.
"Graphic Loop Control"
FireFox doesn't give as much control (anyplace obvious anyway) over things like whether a graphic loop will "play once, loop, or not animate at all".
There have been several settings that I have gone fishing for in FireFox and not subsequently found.
I have seen add-ins that claim to do some of the "missing" things, but I'll stay with the fully-featured mozilla for now.
I do give FireFox to the IE clones at work, but I use the full suite at home and work.
Let's face it, the whole problem disapears if there is an option where the start-time of a later program interrupts an earlier one.
I have run into this on several (older) PVR products/projects like the ATI PVR for the Radeon/Radeon Pro All-In-Wonder and media center. It would "miss" a later program because it couldn't switch over to it while it was cleaning up an earlier one. So an hour at 9 couldn't be recorded if you just recorded an hour at 8.
It's not that hard to see that you have to switch, wind up what you've got going, and then start the new thing and just be as fast as possible to minimize loss.
If I chose a show that runs from 8:00 to 9:02 and another that runs from 9:00 to 10:02 then It shoudl be "unacceptable" for the second one to just get dropped. Either the recording shoudl start two minutes late, or the first show should be cut off by two minutes (as my choice).
Rocket Science!
A reference as to the issues of placing a multiple generation farm onto the grid.
V er ityDisplay/29D24AC36EEACC6A85256D2E003F2E6E/$File/ WindPanelPaperPart2.pdf
http://library.abb.com/GLOBAL/SCOT/SCOT289.nsf/
Granted, with wind, the rate-of-change and frequency-of-change is more substantial compared to the sterling engine system (just because of persistence of heat compared to wind etc).
This was found with a quick google, so it may be less than perfect as a reference.
But section III-B sounds very like the power profiling issues that the solar generation system guy was describing.
===
Again, defaulting to what we have learned from wind power.
http://www.nrel.gov/docs/fy00osti/28409.pdf
"There is a concern that distributed generation must trip off-line quickly when the substation feeder breaker opens to clear a fault on the distribution line. If the generation doesn't trip off before the feeder breaker recloses, then it could cause damage to the distributed generation in some cases. The length of time allowed for a wind turbine to detect the resulting loss of the grid and then trip off is short; it may be an issue for some types of large wind turbines. There is also a concern that if the substation feeder breaker opens with no fault on the line, then the distributed generation must also trip off to avoid creating an "island" served by the distributed generation. This could possibly require some protective relaying functions to be added to wind turbines that are connected to distribution feeders. Generally, a wind turbine would trip off line if the substation breaker opens, but it is possible that it might not trip within a
few seconds."
So the relevant standards (as they emerge) are pretty much going to require that these power sources be self-isolating. And you arn't going to want to re-pay the startup current costs after a trip, nor are you going to want to lose the power generated during a falt. That says "intermediate stage with storage media" to me. The referenced paper also briefly touches on stability requirements and sync/sourcing.
===
On the issue of your degree. Arguing to authority. (and almost certianly outside of your field of expertise, since I didn't hear you calaiming to have built (been involved in building) a 20,000-independent-unit sync-alt generation station.)
===
The capacitors you seem to feel I have "magical faith" in, in _my_ head don't have a meaningful inductive impact on the grid as I am proposing them as a power resivour _behind_ the inverters that would then drive the power out onto the grid. Once you propose/introduce that level of isolation you gain a degree of freedom in the method and particulars of the individual generators.
You just watch.
I *DEFY* you to (meaningfully) "put power on" the 230,000 volt long-haul grid "with a couple of solar panels and a synchronous inverter"
Actually, _you_ should read the article. The small units will have the sync-alts, but when the farm gets to their target size they hope to get on the long distance grid at the very-high voltages.
"From 2007 to 2010, the program proposes mass-producing dishes to create a 20,000-dish farm supplying 230,000 V of long-haul power from its own substation directly connected to the grid."
This was the point at which the whole rising power thing becomes an issue in terms of a sustained, steadily increasing supply.
But at this point they also have the 10-amps for a few seconds cost per unit to come online.
Plus the "electronics" arn't going to effectively be able to put power onto the grid until the station has got a little head. Besides, there is no way in hell you want to have 20,000 sync-alt generators directly connected to the grid in one place. So the station is going to have to come up and stabalize itself anyway, just like _every_ _other_ non-trivial power source on the grid.
So the one problem solves (could solve) the other.
Bring the first dishes on-sun and power the second and subsequent through their startup (for large values of first and second 8-), the system comes online while off the grid, more-or-less as fast as possible, then cuts in just like a regular plant.
Yes there will be these mysterious electronics of which you speak and my poor caveman brain can hardly comprehend... But they are going to need a big ass bank of capacitors in there somewhere to get themsleves up to operating voltages and menaingful power levels. Elsewise the system couldn't meaningfully participate on (and protect itself from etc) the long-haul grid, and they'd be stuck at six-and-forty (dishes-to-houses 8-).
Among other things, they probably *wont* use sync-alts bare to the grid because of the reactive power that would soak up. (That would twenty _thousand_ field coil groups!) (e.g. the wind-farm delema). Were I to bet I'd bet on a farm of single independent generators or small clusters of same, near-term rectifiers "just before" a mighty bank of capacitors, and then the step-up electronics to drive the power from the capacitors onto the grid. There wouldn't be that much heating or loss either since, overall, the voltage and current profiles of the "ready" bank would remain relatively constant over any 10 second period so without much flux(*) there wouldn't be that much heat. (* yes, many caveats apply, but not in this forum. 8-)
Being hungry for every watt isn't the same as being able or willing to soak up "bad" power. And given the startup amperage, even in batches of a few milliseconds, 20,000 times is not a neighborly thing to do.
The BSOD is a standard as far as it goes.
"In the crapper" and "Runs once out of ten tries" are "quality standards" just not excessively hard to achieve.
Yea, that sounds funny, but I am not joking. If you have ever worked with government or mission critical systems you know that there are whole ranges of "quality standards" that properly hinge on all sorts of factors and properly "only go so far".
You have been conditioned to see those two words and automagically think nine-nines-of-uptime or zero-errors or whatever. But those words are _MEANINGLESS_.
The article and the proposal is a bunch of Market Speak.
In point of fact each program/project/routine has some (possibly unspoken) quality standard to which it is being crafted. And the web site/company in question is also being crafted to the PHB set.
The questions really are:
1) does this organizatino propose quality requirements that are more-exacting than the Open Software systems they expect to sell and support, and if so, will they be spending the time and money to raise those projects/programs to those standards or will they just bitch in some mailing list?
1a) Aproach?
1b) Participation?
1c) Remedies?
2) Is this just pandering to control-freakery or does the group in question have a participation model in mind? Does that model presage a "we (you people) need a licensing organization (us) to certify you as good open source"?
3) What resources is this organization/company expecting to "plunder" in their start-up period? Given that they don't list products and projects, they clearly don't plan to hire a group of experts before setting up shop. This infers that they will either shovel a lot of very fluid finincials in different directions at the drop of a dime; or serve up stock distributions with their sticker on them; or they plan to try to coerce the OS bug tracking and review process. In the latter case they probably have no idea about how little power random people have in coercing OS workers into individual agendas.
So far, my vote is, "no, we don't need you to come in and try to lubricate OS, it's working fine without your vision and you'll just give it a bad name once you finish fleecing your dupes."
The problem is, somewhat simply, that the "workspaces" to which you refer are not a feature of the X windows service. They are a feature of the window manager you have chosen to use. The "workspaceness" is acheived by realizing and unrealizing (showing and hiding) and moving windows about on the screen.
The DISPLAY value only has "server" and "screen" sections. So there is no way to communicate this "workspace" to the application.
You start an application on the _SCREEN_, that being the only screen you likely have. When the window is finally realized your window manager assigns it to the "active workspace" because that is the one that is active when the window "finally arrives."
So you have a bad case of operator impatience, and the workspace feature is so nicely and seamlessly presented by your window manager that you have been led to beleive it is a facility as opposed to a visual convention. Good for your programmer.
An exceptional window manager (note, not "application" as in Mozilla or Word or Open Office, but window manager as in KDE-WM of Gnome-WM or Motif or whatever) might be able to be configured to "know" that you want a given application to show up in a given "workspace". [e.g. like Hydravision(tm) for ATI addapters in Windows(tm).]
The problem is one of disconnect.
You click on an icon to start an application and the fork-and-exec take place and things are off and running. You switch "workspaces" but the application may not even have gotten around to calling the init routine for the X library yet, let alone contacting the display server and allocating a top-level (if invisible) window. There is no way for the window manager (or X) to associate the application that is "just connecting to the server" with the button-press of a few moments ago as the contexts are completely disjunct.
As an added example case, an application that will realize/show/"un-hide" itself in some circumstance may apear to skip around from "workspace" to workspace. Some window managers may be smart enough to take the realize-notification, see that it is for a window "on another workspace" and immediately un-realize the window before you see it or it really gets drawn.
But the virtual display surfaces you know as workspaces are just an illusion, so you really cannot blame arbitrary apps for "failing to work" with a particular (if useful and wholesome) smoke-and-mirror effect.
Hydro, it turns out, is not that great a deal. It does work, but most of the dams built in the last fifty years are nearly at the end of their lifecycle due to silting.
The envrionmental impacts are also more serious than originally thought.
The salmon issues here in the north-west UAS are bad enough, but without the regular release of non-trivial fractions of the flow at near-flood proportions lots of down-stream habatat just disapears.
One dam can stop 90% of the silt-flow of a river, which can improvish a heck of a lot of wetlands, cause rivers to "straighten" which increases the flash-flooding potential in down-stream areas, and which can fill the resivour with mud instead of water in fairly short order.
Hydro works, but it seriously needs to be re-thought if it is to be sustained.
YEs, I meant to type "100 miles square" (or something) but 100 square miles just leaked out of my brain. 8-)
But if 100 square miles was absurdist but demonstrative of the scale, 10,000 square miles is only moreso.
8-)
Remembering that the actual heat isn't going very far, the cooling isn't *that* interesting.
.5 to 2 times the size of the farm. The thermal might cast a rain shadow but not for more than twice (?) the length of the chord distance that the prevailing wind passes over the farm.
We arn't reflecting the heat off into space (a la snow-cover), we are reflecting it to a heat sink about 20 feet off the ground.
The heat passes through that heat-sink and into the air. The air temprature will probably *rise* during the day because the ground isn't soaking it up _directly_. Any given square-inch of ground will be in shdow for about two extra hours a day per dish (wild-ass geuss from just looking at the thing) and will be subject to the shadows of three dishes max. So any given square inch will be "shaded" for half the day.
A good bit of that heat will get back into the ground anyway.
The net environmental impact would be about the same as for sparse tree cover (But without the water use and with a dissimilar habatat provision).
Soil water retention would go up just a tiny bit.
The most liekly impact woudl be changes in midle-size air masses within a range of about
So worst case, (total wog again here) about the same climatological impact as if say one-third the same area were covered with "water that couldn't evaporate" or concrete sculptures of trees.
A similar area covered with buildings would probably be worse in general. It would be the classic "downtown effect" (where it is hotter downtown during the day and colder downtown at night).