This zero point energy is rather evenly distributed in all of space. It is not easily available to be used as an energy source. However, if a way could be found to utilize even some tiny differences in this unfathomably huge energy, the results would be amazing.
Environmentalists wouldn't allow it, because zero-point-energy dams would prevent K-water salmon from swimming upstream to reach their spawning grounds.
Prodigies usually attend universities near home, so that they can still live with their family. The quality of the school is secondary, as they can always move on later if they outgrow it.
Heh. My dad was one of these kids. Lucky for him he was a Boston native, and his "school near home" as Harvard.
He'll be quite open to admit, though, that it completely screwed him up socially.
Why is it possible to believe that God has always been there, and one day, dcided to create space, time the universe and you. Yet it's not possible to say simply that the universe has always been there?
It is possible to say simply that the universe has always been there. Try it: you can do it, so can I.
The question then becomes, what is it about the universe -- including the laws that govern it -- that brought it into creation?
If you don't want to visit that issue at all, then that's your choice. Just don't dismiss those who look more deeply into the question of creation, especially the fundamental issue of self-creation.
For myself, only by taking an over-arching view of the entire concept of the universe -- aka "metaphysics" -- do I feel I have any hope of getting a practical understanding of what is going on here, and now.
This study of "metaphysics" is, naming issues aside, really indistinguishable from the study of what is widely called "God". And, just as Western science tends to want to reduce multiple competing systems describing the universe into a single one so it covers all bases (as in trying to unify theories such as G, EM, and so on), Western metaphysics, or science, tends to want to assume that there is only a single "metaphysical" system that accounts for the entire cosmos in the first place.
As to "one day, [God] decided to create space, time, the universe, and you": since space, time, the universe, and we are all, even according to the most atheistic interpretation of physical law (quantum mechanics, string/noodle theory, whatever), nothing more than ephemeral manifestations of an arbitrary number of random events resulting, on rare occasion, in some kind of "emergent behavior", there's no basis whatsoever to worry about whether or when God "decided" to create that, because, outside of that system, which includes not only the rules of the universe but the very concepts of "rules" and "causality", there's simply no such thing as "whether" (no concept of choice) or "when" (no concept of time).
It's not that scientists consider pre-big-bang to be taboo. It's just that there's no generally accepted theory. Some think whatever happened before is unkowable and therefore pointless to dicuss(but not forbidden). Others think there was another universe before this one that underwent a big crunch. Others believe there were lots of little bangs going on for eternity. Others think the universe didn't start with any bangs at all but has always been here, swimming around for eternity.
Exactly the point -- except that, in practice, this lack of clarity beyond what seems to be a vast ocean of consensus among scientists leads to many scientists (or at least their "spokespeople", such as politicians, talking heads, and public-school teachers -- you know, the ones who say "scientists tell us Global Warming is happening, it'll be a disaster, it's man's fault, and we can make things better by entering the Kyoto Protocols") treating it as if it were taboo, and treating anyone who does go there not unlike how some dark/middle-age "religious" types treated those who were willing to sail beyond the horizon: as "nutcases".
Metaphysicists, however, are willing to explore (not merely speculate about) those issues, except they typically move it out of the realm of "what physical characteristics describe the universe pre-Big-Bang" into "what metaphysical characteristics account for our entire existence in the first place, and why?".
That changes the point of view from one of remote, probably irrelevant, distances in spacetime, to one of immediate concern, because it implies that there might be some Creator, completely unconfined by our own material universe and its rules, able to fully control this universe (e.g. by directing each and every event we call random, even if fundamentall
what was before/caused the big bang is by definition unknowable. And religious people can always invoke God at they will never be disproved. So why some people feel the need to invoke God in areas in which we have evidence for the mundane, is just ridiculous.
Not really, but I can see why it seems that way, because I've thought long and hard about the "problem" from several points of view (mainly, raw atheism and variants, and Christianity, including strains such as Christian Science).
Here is the essential problem leading to "why the need to invoke God".
Even if science can demonstrate that, given some reduced set of laws ("unified principle", "string theory", etc.), and an initial state of some arbitrary or random substance (which is, or leads to, the "big bang"), our entire existence and experience can theoretically come into existence -- I'll go further, let's say it someday demonstrates that this mechanism did create our present existence -- there still remain three fundamental questions regarding this approach:
How did that reduced set of laws come into being?
How did that initial state come into being?
How can we be sure what we claim to observe as "our entire existence" is anything approaching reality?
The first two problems represent what I call the Creation Problem. "Scientists" can identify and point to all the mechanisms they want to explain how we got from Point Y to Point Z, and backwards in time (well, in causality) to Point A, but they have never even begun to identify any self-creative concept (rule base) or substance (atomic, quantum, string, or otherwise) that explains how Point A came into being.
So, today's "scientists" basically hand-wave the issue by saying "beyond Point A, we don't discuss, and anybody who does so is perhaps a fool, or at least unscientific".
The scientifically religious, such as Christian Scientists (or as they're properly taught), recognize this concept of a self-creating entity from the Bible, and perhaps from other religious texts.
Without that concept of a self-creating entity, there is no basis to believe in the concept of creation (or causality) itself, or at least there has yet to be put forward, to my knowledge, any reason to accept that some arbitrary process (like quantum mechanics) leads from one state to the other, and thus to "life", yet somehow this whole thing never had to itself "arise" from anything, it just somehow spontaneously "created" itself, outside of spacetime, despite having left no evidence of its own self-creative capacities that we can see (we see evidence only of those processes in action, not of any spontaneous self-creation; the universe is "winding down" ever since the Big Bang).
In short, lack of a self-creating entity implies lack of any Creation in the first place, which denies our entire existence. But today's Science consistently denies the existence of any self-creating entity, and denies the only widely identified such entity -- God -- as being pertinent.
(Consider Conway's Game of Life: it's obvious this game can demonstrate apparently lifelike, and certainly highly complex, behavior, given a sufficiently interesting starting point, but the fact remains that the rules were invented by Conway, and the starting point by whoever starts the game; the game does not create itself, nor its own rules or starting point.)
This leads to Point 3, above; is it all our -- my -- imagination that we (I) exist? Well, down that path, we might as well imagine whatever the heck we want, whether that includes God or Satan or Bill Gates or whatever.
The upshot is, while "scientists" credit themselves for being "dispassionate" about the existence of a Deity, such as the Christian God, there are plenty of sincere Christians who are sufficiently scientific -- who, like myself, honestly think about and explore, with Bible in one
In New Jersey, where my wife grew up, their bank had its home office in Red Bank, but they did most of their banking at a branch it had in Long Branch.
So they often went to the Long Branch Branch of the Red Bank Bank!
its not necessarily the case that everyone enjoys that sort of thing
Exactly. When I think back, say, 20 years and recall my most "fun" memories, sure, there are a few that involve "partying" (this is a few years before my marriage), but not really the kind y'all are talking about, even though I did try the scene a few times just out of curiousity.
An example of something I really do cherish, and a strange one at that because, on the surface, it wouldn't mean much to most people, is definitely a "nerd thing".
I was working at Prime Computer as a tech writer at the time, having switched from programming, but had nevertheless retained, or perhaps regained, my "status" among the hardcore OS coders up on the 3rd floor where I used to work.
Though my new position came to involve management and more of a 9-5 schedule, a special project required me to work 80-hour weeks for a few months, and, during this time, at especially odd hours, some of the OS and FS (filesystem) guys would occasionally show up in my office in order to run some design decision or weird bug past me. (They were in the midst of transitioning the OS from static executables to dynamic, kinda like to what Linux calls ELF, and the FS was on its second attempt at a redesign implementing ACLs and quotas. That led to lots of new problems.)
One Saturday night, when I suppose I could have been out on a hot date, we got together early enough to go out to a local Chinese restaurant that my tech-writing friends frequented during the workweek.
So, there we were, at Ming Gardens in Natick, at maybe 9:30 or 10 pm on a Saturday night. A bunch of hardcore nerds, most of whom were overweight (I certainly was, but never by a whole ton), some of whom were ugly, and none of whom, to my recollection, had particularly good social skills (but I was probably on the low end of the range myself). And the guys were ordering food for the group -- you know, stuff like potstickers.
Yet, somehow, that became a "special moment" for me. I think it's just an aspect of feeling like a member of a "clan", almost like primitive hunter-gatherers, except these guys would be better at designing the spear than throwing it.
It was also a meaningful act of acceptance -- in many ways, moreso than if, say, some hot 20-something blonde had thrown herself at me, because who knows how long that sort of adoration would last (as it usually comes with some serious strings attached).
After all, to the extent I was being accepted by these guys, it was for my skills and insight. They didn't invite me along because I was rich, handsome, popular, or their boss. In some ways, I'd had to earn their respect. And they deserved, and got, mine for the same reasons.
Now, I've never been the sort of guy who likes hanging out with guys. Going to ballgames, sports bars, etc., are things I have done only on occasion.
But these sorts of memories are so meaningful to me, they help me understand why guys -- even those married to "hot" women -- often want to spend entire nights playing poker or bowling with their friends.
And since getting married and, especially, having children will tend to cut down on the time available to "bond" with other guys, it's probably just as worthwhile spending time doing that, and having memories you can honestly share with your children once they reach a certain age, than to spend your youth "partying".
Of course, when some guys hang around so they can find the hot chicks and cool parties together, one perhaps shouldn't turn down the opportunity to kill two birds with one stone....
But, to be clear, what the GP talked about -- working the door of a club -- is, to me, just the sort of constructive, positive experience a nerdy type could use in order to learn how a very different part of the "real world" actually works, as well as gain self-confidence. It's probably a lot more dangerous than h
A couple of replies have already touched on this, but I'll say it straight out: let's kill filenames while we're at it.
By "kill", I mean that the OS (the one I'm designing anyway) shouldn't assume that the creator of a file will assign a particular filename to it at any particular point.
Unix requires the creator to assign a filename when the file is first opened for writing. That leads to all sorts of annoying workarounds for cases when the name isn't important, as in temporary files (witness all the security and related bugs with multiple users accessing/tmp) and emails (which have no need of names, more of "to" addresses).
Internally, filenames are metadata in much the same way as are folders (directories).
So why not let users simply "Save" a document without having to give it a name? Ditto for the underlying API to the OS.
Never mind "Save". Why not just automatically journal any work in progress, and let users easily browse such works by timeline ("whatever I was working on yesterday afternoon" becomes easy to spot, given a suitable clock or calendar presentation) or content?
Historically, much of what we refer to as "files" and "directories" came from the assumption that "save to disk" was synonymous with "make sure this survives a system crash or power outage".
Nowadays, most personal computing devices are as reliable as historical disk drives, sometimes moreso (many have solid-state hard drives), most are networked, and many are constantly "on line" to that network.
So, instead of "Save" and requiring a user to name a file, replace that paradigm with one that allows users to more easily and naturally "Commit" changes to a document, "Publish" the document to a given audience, "Secure" the document such that it never is recorded on certain devices or networks, and so on.
Eliminating underlying OS dependencies on filenames and file folders can free the OS, API, and even the user to focus on characterizing and searching for the data in the documents being composed, not on trying to figure out just what is the right name and/or "location" for a document as it is being composed.
In the case of a VLIW machine, theoretically, it's a fast beast- but you have to have a good compiler
I'm no longer convinced. I worked on the internals of a Fortran optimizing compiler for a VLIW machine -- nearly 20 years ago!! -- so I do have some understanding of the issues.
Seems to me that we've had plenty of time to produce VLIW compilers of adequate quality. Any VLIW/EPIC-chip vendor would naturally try very hard to ensure all potential developers (including 3rd-party and FOSS developers) had easy, even free, access to such compiler. Otherwise, what's the point?
Yet, VLIW just keeps failing to capture anything beyond a niche market. Why?
I think it's because it really wins only for a relatively narrow range of chip technologies, die sizes, and application needs.
Mainly, once you compile your code to a VLIW target, you've committed it to run efficiently on a very specific number of available registers, a particular narrow range of memory latencies, and so on.
So if you run that same machine code on a newer, "bigger" CPU with more registers or faster (or even different-latency) memories, your highly optimized code is suddenly stuck running in a suboptimal fashion. Ditto if you run it on a lower-cost, lower-power machine that offers, say, half the registers and twice the memory latencies.
Meanwhile, your I-cache gets stressed out because of all the long instructions needed to get so much less done. Sure, when you're in a predictably tight loop with few or no intra-iterative dependencies, the loop itself might take within 5x the number of bytes of code, compared to x86, in I-cache, and run a lot faster (at least on paper).
But all the "scalar" code really blows up your I-cache, or so I assume. Whereas a CPU with a bit-efficient ISA, such as the x86, fits a lot more into the same I-cache, with the tradeoff that it might use a smaller I-cache in order to gain space for a microcode-like decoding of "hot spots" in the code it is running (e.g. loops), in which case that microcode is, obviously, fairly carefully tuned to suit that particular processor. (Yes, it's basically got the optimization phase of a compiler on the chip at that point, something VLIW theoretically doesn't need.)
IMO, before VLIW/EPIC chips become winners, we'd have to see a fundamental leap in the ability of not just compilers, but operating systems, libraries, linkers/loaders, and so on, to accommodate truly dynamic, chip-specific generation of machine code from a predigested form of the original code.
It's not unlike what would be needed to really take advantage of per-CPU knowledge of I-cache, D-cache, L2 cache, TLB, and other concerns, except much more complicated, so I'd try first to demonstrate that a complete OS could take advantage of today's CPUs, before assuming one could take sufficient advantage of VLIW/EPIC to justify rolling out a whole new architecture.
I sometimes wonder what the modern wolrd would be like if they hadn't been so incompetent.
I used to wonder about that sort of thing all the time.
Now I'm pretty much convinced that tyranny is merely a particular form of incompetence.
Whether tyranny pertains to social mores, personal beliefs, choice of where to live, choice of what kind of work to do, or general economics, it seems that, generally speaking, the more tyrannical a regime, the more incompetent it is.
The result seems to be that, over time, tyranny lessens as more-competent (less-tyrannical) regimes come into power.
I don't even know what the hell that's supposed to mean.
Well, seeing as the version of GCC you're using is the result of a fork, which couldn't have happened if GCC had been a typical proprietary compiler, it's pretty clear that the right to fork is, indeed, essential to the free-software community.
What even if it is true? You're pointing out that he used a proprietary tool to write some substitutive free equivalent?
I don't know if that's what the OP was trying to say, but, in any case, AFAIK the TECO RMS used to implement EMACS was not proprietary. It was the MIT-ITS version, and I'd be very surprised if it wasn't as easy to walk out of the AI lab with a magtape of the TECO source code under your arm as it proved to be with the sources for other programs written there....
(My recollection is getting vague, but I do remember being in the AI building and online when RMS sent everyone a message about a new release or version of EMACS, and trying it out, thinking it was kinda cool but weird. That would have been in 1976 or so.)
Re:Compiler incompatibilities
on
GCC 4.0 Preview
·
· Score: 1
[...]about Fortran character strings, are they still passed with a hidden argument for the length in addition to the formally declared argument (address) or have the GNU people by now figured out why, for example, VMS compilers use a descriptor (structure) to describe complex arguments?
GNU isn't a clone of VMS; rather, a clone of Unix, so compatibility with f77, f2c, etc. was more important during g77 development than was replicating the VAX/VMS FORTRAN environment (though some of that background did find its way into the g77 front end, at least early on).
Besides, VMS's descriptors weren't just about catering to the CHARACTER type in Fortran, but about a full range of inter-language capabilities that was offered by that architecture. GNU hadn't, and to my knowledge hasn't since, attempted to similarly cater to the (fairly tiny) audience for such a comprehensive range of capabilities. It would have been counterproductive for g77 to try to serve as the launching-pad for such capabilities; just getting the GCC people to recognize the utility of certain optimizations that would help Fortran code was nontrivial.
Whether g95 uses descriptors by default (for FORTRAN-77-compatible CHARACTER types), or sticks with the hidden-argument approach for compatibility with g77-compiled (and f77-compiled and f2c-compiled) code to which its own compiled code might be linked, I don't know. Check the web site. But for some F90 features, much more sophisticated handling of argument-passing to procedures (than g77 ever did) would certainly seem to be necessary.
"semi-random" testing (we call it Adaptive Random Testing) which, we claim, detects more errors with fewer tests and reduces the problem that way
When I was developing GNU Fortran (g77), one of the other volunteers (Dave Love, I think it was?) used this approach to stress-test the compiler.
It worked great. Caught lots of the usual "duh" kind of bugs, but occasionally caught the "omigod" sort -- the kind of bug that, at first, looks like just another crash, but, upon further investigation, exposes a higher-level flaw in the design or implementation.
I would definitely strongly recommend this kind of testing for any pertinent product while under development.
[...]on the cache-miss and similar though. That's why itanium was good - less of the cpu trying to optimize its own code before running it.
But it doesn't seem to be good enough for the marketplace.
I'm not sure whether that's because it's ultimately suboptimal in theory (no compilers could ever work around such a design) or in practice (such compilers weren't buildable within the economic and time constraints necessary to make the system, as a whole, meet its original performance goals).
If you think that removing the gunk and having an OS based around from-source would let you compile in timescales similar to installing a binary package, then you're right and let's start working on it, but I don't think processors are quite fast enough yet.
I think that it's all possible.
I think a sufficiently-well-designed system would allow a distribution to consist of not just the raw source, and not the equivalent of today's executables, but of raw source plus something in between the two that allows a final optimization stage to focus optimization resources on the known "hot spots" and, otherwise, use cheap target-specific optimizations to generate the final code upon installation.
I think this sort of system could provide all sorts of advantages over the present architecture, be faster, more reliable, easier to debug, etc.
But, since I might well be wrong, or right but ahead of my time (or possibly behind?), I don't want to start working on it until I can satisfy at least one of the following two criteria:
Create a small-scale prototype as proof of concept, demonstrate that it would actually work and produce better "numbers" than would be predicted by the old way (perhaps actually implement the prototype's design the "old way" as a separate track for direct comparison)
Create tools
that not only automatically generate much of the code for such a system, but much of the protocols, file formats, and APIs as well
(Asking a computer to do more work for me means giving it more power to decide how best to approach the task. For example, since I'm "asking" it to allow distributions of pre-digested source leading to faster generation of optimized code upon installation, either I have to design the format of those pre-digested files myself, or I can somehow teach the system to do it itself and maybe produce a better result.)
Accordingly, I've been slowly designing a simple, scaled-down replacement for the Unix OS that is intended to allow me to meet both criteria, or at least the first.
(But I haven't really written much up on it yet -- nothing online, certainly.)
If you delay the compilation to startup, you get a delay when launching.
I'm not suggesting anything quite that naive.
Think of it this way: when you install, say, Fedora Core 3 (FC3) on your computer, you are experiencing a delay in startup, in two important ways:
It took the package distributor a long time to generate the binaries for some generic system, but your system is probably different enough to deserve binaries optimized specifically for it; so, to get an "optimal" install, you're looking at installation, or startup, times comparable to a Gentoo install anyway
The supposedly-optimized binaries you're running have all sorts of special code to discover what's special about your system, and somehow communicate that (mostly ineffectively) to all the other program binaries in the distribution, so you have to wait for that to happen anyway (you might be surprised how much of the startup code your system runs each time you do something is, in fact, unnecessary)
An OS designed from the ground up around source availability would not always suffer the former penalty and could more generally reduce the latter.
Yet, there would be nothing preventing distributing "pre-digested", or pre-compiled, variants of such an OS. Such variants would be, conceptually, little different from use of prefetching or caching at lower levels.
Speaking of lower levels, I do wonder how much faster a given system might be if the CPU didn't provide constant cache-miss and TLB-miss detection, among other things, and left that to the code.
That'd certainly make code-generation more complicated, but that's why we have computers, right?
Meanwhile, inside tight loops, once the code verified that ranges of addresses pertaining to the working set of a loop were in the L1 cache, mapped, etc., the inside-loop references could be substantially faster (premapped to hardware RAM addresses, for example).
anything you can do at run-time you can do at compile-time - just add a detection routine if you really need to, most of the time you won't
It can't be that simple, or (and I have often thought about this myself) the fastest general-purpose CPUs would not have dedicated hardware to detect cache misses, TLB misses, etc.
And in a perfect world where complexity management wasn't a problem, indeed, much of what is presently reserved to special functions in a CPU would be instead made available to more-general mechanisms that clever compilers could exploit.
But complexity management is the problem. Move complexity out of the CPU architecture and it either becomes slow (you've serialized and sequentialized everything) or practically impossible for most of its users to properly program in order to regain the performance lost due to naively using the underlying architecture.
Then there's the (apparent, at least to me) fact that dedicated logic can always (?) be "shrink-wrapped" to smaller, faster cores than can equivalent logic implemented via dynamically programmable microcode/nanocode on top of a simpler hardware micro/nano-processor.
After years of trying to teach compilers to take advantage of VLIW (and EPIC) architectures, it still seems best, overall, to leave microinstruction scheduling, dependency analysis, and so on to the hardware via its own run-time analysis.
A simpler instruction set (that leaves low-level optimization to run-time decisions by the CPU) also has the advantage of allowing "vanilla" programs to much more easily run across a wide range of compatible hardware.
(Yes, "fat binaries" or equivalents can make some accommodations, but IMO the way to go, to really take advantage of the sort of theoretical capabilities you and I are talking about, is to run an OS that is beyond GNU in terms of being designed, from the ground up, to always run "source code" at a fundamental level -- that is, treating compilation as a behind-the-scenes activity.)
My biggest gripe with comments is that they're written by people who aren't technical writers, so they often are ambiguous, misleading, or false.
I started programming when I was 9. By the time I was in my early 20s, I was a "hotshot". I also wrote lousy specs for my software, but, amazingly, the people in the Tech Pubs department said they were generally the best such specs that R&D was turning out.
As a result of realizing my comms skills were poor and having an opportunity for a career change, I accepted a job in that very Pubs department, learned the "trade" of tech writing, ended up in management, won a tech-writing award, set some new standards for accuracy and clarity (especially documenting APIs for the OS), and so on.
Yet, despite all that, I still am quite capable of writing overly long, dense paragraphs, and, if I'm not careful, they can say, precisely and clearly, the opposite of what I intended them to say (that is, a reader can legitimately make the "wrong" conclusion).
And I've seen comments written by programmers who employ the "terse" style, yet still manage to write comments that could be interpreted N different ways. ("This can't exceed 20" -- which means what, exactly?)
It's bad enough depending on code written by people with poor communication skills; it gets worse if they also expect me to depend on their prose to understand what is going on.
Better for programmers to write code and minimal prose, just as I think we'd all prefer tech writers to stick to writing prose and not code (as they often get even sample code wrong).
My favorite programming tricks of all time involved the use of EQUIVALENCE.
Not just your favorite; the PRIMOS operating system, and many of its utilities (I started out fixing bugs in FUTIL, the file-utility program that did copying, deleting, renaming, etc. of files), used EQUIVALENCE, as they were written in a kind of FORTRAN 66, along with COMMON, to do what C programmers would ultimately recognize as structs, unions, pointer operations, malloc()'s, and free()'s.
you do need some way of having an non uniform pixel density.
If you figure that out, don't you also need a way to keep the human's eye(s) from focusing on the lower-resolution portions of the display instead of the area you've designed to accommodate high resolution?
Slashdot Mirror
Not for N=1 or P=0.
;-)
Environmentalists wouldn't allow it, because zero-point-energy dams would prevent K-water salmon from swimming upstream to reach their spawning grounds.
It is possible to say simply that the universe has always been there. Try it: you can do it, so can I.
The question then becomes, what is it about the universe -- including the laws that govern it -- that brought it into creation?
If you don't want to visit that issue at all, then that's your choice. Just don't dismiss those who look more deeply into the question of creation, especially the fundamental issue of self-creation.
For myself, only by taking an over-arching view of the entire concept of the universe -- aka "metaphysics" -- do I feel I have any hope of getting a practical understanding of what is going on here, and now.
This study of "metaphysics" is, naming issues aside, really indistinguishable from the study of what is widely called "God". And, just as Western science tends to want to reduce multiple competing systems describing the universe into a single one so it covers all bases (as in trying to unify theories such as G, EM, and so on), Western metaphysics, or science, tends to want to assume that there is only a single "metaphysical" system that accounts for the entire cosmos in the first place.
As to "one day, [God] decided to create space, time, the universe, and you": since space, time, the universe, and we are all, even according to the most atheistic interpretation of physical law (quantum mechanics, string/noodle theory, whatever), nothing more than ephemeral manifestations of an arbitrary number of random events resulting, on rare occasion, in some kind of "emergent behavior", there's no basis whatsoever to worry about whether or when God "decided" to create that, because, outside of that system, which includes not only the rules of the universe but the very concepts of "rules" and "causality", there's simply no such thing as "whether" (no concept of choice) or "when" (no concept of time).
Exactly the point -- except that, in practice, this lack of clarity beyond what seems to be a vast ocean of consensus among scientists leads to many scientists (or at least their "spokespeople", such as politicians, talking heads, and public-school teachers -- you know, the ones who say "scientists tell us Global Warming is happening, it'll be a disaster, it's man's fault, and we can make things better by entering the Kyoto Protocols") treating it as if it were taboo, and treating anyone who does go there not unlike how some dark/middle-age "religious" types treated those who were willing to sail beyond the horizon: as "nutcases".
Metaphysicists, however, are willing to explore (not merely speculate about) those issues, except they typically move it out of the realm of "what physical characteristics describe the universe pre-Big-Bang" into "what metaphysical characteristics account for our entire existence in the first place, and why?".
That changes the point of view from one of remote, probably irrelevant, distances in spacetime, to one of immediate concern, because it implies that there might be some Creator, completely unconfined by our own material universe and its rules, able to fully control this universe (e.g. by directing each and every event we call random, even if fundamentall
Not really, but I can see why it seems that way, because I've thought long and hard about the "problem" from several points of view (mainly, raw atheism and variants, and Christianity, including strains such as Christian Science).
Here is the essential problem leading to "why the need to invoke God".
Even if science can demonstrate that, given some reduced set of laws ("unified principle", "string theory", etc.), and an initial state of some arbitrary or random substance (which is, or leads to, the "big bang"), our entire existence and experience can theoretically come into existence -- I'll go further, let's say it someday demonstrates that this mechanism did create our present existence -- there still remain three fundamental questions regarding this approach:
How did that reduced set of laws come into being?
How did that initial state come into being?
How can we be sure what we claim to observe as "our entire existence" is anything approaching reality?
The first two problems represent what I call the Creation Problem. "Scientists" can identify and point to all the mechanisms they want to explain how we got from Point Y to Point Z, and backwards in time (well, in causality) to Point A, but they have never even begun to identify any self-creative concept (rule base) or substance (atomic, quantum, string, or otherwise) that explains how Point A came into being.
So, today's "scientists" basically hand-wave the issue by saying "beyond Point A, we don't discuss, and anybody who does so is perhaps a fool, or at least unscientific".
The scientifically religious, such as Christian Scientists (or as they're properly taught), recognize this concept of a self-creating entity from the Bible, and perhaps from other religious texts.
Without that concept of a self-creating entity, there is no basis to believe in the concept of creation (or causality) itself, or at least there has yet to be put forward, to my knowledge, any reason to accept that some arbitrary process (like quantum mechanics) leads from one state to the other, and thus to "life", yet somehow this whole thing never had to itself "arise" from anything, it just somehow spontaneously "created" itself, outside of spacetime, despite having left no evidence of its own self-creative capacities that we can see (we see evidence only of those processes in action, not of any spontaneous self-creation; the universe is "winding down" ever since the Big Bang).
In short, lack of a self-creating entity implies lack of any Creation in the first place, which denies our entire existence. But today's Science consistently denies the existence of any self-creating entity, and denies the only widely identified such entity -- God -- as being pertinent.
(Consider Conway's Game of Life: it's obvious this game can demonstrate apparently lifelike, and certainly highly complex, behavior, given a sufficiently interesting starting point, but the fact remains that the rules were invented by Conway, and the starting point by whoever starts the game; the game does not create itself, nor its own rules or starting point.)
This leads to Point 3, above; is it all our -- my -- imagination that we (I) exist? Well, down that path, we might as well imagine whatever the heck we want, whether that includes God or Satan or Bill Gates or whatever.
The upshot is, while "scientists" credit themselves for being "dispassionate" about the existence of a Deity, such as the Christian God, there are plenty of sincere Christians who are sufficiently scientific -- who, like myself, honestly think about and explore, with Bible in one
And just how does one perform a Fourier transform on a coronet, I wonder?
In New Jersey, where my wife grew up, their bank had its home office in Red Bank, but they did most of their banking at a branch it had in Long Branch.
So they often went to the Long Branch Branch of the Red Bank Bank!
Exactly. When I think back, say, 20 years and recall my most "fun" memories, sure, there are a few that involve "partying" (this is a few years before my marriage), but not really the kind y'all are talking about, even though I did try the scene a few times just out of curiousity.
An example of something I really do cherish, and a strange one at that because, on the surface, it wouldn't mean much to most people, is definitely a "nerd thing".
I was working at Prime Computer as a tech writer at the time, having switched from programming, but had nevertheless retained, or perhaps regained, my "status" among the hardcore OS coders up on the 3rd floor where I used to work.
Though my new position came to involve management and more of a 9-5 schedule, a special project required me to work 80-hour weeks for a few months, and, during this time, at especially odd hours, some of the OS and FS (filesystem) guys would occasionally show up in my office in order to run some design decision or weird bug past me. (They were in the midst of transitioning the OS from static executables to dynamic, kinda like to what Linux calls ELF, and the FS was on its second attempt at a redesign implementing ACLs and quotas. That led to lots of new problems.)
One Saturday night, when I suppose I could have been out on a hot date, we got together early enough to go out to a local Chinese restaurant that my tech-writing friends frequented during the workweek.
So, there we were, at Ming Gardens in Natick, at maybe 9:30 or 10 pm on a Saturday night. A bunch of hardcore nerds, most of whom were overweight (I certainly was, but never by a whole ton), some of whom were ugly, and none of whom, to my recollection, had particularly good social skills (but I was probably on the low end of the range myself). And the guys were ordering food for the group -- you know, stuff like potstickers.
Yet, somehow, that became a "special moment" for me. I think it's just an aspect of feeling like a member of a "clan", almost like primitive hunter-gatherers, except these guys would be better at designing the spear than throwing it.
It was also a meaningful act of acceptance -- in many ways, moreso than if, say, some hot 20-something blonde had thrown herself at me, because who knows how long that sort of adoration would last (as it usually comes with some serious strings attached).
After all, to the extent I was being accepted by these guys, it was for my skills and insight. They didn't invite me along because I was rich, handsome, popular, or their boss. In some ways, I'd had to earn their respect. And they deserved, and got, mine for the same reasons.
Now, I've never been the sort of guy who likes hanging out with guys. Going to ballgames, sports bars, etc., are things I have done only on occasion.
But these sorts of memories are so meaningful to me, they help me understand why guys -- even those married to "hot" women -- often want to spend entire nights playing poker or bowling with their friends.
And since getting married and, especially, having children will tend to cut down on the time available to "bond" with other guys, it's probably just as worthwhile spending time doing that, and having memories you can honestly share with your children once they reach a certain age, than to spend your youth "partying".
Of course, when some guys hang around so they can find the hot chicks and cool parties together, one perhaps shouldn't turn down the opportunity to kill two birds with one stone....
But, to be clear, what the GP talked about -- working the door of a club -- is, to me, just the sort of constructive, positive experience a nerdy type could use in order to learn how a very different part of the "real world" actually works, as well as gain self-confidence. It's probably a lot more dangerous than h
Yeah, but they're also prone to long, boring solos.
By "kill", I mean that the OS (the one I'm designing anyway) shouldn't assume that the creator of a file will assign a particular filename to it at any particular point.
Unix requires the creator to assign a filename when the file is first opened for writing. That leads to all sorts of annoying workarounds for cases when the name isn't important, as in temporary files (witness all the security and related bugs with multiple users accessing /tmp) and emails (which have no need of names, more of "to" addresses).
Internally, filenames are metadata in much the same way as are folders (directories).
So why not let users simply "Save" a document without having to give it a name? Ditto for the underlying API to the OS.
Never mind "Save". Why not just automatically journal any work in progress, and let users easily browse such works by timeline ("whatever I was working on yesterday afternoon" becomes easy to spot, given a suitable clock or calendar presentation) or content?
Historically, much of what we refer to as "files" and "directories" came from the assumption that "save to disk" was synonymous with "make sure this survives a system crash or power outage".
Nowadays, most personal computing devices are as reliable as historical disk drives, sometimes moreso (many have solid-state hard drives), most are networked, and many are constantly "on line" to that network.
So, instead of "Save" and requiring a user to name a file, replace that paradigm with one that allows users to more easily and naturally "Commit" changes to a document, "Publish" the document to a given audience, "Secure" the document such that it never is recorded on certain devices or networks, and so on.
Eliminating underlying OS dependencies on filenames and file folders can free the OS, API, and even the user to focus on characterizing and searching for the data in the documents being composed, not on trying to figure out just what is the right name and/or "location" for a document as it is being composed.
I'm no longer convinced. I worked on the internals of a Fortran optimizing compiler for a VLIW machine -- nearly 20 years ago!! -- so I do have some understanding of the issues.
Seems to me that we've had plenty of time to produce VLIW compilers of adequate quality. Any VLIW/EPIC-chip vendor would naturally try very hard to ensure all potential developers (including 3rd-party and FOSS developers) had easy, even free, access to such compiler. Otherwise, what's the point?
Yet, VLIW just keeps failing to capture anything beyond a niche market. Why?
I think it's because it really wins only for a relatively narrow range of chip technologies, die sizes, and application needs.
Mainly, once you compile your code to a VLIW target, you've committed it to run efficiently on a very specific number of available registers, a particular narrow range of memory latencies, and so on.
So if you run that same machine code on a newer, "bigger" CPU with more registers or faster (or even different-latency) memories, your highly optimized code is suddenly stuck running in a suboptimal fashion. Ditto if you run it on a lower-cost, lower-power machine that offers, say, half the registers and twice the memory latencies.
Meanwhile, your I-cache gets stressed out because of all the long instructions needed to get so much less done. Sure, when you're in a predictably tight loop with few or no intra-iterative dependencies, the loop itself might take within 5x the number of bytes of code, compared to x86, in I-cache, and run a lot faster (at least on paper).
But all the "scalar" code really blows up your I-cache, or so I assume. Whereas a CPU with a bit-efficient ISA, such as the x86, fits a lot more into the same I-cache, with the tradeoff that it might use a smaller I-cache in order to gain space for a microcode-like decoding of "hot spots" in the code it is running (e.g. loops), in which case that microcode is, obviously, fairly carefully tuned to suit that particular processor. (Yes, it's basically got the optimization phase of a compiler on the chip at that point, something VLIW theoretically doesn't need.)
IMO, before VLIW/EPIC chips become winners, we'd have to see a fundamental leap in the ability of not just compilers, but operating systems, libraries, linkers/loaders, and so on, to accommodate truly dynamic, chip-specific generation of machine code from a predigested form of the original code.
It's not unlike what would be needed to really take advantage of per-CPU knowledge of I-cache, D-cache, L2 cache, TLB, and other concerns, except much more complicated, so I'd try first to demonstrate that a complete OS could take advantage of today's CPUs, before assuming one could take sufficient advantage of VLIW/EPIC to justify rolling out a whole new architecture.
I used to wonder about that sort of thing all the time.
Now I'm pretty much convinced that tyranny is merely a particular form of incompetence.
Whether tyranny pertains to social mores, personal beliefs, choice of where to live, choice of what kind of work to do, or general economics, it seems that, generally speaking, the more tyrannical a regime, the more incompetent it is.
The result seems to be that, over time, tyranny lessens as more-competent (less-tyrannical) regimes come into power.
Sigh. Yes. I knew I should have run that post through my HaxChecker.
Good luck with that, but here are some suggestions to replace your use of "Unix-based":
Okay, that last one is a ridiculous name that nobody in their right mind would ever use for an OS, but the rest are pretty cool, eh?
Well, seeing as the version of GCC you're using is the result of a fork, which couldn't have happened if GCC had been a typical proprietary compiler, it's pretty clear that the right to fork is, indeed, essential to the free-software community.
I don't know if that's what the OP was trying to say, but, in any case, AFAIK the TECO RMS used to implement EMACS was not proprietary. It was the MIT-ITS version, and I'd be very surprised if it wasn't as easy to walk out of the AI lab with a magtape of the TECO source code under your arm as it proved to be with the sources for other programs written there....
(My recollection is getting vague, but I do remember being in the AI building and online when RMS sent everyone a message about a new release or version of EMACS, and trying it out, thinking it was kinda cool but weird. That would have been in 1976 or so.)
GNU isn't a clone of VMS; rather, a clone of Unix, so compatibility with f77, f2c, etc. was more important during g77 development than was replicating the VAX/VMS FORTRAN environment (though some of that background did find its way into the g77 front end, at least early on).
Besides, VMS's descriptors weren't just about catering to the CHARACTER type in Fortran, but about a full range of inter-language capabilities that was offered by that architecture. GNU hadn't, and to my knowledge hasn't since, attempted to similarly cater to the (fairly tiny) audience for such a comprehensive range of capabilities. It would have been counterproductive for g77 to try to serve as the launching-pad for such capabilities; just getting the GCC people to recognize the utility of certain optimizations that would help Fortran code was nontrivial.
Whether g95 uses descriptors by default (for FORTRAN-77-compatible CHARACTER types), or sticks with the hidden-argument approach for compatibility with g77-compiled (and f77-compiled and f2c-compiled) code to which its own compiled code might be linked, I don't know. Check the web site. But for some F90 features, much more sophisticated handling of argument-passing to procedures (than g77 ever did) would certainly seem to be necessary.
When I was developing GNU Fortran (g77), one of the other volunteers (Dave Love, I think it was?) used this approach to stress-test the compiler.
It worked great. Caught lots of the usual "duh" kind of bugs, but occasionally caught the "omigod" sort -- the kind of bug that, at first, looks like just another crash, but, upon further investigation, exposes a higher-level flaw in the design or implementation.
I would definitely strongly recommend this kind of testing for any pertinent product while under development.
But it doesn't seem to be good enough for the marketplace.
I'm not sure whether that's because it's ultimately suboptimal in theory (no compilers could ever work around such a design) or in practice (such compilers weren't buildable within the economic and time constraints necessary to make the system, as a whole, meet its original performance goals).
I think that it's all possible.
I think a sufficiently-well-designed system would allow a distribution to consist of not just the raw source, and not the equivalent of today's executables, but of raw source plus something in between the two that allows a final optimization stage to focus optimization resources on the known "hot spots" and, otherwise, use cheap target-specific optimizations to generate the final code upon installation.
I think this sort of system could provide all sorts of advantages over the present architecture, be faster, more reliable, easier to debug, etc.
But, since I might well be wrong, or right but ahead of my time (or possibly behind?), I don't want to start working on it until I can satisfy at least one of the following two criteria:
(Asking a computer to do more work for me means giving it more power to decide how best to approach the task. For example, since I'm "asking" it to allow distributions of pre-digested source leading to faster generation of optimized code upon installation, either I have to design the format of those pre-digested files myself, or I can somehow teach the system to do it itself and maybe produce a better result.)
Accordingly, I've been slowly designing a simple, scaled-down replacement for the Unix OS that is intended to allow me to meet both criteria, or at least the first.
(But I haven't really written much up on it yet -- nothing online, certainly.)
I'm not suggesting anything quite that naive.
Think of it this way: when you install, say, Fedora Core 3 (FC3) on your computer, you are experiencing a delay in startup, in two important ways:
An OS designed from the ground up around source availability would not always suffer the former penalty and could more generally reduce the latter.
Yet, there would be nothing preventing distributing "pre-digested", or pre-compiled, variants of such an OS. Such variants would be, conceptually, little different from use of prefetching or caching at lower levels.
Speaking of lower levels, I do wonder how much faster a given system might be if the CPU didn't provide constant cache-miss and TLB-miss detection, among other things, and left that to the code.
That'd certainly make code-generation more complicated, but that's why we have computers, right?
Meanwhile, inside tight loops, once the code verified that ranges of addresses pertaining to the working set of a loop were in the L1 cache, mapped, etc., the inside-loop references could be substantially faster (premapped to hardware RAM addresses, for example).
Whaddya think?
It can't be that simple, or (and I have often thought about this myself) the fastest general-purpose CPUs would not have dedicated hardware to detect cache misses, TLB misses, etc.
And in a perfect world where complexity management wasn't a problem, indeed, much of what is presently reserved to special functions in a CPU would be instead made available to more-general mechanisms that clever compilers could exploit.
But complexity management is the problem. Move complexity out of the CPU architecture and it either becomes slow (you've serialized and sequentialized everything) or practically impossible for most of its users to properly program in order to regain the performance lost due to naively using the underlying architecture.
Then there's the (apparent, at least to me) fact that dedicated logic can always (?) be "shrink-wrapped" to smaller, faster cores than can equivalent logic implemented via dynamically programmable microcode/nanocode on top of a simpler hardware micro/nano-processor.
After years of trying to teach compilers to take advantage of VLIW (and EPIC) architectures, it still seems best, overall, to leave microinstruction scheduling, dependency analysis, and so on to the hardware via its own run-time analysis.
A simpler instruction set (that leaves low-level optimization to run-time decisions by the CPU) also has the advantage of allowing "vanilla" programs to much more easily run across a wide range of compatible hardware.
(Yes, "fat binaries" or equivalents can make some accommodations, but IMO the way to go, to really take advantage of the sort of theoretical capabilities you and I are talking about, is to run an OS that is beyond GNU in terms of being designed, from the ground up, to always run "source code" at a fundamental level -- that is, treating compilation as a behind-the-scenes activity.)
I started programming when I was 9. By the time I was in my early 20s, I was a "hotshot". I also wrote lousy specs for my software, but, amazingly, the people in the Tech Pubs department said they were generally the best such specs that R&D was turning out.
As a result of realizing my comms skills were poor and having an opportunity for a career change, I accepted a job in that very Pubs department, learned the "trade" of tech writing, ended up in management, won a tech-writing award, set some new standards for accuracy and clarity (especially documenting APIs for the OS), and so on.
Yet, despite all that, I still am quite capable of writing overly long, dense paragraphs, and, if I'm not careful, they can say, precisely and clearly, the opposite of what I intended them to say (that is, a reader can legitimately make the "wrong" conclusion).
And I've seen comments written by programmers who employ the "terse" style, yet still manage to write comments that could be interpreted N different ways. ("This can't exceed 20" -- which means what, exactly?)
It's bad enough depending on code written by people with poor communication skills; it gets worse if they also expect me to depend on their prose to understand what is going on.
Better for programmers to write code and minimal prose, just as I think we'd all prefer tech writers to stick to writing prose and not code (as they often get even sample code wrong).
Not just your favorite; the PRIMOS operating system, and many of its utilities (I started out fixing bugs in FUTIL, the file-utility program that did copying, deleting, renaming, etc. of files), used EQUIVALENCE, as they were written in a kind of FORTRAN 66, along with COMMON, to do what C programmers would ultimately recognize as structs, unions, pointer operations, malloc()'s, and free()'s.
I'm not making this up.
If you figure that out, don't you also need a way to keep the human's eye(s) from focusing on the lower-resolution portions of the display instead of the area you've designed to accommodate high resolution?
(I've often wondered about that.)
Sounds like the keypunch rooms we used to work in back in the '70s!
'-)