Will be slim to none, imho. "A serial process operating on parellel hardware." It seems likely that the comparison was a serial process because a line of cubes, one not the same, is not something you see regularly enough recognize in parellel -- "at a glance", like you do, for instances, faces. I'd bet that after enough repetitions, the mind's pattern matching would kick into action and operate vision in parellel. After all, how many of you still read letter-by-letter?
The conclusion to gain from this experiment is that computer vision systems need to be adaptive and learning. While it's probably not necessary to explicitly program every word into a computer reading system, sitting there and grinding away with OCR on a character-by-character basis is probably a waste of time. The difficulty is in feeding back the brain's (knowledge base's) identifier for a pattern (how do remember what the word "word" looks like well enough that you don't read it letter-by-letter?), determined after a serial examination of a given input, back to the parellel recognition system for training.
I think it's safe to dismiss the 1/10 of a second switch as specific to the situation. I can notice an interval a great deal smaller than that playing Half-Life, and so can you, I'd imagine.
Sure. If your favorite author didn't produce anything, this model assumes that its because his price hasn't been met. You want him to produce something, so you send him the price of a book. Some time later (next month?) the publisher/author/middleman sends you the content that that author has created and you produce your container of choice for it at home. Or, if you value anonymity, you contribute anonymously and go pick up a copy at the anonymous bookstore.
It's basically allowing market forces to come into play: the supply will continue to drop to meet the demand as expressed in money sent to an author. If the supply drops below this demand (for new content, not new copies, remember), the people who have been freeloading will pay up or do without. Since demand for content seems to be rather high currently (as expressed by the number of containers of that content sold), and shows no particular signs of slowing down, I would expect the freeloaders to pay up rather than the authors to shift to a patron-client relationship.
Just like to note that this not "my" thesis -- the Protocol seemed to be a good idea getting the short end of the stick. However --
What if the world doesn't cooperate? And even if it does, then I guess this scheme would then be vulnerable to copyright barbarians at the gates.
I think you're making a mistake by requiring a significant change in the way people do business as a prerequisite. As a consequence, fine, but not as a prerequisite.
All the boards are effectively identical in terms of raw 2D power; some of them (the Matrox boards) are better supported in the accelerated X servers than others. After checking driver support (which shouldn't matter all that much for performance), the only thing that's left is image quality, which is usually a personal preference, once you've gotten to a decent RAMDAC speed. (So you can run at the high graphics professional resolutions like 1600x1200 or whatever at >72 Hz vertical refresh rate.)
I'll respond to some of the concerns raised here in order, after a set of general comments.
First, it's important to realize that the Protocol depends on the assumption that copyright law is already broken, and only becomes valid when that point is reaced. Furthermore, it depends on the notion that the current scarcity model for content can no longer be applied. Some of the comments address this contention ("nobody wants to read novels online"), missing the assumption that we've effectively divorced content from its container.
For example, this is already 90% true in music. After a relatively small initial investment, anyone with a decent computer and a decent netlink can burn their own audio CD's at something like $4 a pop. It becomes increasingly apparent that 'piracy' of musical content is astoundlingly widespread and equally impossible to stop. Music distribution is digital until the point it gets on the wires to your speakers, so it's the perfect example. The cost incurred by the end-user (burning the CD) is a concession to the lack of universal networking, not any particular inability to enjoy the music in another form (i.e. your HD, a flashcard, etc). Similarly, the major obstacle to purely digital distribution of novels and texts is two-fold: first, a universal (de-facto) standard (or a pair, like mp3 and CDA) for distribution of content (ASCII text simply doesn't cut it for a serious work), and a cheap home system for manufacturing the container -- nobody's produced a system for manufacturing paperback novels from a home computer systems. (AFAIK.)
So the Protocol depends on the assumption that we've not only developed a low- or no- cost system for distribution of content (the internet) but also a low- or no- cost system for creation of containers. Otherwise, the whole model breaks because people will be willing to pay for copies of the content -- which, in turn, allows copyright law to be enforced, because there's some central point manufacturing those containers. With those points in mind, let's look at the issues raised.
Does anyone remember how some people were worried about RedHat becoming the hegemonic Linux distributor? Personally, I prefer my tyrants to be American, so I need all of you/.ers to go buy RedHat so that SuSE doesn't take over and force us all to use software with support for the euro mark!
Seriously, the size of SuSE is good news for everybody. Should RedHat, in contradiction of sanity, start doing those things people were worried about, businesses have another large company to call for a Linux distro & hand-holding. If SuSE is "in their heart of hearts a services" company, I'd expect them to do very well in the (corporate) support aspect of things, which is where the money is. Having big corporations use Windows is why Windows is still around, so it's rather important for Linux World Domination (oddly enough, not a registerd trademark of Linus Torvalds).
Off-Topic: Microsoft's applications are what's keeping Windows on the desktop. There's no doubt in my mind that companies would prefer a free, reliable, easier-to-remotely-admininster o/s like Linux *if* it ran Microsoft Office. Combine this with WINE, and I see trouble for the model that Microsoft depends on for its revenue. Solution? Stop wasting time and money on Win2000/NT 5 and go ahead and finish WINE. According to my reading of the WINE license, they can fork the project and close-source the remainder of WINE. This is a classic embrace & extend manuever, and has three benefits for MS. First, it allows them to continue to sell at least a chunk of the O/S (i.e. DirectX 6/7, other API implementations); second, it saves them the enourmous R&D costs of developing a real O/S (i.e. Linux, FreeBSD, or Solaris) and immediately gains them all the benefits thereof; third, it maintains the APIs that Office depends on in the face of the Linux threat, and hence protects their hegemony. It's the same calculation they made porting Office to Macintosh, but even easier: Linux has a larger installed base (and/or more publicitly), and you get the added bonuses of selling something in addition to Office *and* "subverting" a competitor.
-_Quinn Slackware 4.0: because the penguin is never sleeping.
I have a dream. I have a dream that one day, internet users of every bandwidth will see the same bland parabellum. I have dream that they will link hubs together and sing for the joy they have knowing that they've abrogated their rights for the lazy pleasures of not watching or raising their children. I have a dream that one day, some day, we will be able to look to the Chinese and offer to help them with their censorship. My dream is that Americans of every age be freed from the terrible curse of [censored], [censored], [censored], and [censored]! My dream
(This post has been moderated for sarcasm and criticism of President Dole. Do not adjust your internet connection -- we are in complete control.)
Why do so many people seem to have a problem with "free software" as a term? The ambiguity in English that leads to the "free speech, not free beer" distinction serves "us." The vast majority of end-users -- the ones who will kill Windows for us, right? -- don't have the tools to make use of the freedom of study, or the freedom of improvement. (#1 and #3 from the FSF definition.)
The target of the the free software rhetoric can not be the general public, because the general public does not code. They don't care about freedom to study and freedom to change -- what the process is by which "free software" (e.g. "Linux," by which they mean the linux kernel, the GNU utilities, and somebody wrap them up prettily in a distribution) has become better in a concrete technical sense, which leads to a better end-user "experience" -- than conventional software. The vast majority of people will buy a boxed distro at their computer store and be happy to pay $50 for it to get thirty days of hand-holding.
To the vast majority, free software means that it's cheap, (Freedom #2 (redistribution), the the "free beer" freedom) and that's fine by me -- anything that gets someone using Linux (er, a GNU/Linux distro); I have enough confidence in its superiority to the alternatives that I think people will stay with it. And, like most people who don't care about how their car works, as long as it does, it won't be important to them why free software (#1 and #3, here) is better -- just that it is. The more curious we can greet with open arms and explanations.
"Open source" is, without doubt, a business term -- the explanation that the vast majority is content to ignore. The problem lies when it's used as marketing, and not as a tool to achieve the results (better software) that the marketroids talk about; the term extracts freedoms #1 and #3 and calls them a new name. That open source emphasises the not-free-beer aspect is a good thing when you're dealing with questions about why GNU utils and linux are better; the problem is that it -- and the businesses -- have missed an important part of the "magic formula" -- no cost. Charging for your open source product is a bad idea, because it cripples the strength of open source development -- the enourmous pool of developers willing to improve something they work with; by charging for the product, you limit that pool tremendously.
That's not to say that open source but costed products won't get better faster than they would otherwise; the end-users always outnumber the developers for any commercial enterprise, and any appreciable fraction of those end-users being developers substantially increases the number of people working on the product. What it does mean is that free software -- in both senses of the term -- will get better faster. Getting back to my original question: is having two levels of meaning for a phrase such a terrible thing? Most people aren't equipped to understand, and won't even ask about, the second (open source) meaning, and will be content with the first.
There's no need to aggressively proselytize free software; the advantages of a free software approach to development lead to technically superior products, and it sufficient to let the fruit speak for the tree. Technical superiority, I'll admit, will only win by itself on server platforms; but it is much easier to add the necessary to chrome to a healthy car than replace the engine of a sick one.
The objective is always to do useful work. For the longest time in software, that meant adding more to the software -- but that time is past. Nobody uses -- or even tries to -- all the "features" of every program they own (er, liscense). The most common line I hear is, "I just need it for some word-processing." (And maybe a few games on the side.) "The computer" (its O/S and the word-processing app) just need to work, all the time, any time. The attempt to make things just work that had the media's attention for a while was the "information appliance," an attempt to simplify the software to the point where a single company could write and fully debug the software, both O/S and application.
This is obviously the Wrong Way. The Right Way -- which the press has caught on to -- is to use an O/S that already works (Linux, FreeBSD, etc) and free software that already works (Apache, X, etc). The question you keep seeing in the media is a very good one, and it boils down to this: "Can free software write a better Word?" What GUI that better Word runs under is completely immaterial -- though KDE or GNOME have the looks and facilities to make writing such an application simpler than doing it with, say, twm.
I happen to believe that "we" (free software developers) can write that "better Word." We can crow about our achievements in writing a better O/S -- we, without a doubt, have, and it continues to get better -- but the information appliance idea contains an important truth: people don't care about the O/S, only what they can do with "their computer." (I.e. the "desktop market" that Office -- not Windows! -- owns so thoroughly.) If we want "the people" to accept free software in all its meanings, we have to do to the desktop what we did to the server -- which was not proselytize.
A web-server kernel module, which is as fast as Zeus, but at half the CPU usage -- according to one variety on benchmarks.
"...Bjorn Wesen objected to the entire idea, saying that if the web server worked better as a module, it was only an indication that the OS itself was broken and should be fixed."
That sums it up: the fast & easy (IIS) way vs the Right Way.
The question you have to ask in this case is, "how much are my customers willing to pay for support?" Given that these are niche applications (ones with only marginal returns on technical superiority) I doubt that you'd benefit from open source in the conventional manner; it would benefit you in marketing -- where ESR talks about "perceived future value." Allowing a client company access to the source (perhaps you might want to consider a license model where modifications can only be redistributed internally unless they're released back to public) will give them the confidence that your software will be maintainable for its five-year lifetime.
Furthermore, if I understand your situation correctly, your clients are effectively out-sourcing an expensive software development project that would be of at most minimal use to another company. This situation would seem ideal for a model where the 'sale value' pays for the services of one (or more) of your programmers, who would then customize the software to fit the client (preferrably on-location). Your company would extract 'use value' by then charging for that programmer's maintenance visits (number and extent at the client's option) and technical support for those changes. The open-source model here only damages your company if you can't do a better job of code maintenance & support than your client can.
This scenario means that your maintenance & support contracts would have to contain a clause requiring the client company to send codebase changes back to you, so that your support could stay up to date; but the programmer(s) making the changes for the client (the same ones who were either too busy, too few, or too inexperienced to implement this application in the first place) would probably welcome an eye closely familiar with the code checking their changes.
Because it's cheaper and it works better, apparently. As fast as it seems IT is dumping the idea of 'thin' clients, it's picking up on the realization that a Real OS (TM) is much better suited to reducing TCO than any amount of hacking at Windows. Especially where your computers are Java-based ERP apps, there's no reason to run Windows. The under-$1000 PC coupled with linux has all the advantages of a dedicated 'information appliance,' without any of the disadvantages -- and you don't need as heavy a network infastructure to handle them.
Long answer: it depends on the applications and the usage patterns.
(I'm assuming we're talking about practical limits here, not theoretical ones -- the theoretical limit is probably the address space of a cluster's message-passing interface (i.e. 4 billion nodes).)
Some applications -- the so-called "embarassingly parellel" ones -- will scale with nearly no deviation from linear to any number of nodes, because they do loosely-coupled problems. (Which means the result of one part of the parellel computation does not depend on a result from some other parellel computation. The mandlebrot set is a good example of this.)
In general, the more tightly-coupled the problem is, the harder it is to scale, as the amount of data that has to be exchanged pushes the limit of the interconnects. A 32-node cluster constructed on a hub will be faster for loosely-coupled programs than a 24-node cluster on a switch, which could beat the 32-node cluster on a tightly-coupled problem because of communications overhead in the 32-node cluster.
Usage patterns also determine the maximum useful size. If you're at a large lab like Sandia, you can reasonably expect a large number of jobs to be running concurrently, which essentially parellelizes the cluster -- running 6 tightly-coupled programs, each on their own hypercube interconnect, will complete faster than running the six in series, each with the whole cluster.
Unless they plan on shipping this with a 'normal' processor core that then offloads certain chunks of code to the FPGA, the FGPA must know about the context switching and the O/S and all the rest of it -- registers need to be cleaned, pipelines flushed, the base address for the virtual memory needs to be reset, the works. And if its current instruction set is insufficiently generic (i.e. it just finished optimizing the rendering loop) -- it sits there until its gate reconfiguration is done. Modern systems already have the most of the generic accelerations you're talking about ( SSE/3DNow!/MMX; soundcard accelerators, video accelerators, etc...); the benefits of the FPGA disappear if you insist on using them in a strictly generic way.
Regarding the idea that the processor itself will profile its working set: while it's possible, it won't work that well, and special compilers will be necessary for performance. (I'm compiling Quake3, and no matter what else happens, I need to keep this set of gates the same because we'll be returning to the rendering loop very shortly. I also need a generic set of gates to handle the game logic, over here, and I don't want anyone to try and optimize the game logic because it's not worth the effort.) How do I know it won't work well to have the processor itself handle the optimizations? Look at Intel: they've given up on hardware doing the optimizations because it doesn't work well enough to keep their processors busy. If you optimize in the compiler, you can present the FPGA with an area in RAM that contains the proper gate configuration for your program and you get the speedup immediately, without waiting for the optimizer to kick in (which it might never). Even doing on-the-fly optimization in software, where you've got resources to spare, is insanely difficult: look at how late Sun was with its HotSpot tech.
It depends on how you define 'entire' if you want the entire pipeline in hardware or not. Again, it's the trade-off between reconfiguring the FPGAs to be very specifically executing that 100,000 times a second loop blindingly fast and then doing/nothing/ while its gates are rearranged so it/can/ do the 30 times a second bit and making them more general and not have to switch at all. If you're in that inner loop for a substantial enough amount of time, you still gain speed by optimizing it, but much less than you would if you didn't have to switch out. The problem, like I said earlier, is scale. Can this company make an FGPA complex enough that it gains more by doing hardware acceleration of certain chunks of the algorithm than it loses by switching between those accelerations? (Alternatively, is there enough complexity in the FPGA to have a large chunk of the rendering pipeline in hardware AND a general processor core to handle the rest of the code/without/ switching away from rendering pipeline acceleartion?)
The FGPA speed advantage over dedicated chips would come from two sources: i/o overhead and specificity. If the TNT-esque FPGA is sitting in the 'processor core,' the geometry data the FPU-esque FPGA is spitting out doesn't have very far to go before it gets crunched into pixels in the frame buffer. If the FPGA is large enough and deep enough, it can implement larger chunks of the 3D pipeline than the 3D card can, because it doesn't have to be a general (i.e. OpenGL) solution: it will only implement those features which the rendering pipeline uses, and things that aren't accelerated by the 3D card at all. Presumambly, this will make it faster than the equivalent generic accelerator.
AFAIK, FPGAs are not cheaper than dedicated ASICs, although this company might change that...
While the FPGA approach should have great advantages over conventional RISC/CISC approaches, two major problems have to be addressed. First, there's the too little, too late effect: SSE & 3DNow! instructions accelerate in hardware the most common types of instructions, so that those same instructions won't be accelerated in the FPGA by comparison -- and will probably suffer. Performance will be impacted in three major ways: first, the cost of reprogramming the FPGA -- "thousands of times a second" simply isn't that impressive when you're talking about core processor speeds of a gigahertz in the same timeframe. Assuming 10k changes/sec, you're still looking at 100ms to make the change. The problem here is a question of scale: can I fit all of Quake 3's rendering pipeline into the hardware? If I can, it should cream a dedicated processor. If I can't, I lose major amounts of speed switching the gate array, or to using a less-efficient general layout on one part of the array. Second, how deeply can you pipeline a FPGA on the fly? To my understanding, FGPAs are slower and larger than dedicated circuitry, which limits the transistor count if you're looking at a reasonable die size. Pipelining is necessary, even in massively parellel enviroments, to achieving supercomputing speeds; the bottleneck tends to be i/o, which lends the speed advantage to pipelining, which is parellel over time rather than space. (If you can execute 7 instructions simulatenously at 1/7 the speed of the 7-stage pipelining, you lose, because the operands probably won't be ready in time, inserting stall cycles.) Third, the compilers for this architecture will have to be absolutely amazing; as much trouble as Intel is having with EPIC compilers, I'd expect a "massive parellel, tightly coupled" FPGA system to have an even more complicated compiler. Further, in addition to the normal costs associated with context switching, the FPGA will have to switch back to match the configuration it was when the process was switched out, further damaging high-end performance.
Finally, as I mentioned above, i/o is usually the bottleneck with high-speed computing. The FPGA design doesn't offer any compelling advantage there; it doesn't matter how much of the rendering pipeline it can do in hardware if the geometry data can't get there on time.
Sounds like a way to test hardware emulators. You rack up your Pentium II (running Linux) next to your Transmeta ZZ-Plural (running Linux), plug this thing into both of them and wait for a mismatch. The auto-replay stuff mentioned near the end sounds like a means to determine if the error was transient (bit rot) in either machine, by re-running recent history. If the mismatch occurs again, I'd imagine you log it for the engineers to look at and start up a different test run.
On naming: a physicist studies physics; a chemist studies chemistry; a roboticist studies robotics. A farmer farms, a sprinter sprints, a programmer programs. The *ist's are usually academic pursuits ( not always ); the *er's are usually naming what people/do/. A hacker, then, hacks. No problems (except about what a/hack/ is.)
I would guess most/.ers aren't academics; (those that are, according to the above, should be 'computists'); but what does a/.er/do/ (besides read/.)? Well.../I/ write code, I program, I script, I do some system administration, a little web-mastering, some system tweaking, read up on the field, set up hardware and repair systems that go down. Some might call me a hacker.
A quick analogy: compare computers to cars; for most people, they're equally mysterious internally and come with cryptic recommendations for routine maintenance. Car driver::computer user. Simple so far, right? Here's where things begin to break down:
guy at the gas station who checks your fluid levels at the full service pump::hacker
grease monkey::hacker
ASE-certified master mechanic::hacker
engineer who designed the brakes::hacker
artist who designed the looks::hacker
manager in charge of the drivetrain::hacker
manager in charge of that particular make::hacker
(Around here, you start getting to large enough projects (programs) that you're not talking about coding-level individuals anymore.)
You see the problem here? Cracker is a very specific term, one who cracks systems. Hacker? Nobody knows. The real problem with the terminology for people who know & use computers at a level greater than 'car driver': the industry is only now just beginning to mature to the point where jobs are starting to separate out, and we don't/really/ have the words for them all yet. This is behind the recent furor over liscencing software engineers: software engineers (the employee at toyota who designed the brakes for your new camry) want to distinguish themselves from the programmer (the guy who fixed your brakes at meineke), neither of whom wish to be confused with the computer scientist (the physicist who came up with the equations describing how brakes work that the engineer used to check his designs so that the mechanic wouldn't have to fix them as often.) We don't have word that refers to all those different people involved in the auto industry; it's probably a mistake to have one for the computer industry.
Weather: inherently chaotic, but according to a well-known model. Butterfly flaps its wings in India, one week later it rains in New York, sure -- but the weather sats will pick the changes that are necessary to make it rain between day two and day four. (Depending on how much power you throw at the problem, weather is predicatable between three and five days ahead of time.) Also, while weather systems are chaotic, they are also bounded -- I don't care how hard that butterfly flaps its wings, if there's not enough water in the air of new york, it's not going to rain. Basically, weather prediction is all about how much (accuracy and precision) data you can throw at a model and how fast you can crunch that model. Historically susceptible to increases in computing power; no reason to expect that to change now.
Chess: not only a matter of raw horsepower, though Deep Blue had plenty of it, it's also a matter of achieving a complex enough program that it could be *trained*. That people only 'see' two moves deep is compensated for by intution & pattern-matching, two things computers are notoriously bad at. Think about the Turing test: does it matter how something gets done?
Quick question: what's the overlap between Deep Computing and the Grand Challenge problems/projects?
> I personally only find life worth living when I'm coding.
[Insert some job here] is not enough for many people -- if it is for you, props to you for it.
> Will anyone remember you or care after you die > whether or not you played frisbee with your g/f?
Nobody except her, no, but how many better is one than none? Even if -- especially if! -- nobody cares, why bother? What's the point to the daily grind? You sit at home and code all day -- at the end of the day, what have you done? You've... passed another day. Living for pleasure in coding is no less hedonism than living for you daily dose of soma. You might not have a problem with hedonism; you might have what it takes to live alone, but spiritualism is the response of some of those who think there must be something more to life than solitary pleasure.
The point is not that you want to be remembered (though I'd personally like to be) -- the point is that people are asking these sort of questions and not getting any answers.
> not everyone likes all that human interest crap
It was an example, not a gospel. I could have just as easily asked "What's the point, if it doesn't get you laid?" and answered in the same way: there are better things to worry about, and better yet not to worry. When you're 75 and beyond Viagra's help, you'll either conclude that life's not worth living or that there's something more to it sex. Most people seem to end up with option two, and a lot earlier than 75.
Why Matrix over Phantom Menace? Look at the climatic scenes: hacker gets the (goth) girl and then Sees the Code -- Finds the Zone where he can code no wrong. And the Phantom Menace? Annoying child gets lucky; cool Zen master gets butchered by a freak with two speaking lines.
Which sounds like it Could Happen To You?
One question, before I move on to the larger issue: why does it seem to suprise so many people that there's a strong spiritual aspect to geekhood? Given the "Voices from the Hellmouth" series of articles -- and my own experience -- I would be suprised if geeks weren't more spiritual than the average population. Where else do geeks have to turn? Other geeks -- the online community? The online community isn't sufficient in the same way that actors prefer stage: there's a personal connection in being there. That's why so many people talk about 'telepresence.' A full-immersement sim (VR 5) is a way around the problem of teleportation -- it they can't if you're 'really there' does it really matter if you are 'really there' or not? The way things are going, it looks like we'll find out just after I die of old age:)
The same principle of the subjective applies to films like Wag the Dog and The Truman Show: what is 'real'? Think about it: you get up on Monday morning, logon, get your work for the week in an e-mail from your boss -- work which you complain about in a reply to co-worker; their contributions showing up from the `cvs update` you just asked for; you get your news from cnn.com.
At the end of the day, go outside and take a look around. What have you done? It's a nice night, so you decide eat outside. But (like the majority of Americans) you're either single or divorced, and you don't have anyone to eat/with/. And you look up at the stars and ask, What I have done today? And the north wind answers: you didn't see the sunrise for the glare it made on your monitor; you didn't watch the sun set or the birds fly or the flowers bloom because you were busy typing; you didn't notice that the man across the street from you celebrated his 80th birthday by gardening, because that's what he likes to do, and damn it, he won the second world war, so it's his by rights. And the east wind says: another couple thousands Kosovans got shoved out of their homes today, looking at the sky and wondering, America, what's the point of planes? People don't live in the sky. And the south wind replies, the point of planes is to/fly/, to live the dream, and what do you do with the dream made real? You sit in the aisle seat for the legroom, so that it looks like just like a train to you -- and you plug your laptop in and continue to write dry sentences about budgets and forecasts, and the future, when you could be dreaming the present. Why? And the west wind says, Why? Because you have no soul, no art, no craft; your job is tell the computers which numbers to crunch; your only product is a viewgraph that's used once to project a poorly-focused picture in a dark and stuffy briefing room, after which it will recycled, because you'd like to think you're doing something for the enviroment. And at the end of the day you're sitting there with the chicken that Purdue roasted for you hanging off the end your fork, realizing: I did nothing today. Nobody will remember; nobody will care. And you/know/ that the old man across the street could have used some help moving the mulch bags around, and you/know/ that you needed the excercise. And even if that were it, his thanks and then taking a nice shower after sweating for an hour, putting on a clean shirt -- it would have made you feel better and happier than anything else you spend time on the whole day. Think about tommorow -- not alot! -- think about driving down with a handful of flowers to your girlfriend's office and spending her lunch hour in the park tossing a frisbee around and then eating a picnic lunch, just to enjoy her company. And whenever she asks why, just smile; because today is a good day to fly.
Go to sleep tonight and dream of the things that make your life worth living.
I don't *know* about NT's stack, but I would suspect it's woefully ineffecient; I've run tests Linux vs Win95 on the same box, and Linux wins by a minimum margin of four times on everything I've bothered to test, and it's usually higher. (Max Win95 rate is about 40k/s; max Linux is about 200k/s; this is the 2.0.34 kernel with Becker's WD driver.) This really sounds like a hardware solution to a problem in Microsoft's software. (Why, pray tell, should the transfer rate depend on 'getting lucky' with context switching? Did somebody at Microsoft decide that the scheduler worked fine because it didn't lose keyboard strokes?)
Slashdot Mirror
Will be slim to none, imho. "A serial process operating on parellel hardware." It seems likely that the comparison was a serial process because a line of cubes, one not the same, is not something you see regularly enough recognize in parellel -- "at a glance", like you do, for instances, faces. I'd bet that after enough repetitions, the mind's pattern matching would kick into action and operate vision in parellel. After all, how many of you still read letter-by-letter?
The conclusion to gain from this experiment is that computer vision systems need to be adaptive and learning. While it's probably not necessary to explicitly program every word into a computer reading system, sitting there and grinding away with OCR on a character-by-character basis is probably a waste of time. The difficulty is in feeding back the brain's (knowledge base's) identifier for a pattern (how do remember what the word "word" looks like well enough that you don't read it letter-by-letter?), determined after a serial examination of a given input, back to the parellel recognition system for training.
I think it's safe to dismiss the 1/10 of a second switch as specific to the situation. I can notice an interval a great deal smaller than that playing Half-Life, and so can you, I'd imagine.
-_Quinn
Sure. If your favorite author didn't produce anything, this model assumes that its because his price hasn't been met. You want him to produce something, so you send him the price of a book. Some time later (next month?) the publisher/author/middleman sends you the content that that author has created and you produce your container of choice for it at home. Or, if you value anonymity, you contribute anonymously and go pick up a copy at the anonymous bookstore.
It's basically allowing market forces to come into play: the supply will continue to drop to meet the demand as expressed in money sent to an author. If the supply drops below this demand (for new content, not new copies, remember), the people who have been freeloading will pay up or do without. Since demand for content seems to be rather high currently (as expressed by the number of containers of that content sold), and shows no particular signs of slowing down, I would expect the freeloaders to pay up rather than the authors to shift to a patron-client relationship.
-_Quinn
What if the world doesn't cooperate? And even if it does, then I guess this scheme would then be vulnerable to copyright barbarians at the gates.
I think you're making a mistake by requiring a significant change in the way people do business as a prerequisite. As a consequence, fine, but not as a prerequisite.
All the boards are effectively identical in terms of raw 2D power; some of them (the Matrox boards) are better supported in the accelerated X servers than others. After checking driver support (which shouldn't matter all that much for performance), the only thing that's left is image quality, which is usually a personal preference, once you've gotten to a decent RAMDAC speed. (So you can run at the high graphics professional resolutions like 1600x1200 or whatever at >72 Hz vertical refresh rate.)
-_Quinn
I'll respond to some of the concerns raised here in order, after a set of general comments.
First, it's important to realize that the Protocol depends on the assumption that copyright law is already broken, and only becomes valid when that point is reaced. Furthermore, it depends on the notion that the current scarcity model for content can no longer be applied. Some of the comments address this contention ("nobody wants to read novels online"), missing the assumption that we've effectively divorced content from its container.
For example, this is already 90% true in music. After a relatively small initial investment, anyone with a decent computer and a decent netlink can burn their own audio CD's at something like $4 a pop. It becomes increasingly apparent that 'piracy' of musical content is astoundlingly widespread and equally impossible to stop. Music distribution is digital until the point it gets on the wires to your speakers, so it's the perfect example. The cost incurred by the end-user (burning the CD) is a concession to the lack of universal networking, not any particular inability to enjoy the music in another form (i.e. your HD, a flashcard, etc). Similarly, the major obstacle to purely digital distribution of novels and texts is two-fold: first, a universal (de-facto) standard (or a pair, like mp3 and CDA) for distribution of content (ASCII text simply doesn't cut it for a serious work), and a cheap home system for manufacturing the container -- nobody's produced a system for manufacturing paperback novels from a home computer systems. (AFAIK.)
So the Protocol depends on the assumption that we've not only developed a low- or no- cost system for distribution of content (the internet) but also a low- or no- cost system for creation of containers. Otherwise, the whole model breaks because people will be willing to pay for copies of the content -- which, in turn, allows copyright law to be enforced, because there's some central point manufacturing those containers. With those points in mind, let's look at the issues raised.
-_Quinn
Does anyone remember how some people were worried about RedHat becoming the hegemonic Linux distributor? Personally, I prefer my tyrants to be American, so I need all of you /.ers to go buy RedHat so that SuSE doesn't take over and force us all to use software with support for the euro mark!
Seriously, the size of SuSE is good news for everybody. Should RedHat, in contradiction of sanity, start doing those things people were worried about, businesses have another large company to call for a Linux distro & hand-holding. If SuSE is "in their heart of hearts a services" company, I'd expect them to do very well in the (corporate) support aspect of things, which is where the money is. Having big corporations use Windows is why Windows is still around, so it's rather important for Linux World Domination (oddly enough, not a registerd trademark of Linus Torvalds).
Off-Topic: Microsoft's applications are what's keeping Windows on the desktop. There's no doubt in my mind that companies would prefer a free, reliable, easier-to-remotely-admininster o/s like Linux *if* it ran Microsoft Office. Combine this with WINE, and I see trouble for the model that Microsoft depends on for its revenue. Solution? Stop wasting time and money on Win2000/NT 5 and go ahead and finish WINE. According to my reading of the WINE license, they can fork the project and close-source the remainder of WINE. This is a classic embrace & extend manuever, and has three benefits for MS. First, it allows them to continue to sell at least a chunk of the O/S (i.e. DirectX 6/7, other API implementations); second, it saves them the enourmous R&D costs of developing a real O/S (i.e. Linux, FreeBSD, or Solaris) and immediately gains them all the benefits thereof; third, it maintains the APIs that Office depends on in the face of the Linux threat, and hence protects their hegemony. It's the same calculation they made porting Office to Macintosh, but even easier: Linux has a larger installed base (and/or more publicitly), and you get the added bonuses of selling something in addition to Office *and* "subverting" a competitor.
-_Quinn
Slackware 4.0: because the penguin is never sleeping.
I have a dream. I have a dream that one day, internet users of every bandwidth will see the same bland parabellum. I have dream that they will link hubs together and sing for the joy they have knowing that they've abrogated their rights for the lazy pleasures of not watching or raising their children. I have a dream that one day, some day, we will be able to look to the Chinese and offer to help them with their censorship. My dream is that Americans of every age be freed from the terrible curse of [censored], [censored], [censored], and [censored]! My dream
(This post has been moderated for sarcasm and criticism of President Dole. Do not adjust your internet connection -- we are in complete control.)
-_Quinn
Why do so many people seem to have a problem with "free software" as a term? The ambiguity in English that leads to the "free speech, not free beer" distinction serves "us." The vast majority of end-users -- the ones who will kill Windows for us, right? -- don't have the tools to make use of the freedom of study, or the freedom of improvement. (#1 and #3 from the FSF definition.)
The target of the the free software rhetoric can not be the general public, because the general public does not code. They don't care about freedom to study and freedom to change -- what the process is by which "free software" (e.g. "Linux," by which they mean the linux kernel, the GNU utilities, and somebody wrap them up prettily in a distribution) has become better in a concrete technical sense, which leads to a better end-user "experience" -- than conventional software. The vast majority of people will buy a boxed distro at their computer store and be happy to pay $50 for it to get thirty days of hand-holding.
To the vast majority, free software means that it's cheap, (Freedom #2 (redistribution), the the "free beer" freedom) and that's fine by me -- anything that gets someone using Linux (er, a GNU/Linux distro); I have enough confidence in its superiority to the alternatives that I think people will stay with it. And, like most people who don't care about how their car works, as long as it does, it won't be important to them why free software (#1 and #3, here) is better -- just that it is. The more curious we can greet with open arms and explanations.
"Open source" is, without doubt, a business term -- the explanation that the vast majority is content to ignore. The problem lies when it's used as marketing, and not as a tool to achieve the results (better software) that the marketroids talk about; the term extracts freedoms #1 and #3 and calls them a new name. That open source emphasises the not-free-beer aspect is a good thing when you're dealing with questions about why GNU utils and linux are better; the problem is that it -- and the businesses -- have missed an important part of the "magic formula" -- no cost. Charging for your open source product is a bad idea, because it cripples the strength of open source development -- the enourmous pool of developers willing to improve something they work with; by charging for the product, you limit that pool tremendously.
That's not to say that open source but costed products won't get better faster than they would otherwise; the end-users always outnumber the developers for any commercial enterprise, and any appreciable fraction of those end-users being developers substantially increases the number of people working on the product. What it does mean is that free software -- in both senses of the term -- will get better faster. Getting back to my original question: is having two levels of meaning for a phrase such a terrible thing? Most people aren't equipped to understand, and won't even ask about, the second (open source) meaning, and will be content with the first.
There's no need to aggressively proselytize free software; the advantages of a free software approach to development lead to technically superior products, and it sufficient to let the fruit speak for the tree. Technical superiority, I'll admit, will only win by itself on server platforms; but it is much easier to add the necessary to chrome to a healthy car than replace the engine of a sick one.
The objective is always to do useful work. For the longest time in software, that meant adding more to the software -- but that time is past. Nobody uses -- or even tries to -- all the "features" of every program they own (er, liscense). The most common line I hear is, "I just need it for some word-processing." (And maybe a few games on the side.) "The computer" (its O/S and the word-processing app) just need to work, all the time, any time. The attempt to make things just work that had the media's attention for a while was the "information appliance," an attempt to simplify the software to the point where a single company could write and fully debug the software, both O/S and application.
This is obviously the Wrong Way. The Right Way -- which the press has caught on to -- is to use an O/S that already works (Linux, FreeBSD, etc) and free software that already works (Apache, X, etc). The question you keep seeing in the media is a very good one, and it boils down to this: "Can free software write a better Word?" What GUI that better Word runs under is completely immaterial -- though KDE or GNOME have the looks and facilities to make writing such an application simpler than doing it with, say, twm.
I happen to believe that "we" (free software developers) can write that "better Word." We can crow about our achievements in writing a better O/S -- we, without a doubt, have, and it continues to get better -- but the information appliance idea contains an important truth: people don't care about the O/S, only what they can do with "their computer." (I.e. the "desktop market" that Office -- not Windows! -- owns so thoroughly.) If we want "the people" to accept free software in all its meanings, we have to do to the desktop what we did to the server -- which was not proselytize.
-_Quinn
http://www.kt.opensrc.org/kt19990617_23.html#9
A web-server kernel module, which is as fast as Zeus, but at half the CPU usage -- according to one variety on benchmarks.
"...Bjorn Wesen objected to the entire idea, saying that if the web server worked better as a module, it was only an indication that the OS itself was broken and should be fixed."
That sums it up: the fast & easy (IIS) way vs the Right Way.
-_Quinn
The question you have to ask in this case is, "how much are my customers willing to pay for support?" Given that these are niche applications (ones with only marginal returns on technical superiority) I doubt that you'd benefit from open source in the conventional manner; it would benefit you in marketing -- where ESR talks about "perceived future value." Allowing a client company access to the source (perhaps you might want to consider a license model where modifications can only be redistributed internally unless they're released back to public) will give them the confidence that your software will be maintainable for its five-year lifetime.
Furthermore, if I understand your situation correctly, your clients are effectively out-sourcing an expensive software development project that would be of at most minimal use to another company. This situation would seem ideal for a model where the 'sale value' pays for the services of one (or more) of your programmers, who would then customize the software to fit the client (preferrably on-location). Your company would extract 'use value' by then charging for that programmer's maintenance visits (number and extent at the client's option) and technical support for those changes. The open-source model here only damages your company if you can't do a better job of code maintenance & support than your client can.
This scenario means that your maintenance & support contracts would have to contain a clause requiring the client company to send codebase changes back to you, so that your support could stay up to date; but the programmer(s) making the changes for the client (the same ones who were either too busy, too few, or too inexperienced to implement this application in the first place) would probably welcome an eye closely familiar with the code checking their changes.
-_Quinn
Because it's cheaper and it works better, apparently. As fast as it seems IT is dumping the idea of 'thin' clients, it's picking up on the realization that a Real OS (TM) is much better suited to reducing TCO than any amount of hacking at Windows. Especially where your computers are Java-based ERP apps, there's no reason to run Windows. The under-$1000 PC coupled with linux has all the advantages of a dedicated 'information appliance,' without any of the disadvantages -- and you don't need as heavy a network infastructure to handle them.
-_Quinn
How large can a cluster be?
Short answer: it depends.
Long answer: it depends on the applications and the usage patterns.
(I'm assuming we're talking about practical limits here, not theoretical ones -- the theoretical limit is probably the address space of a cluster's message-passing interface (i.e. 4 billion nodes).)
Some applications -- the so-called "embarassingly parellel" ones -- will scale with nearly no deviation from linear to any number of nodes, because they do loosely-coupled problems. (Which means the result of one part of the parellel computation does not depend on a result from some other parellel computation. The mandlebrot set is a good example of this.)
In general, the more tightly-coupled the problem is, the harder it is to scale, as the amount of data that has to be exchanged pushes the limit of the interconnects. A 32-node cluster constructed on a hub will be faster for loosely-coupled programs than a 24-node cluster on a switch, which could beat the 32-node cluster on a tightly-coupled problem because of communications overhead in the 32-node cluster.
Usage patterns also determine the maximum useful size. If you're at a large lab like Sandia, you can reasonably expect a large number of jobs to be running concurrently, which essentially parellelizes the cluster -- running 6 tightly-coupled programs, each on their own hypercube interconnect, will complete faster than running the six in series, each with the whole cluster.
-_Quinn
Unless they plan on shipping this with a 'normal' processor core that then offloads certain chunks of code to the FPGA, the FGPA must know about the context switching and the O/S and all the rest of it -- registers need to be cleaned, pipelines flushed, the base address for the virtual memory needs to be reset, the works. And if its current instruction set is insufficiently generic (i.e. it just finished optimizing the rendering loop) -- it sits there until its gate reconfiguration is done. Modern systems already have the most of the generic accelerations you're talking about ( SSE/3DNow!/MMX; soundcard accelerators, video accelerators, etc...); the benefits of the FPGA disappear if you insist on using them in a strictly generic way.
Regarding the idea that the processor itself will profile its working set: while it's possible, it won't work that well, and special compilers will be necessary for performance. (I'm compiling Quake3, and no matter what else happens, I need to keep this set of gates the same because we'll be returning to the rendering loop very shortly. I also need a generic set of gates to handle the game logic, over here, and I don't want anyone to try and optimize the game logic because it's not worth the effort.) How do I know it won't work well to have the processor itself handle the optimizations? Look at Intel: they've given up on hardware doing the optimizations because it doesn't work well enough to keep their processors busy. If you optimize in the compiler, you can present the FPGA with an area in RAM that contains the proper gate configuration for your program and you get the speedup immediately, without waiting for the optimizer to kick in (which it might never). Even doing on-the-fly optimization in software, where you've got resources to spare, is insanely difficult: look at how late Sun was with its HotSpot tech.
-_Quinn
It depends on how you define 'entire' if you want the entire pipeline in hardware or not. Again, it's the trade-off between reconfiguring the FPGAs to be very specifically executing that 100,000 times a second loop blindingly fast and then doing /nothing/ while its gates are rearranged so it /can/ do the 30 times a second bit and making them more general and not have to switch at all. If you're in that inner loop for a substantial enough amount of time, you still gain speed by optimizing it, but much less than you would if you didn't have to switch out. /without/ switching away from rendering pipeline acceleartion?)
The problem, like I said earlier, is scale. Can this company make an FGPA complex enough that it gains more by doing hardware acceleration of certain chunks of the algorithm than it loses by switching between those accelerations? (Alternatively, is there enough complexity in the FPGA to have a large chunk of the rendering pipeline in hardware AND a general processor core to handle the rest of the code
We'll just have to wait and see.
-_Quinn
The FGPA speed advantage over dedicated chips would come from two sources: i/o overhead and specificity. If the TNT-esque FPGA is sitting in the 'processor core,' the geometry data the FPU-esque FPGA is spitting out doesn't have very far to go before it gets crunched into pixels in the frame buffer. If the FPGA is large enough and deep enough, it can implement larger chunks of the 3D pipeline than the 3D card can, because it doesn't have to be a general (i.e. OpenGL) solution: it will only implement those features which the rendering pipeline uses, and things that aren't accelerated by the 3D card at all. Presumambly, this will make it faster than the equivalent generic accelerator.
AFAIK, FPGAs are not cheaper than dedicated ASICs, although this company might change that...
-_Quinn
While the FPGA approach should have great advantages over conventional RISC/CISC approaches, two major problems have to be addressed. First, there's the too little, too late effect: SSE & 3DNow! instructions accelerate in hardware the most common types of instructions, so that those same instructions won't be accelerated in the FPGA by comparison -- and will probably suffer. Performance will be impacted in three major ways: first, the cost of reprogramming the FPGA -- "thousands of times a second" simply isn't that impressive when you're talking about core processor speeds of a gigahertz in the same timeframe. Assuming 10k changes/sec, you're still looking at 100ms to make the change. The problem here is a question of scale: can I fit all of Quake 3's rendering pipeline into the hardware? If I can, it should cream a dedicated processor. If I can't, I lose major amounts of speed switching the gate array, or to using a less-efficient general layout on one part of the array. Second, how deeply can you pipeline a FPGA on the fly? To my understanding, FGPAs are slower and larger than dedicated circuitry, which limits the transistor count if you're looking at a reasonable die size. Pipelining is necessary, even in massively parellel enviroments, to achieving supercomputing speeds; the bottleneck tends to be i/o, which lends the speed advantage to pipelining, which is parellel over time rather than space. (If you can execute 7 instructions simulatenously at 1/7 the speed of the 7-stage pipelining, you lose, because the operands probably won't be ready in time, inserting stall cycles.) Third, the compilers for this architecture will have to be absolutely amazing; as much trouble as Intel is having with EPIC compilers, I'd expect a "massive parellel, tightly coupled" FPGA system to have an even more complicated compiler. Further, in addition to the normal costs associated with context switching, the FPGA will have to switch back to match the configuration it was when the process was switched out, further damaging high-end performance.
Finally, as I mentioned above, i/o is usually the bottleneck with high-speed computing. The FPGA design doesn't offer any compelling advantage there; it doesn't matter how much of the rendering pipeline it can do in hardware if the geometry data can't get there on time.
-_Quinn
Sounds like a way to test hardware emulators. You rack up your Pentium II (running Linux) next to your Transmeta ZZ-Plural (running Linux), plug this thing into both of them and wait for a mismatch. The auto-replay stuff mentioned near the end sounds like a means to determine if the error was transient (bit rot) in either machine, by re-running recent history. If the mismatch occurs again, I'd imagine you log it for the engineers to look at and start up a different test run.
-_Quinn
> Don't you mean ZZ9 Plural Z Alpha
I didn't have my Guide handy, so I tried to use the first half and not the second -- because we've already got a chip named the 'Alpha'...
-_Quinn
On naming: a physicist studies physics; a chemist studies chemistry; a roboticist studies robotics. A farmer farms, a sprinter sprints, a programmer programs. The *ist's are usually academic pursuits ( not always ); the *er's are usually naming what people /do/. A hacker, then, hacks. No problems (except about what a /hack/ is.)
/.ers aren't academics; (those that are, according to the above, should be 'computists'); but what does a /.er /do/ (besides read /.)? Well... /I/ write code, I program, I script, I do some system administration, a little web-mastering, some system tweaking, read up on the field, set up hardware and repair systems that go down. Some might call me a hacker.
/really/ have the words for them all yet. This is behind the recent furor over liscencing software engineers: software engineers (the employee at toyota who designed the brakes for your new camry) want to distinguish themselves from the programmer (the guy who fixed your brakes at meineke), neither of whom wish to be confused with the computer scientist (the physicist who came up with the equations describing how brakes work that the engineer used to check his designs so that the mechanic wouldn't have to fix them as often.) We don't have word that refers to all those different people involved in the auto industry; it's probably a mistake to have one for the computer industry.
I would guess most
A quick analogy: compare computers to cars; for most people, they're equally mysterious internally and come with cryptic recommendations for routine maintenance. Car driver::computer user. Simple so far, right? Here's where things begin to break down:
guy at the gas station who checks your fluid levels at the full service pump::hacker
grease monkey::hacker
ASE-certified master mechanic::hacker
engineer who designed the brakes::hacker
artist who designed the looks::hacker
manager in charge of the drivetrain::hacker
manager in charge of that particular make::hacker
(Around here, you start getting to large enough projects (programs) that you're not talking about coding-level individuals anymore.)
You see the problem here? Cracker is a very specific term, one who cracks systems. Hacker? Nobody knows. The real problem with the terminology for people who know & use computers at a level greater than 'car driver': the industry is only now just beginning to mature to the point where jobs are starting to separate out, and we don't
-_Quinn
Weather: inherently chaotic, but according to a well-known model. Butterfly flaps its wings in India, one week later it rains in New York, sure -- but the weather sats will pick the changes that are necessary to make it rain between day two and day four. (Depending on how much power you throw at the problem, weather is predicatable between three and five days ahead of time.) Also, while weather systems are chaotic, they are also bounded -- I don't care how hard that butterfly flaps its wings, if there's not enough water in the air of new york, it's not going to rain. Basically, weather prediction is all about how much (accuracy and precision) data you can throw at a model and how fast you can crunch that model. Historically susceptible to increases in computing power; no reason to expect that to change now.
Chess: not only a matter of raw horsepower, though Deep Blue had plenty of it, it's also a matter of achieving a complex enough program that it could be *trained*. That people only 'see' two moves deep is compensated for by intution & pattern-matching, two things computers are notoriously bad at. Think about the Turing test: does it matter how something gets done?
Quick question: what's the overlap between Deep Computing and the Grand Challenge problems/projects?
-_Quinn
> I personally only find life worth living when I'm coding.
... passed another day. Living for pleasure in coding is no less hedonism than living for you daily dose of soma. You might not have a problem with hedonism; you might have what it takes to live alone, but spiritualism is the response of some of those who think there must be something more to life than solitary pleasure.
[Insert some job here] is not enough for many people -- if it is for you, props to you for it.
> Will anyone remember you or care after you die
> whether or not you played frisbee with your g/f?
Nobody except her, no, but how many better is one than none? Even if -- especially if! -- nobody cares, why bother? What's the point to the daily grind? You sit at home and code all day -- at the end of the day, what have you done? You've
The point is not that you want to be remembered (though I'd personally like to be) -- the point is that people are asking these sort of questions and not getting any answers.
> not everyone likes all that human interest crap
It was an example, not a gospel. I could have just as easily asked "What's the point, if it doesn't get you laid?" and answered in the same way: there are better things to worry about, and better yet not to worry. When you're 75 and beyond Viagra's help, you'll either conclude that life's not worth living or that there's something more to it sex. Most people seem to end up with option two, and a lot earlier than 75.
-_Quinn
Please remove duplicate. My apologies.
Why Matrix over Phantom Menace? Look at the climatic scenes: hacker gets the (goth) girl and then Sees the Code -- Finds the Zone where he can code no wrong. And the Phantom Menace? Annoying child gets lucky; cool Zen master gets butchered by a freak with two speaking lines.
:)
/with/. And you look up at the stars and ask, What I have done today? And the north wind answers: you didn't see the sunrise for the glare it made on your monitor; you didn't watch the sun set or the birds fly or the flowers bloom because you were busy typing; you didn't notice that the man across the street from you celebrated his 80th birthday by gardening, because that's what he likes to do, and damn it, he won the second world war, so it's his by rights. And the east wind says: another couple thousands Kosovans got shoved out of their homes today, looking at the sky and wondering, America, what's the point of planes? People don't live in the sky. And the south wind replies, the point of planes is to /fly/, to live the dream, and what do you do with the dream made real? You sit in the aisle seat for the legroom, so that it looks like just like a train to you -- and you plug your laptop in and continue to write dry sentences about budgets and forecasts, and the future, when you could be dreaming the present. Why? And the west wind says, Why? Because you have no soul, no art, no craft; your job is tell the computers which numbers to crunch; your only product is a viewgraph that's used once to project a poorly-focused picture in a dark and stuffy briefing room, after which it will recycled, because you'd like to think you're doing something for the enviroment. And at the end of the day you're sitting there with the chicken that Purdue roasted for you hanging off the end your fork, realizing: I did nothing today. Nobody will remember; nobody will care. And you /know/ that the old man across the street could have used some help moving the mulch bags around, and you /know/ that you needed the excercise. And even if that were it, his thanks and then taking a nice shower after sweating for an hour, putting on a clean shirt -- it would have made you feel better and happier than anything else you spend time on the whole day. Think about tommorow -- not alot! -- think about driving down with a handful of flowers to your girlfriend's office and spending her lunch hour in the park tossing a frisbee around and then eating a picnic lunch, just to enjoy her company. And whenever she asks why, just smile; because today is a good day to fly.
Which sounds like it Could Happen To You?
One question, before I move on to the larger issue: why does it seem to suprise so many people that there's a strong spiritual aspect to geekhood? Given the "Voices from the Hellmouth" series of articles -- and my own experience -- I would be suprised if geeks weren't more spiritual than the average population. Where else do geeks have to turn? Other geeks -- the online community? The online community isn't sufficient in the same way that actors prefer stage: there's a personal connection in being there. That's why so many people talk about 'telepresence.' A full-immersement sim (VR 5) is a way around the problem of teleportation -- it they can't if you're 'really there' does it really matter if you are 'really there' or not? The way things are going, it looks like we'll find out just after I die of old age
The same principle of the subjective applies to films like Wag the Dog and The Truman Show: what is 'real'? Think about it: you get up on Monday morning, logon, get your work for the week in an e-mail from your boss -- work which you complain about in a reply to co-worker; their contributions showing up from the `cvs update` you just asked for; you get your news from cnn.com.
At the end of the day, go outside and take a look around. What have you done? It's a nice night, so you decide eat outside. But (like the majority of Americans) you're either single or divorced, and you don't have anyone to eat
Go to sleep tonight and dream of the things that make your life worth living.
-_Quinn
I don't *know* about NT's stack, but I would suspect it's woefully ineffecient; I've run tests Linux vs Win95 on the same box, and Linux wins by a minimum margin of four times on everything I've bothered to test, and it's usually higher. (Max Win95 rate is about 40k/s; max Linux is about 200k/s; this is the 2.0.34 kernel with Becker's WD driver.) This really sounds like a hardware solution to a problem in Microsoft's software. (Why, pray tell, should the transfer rate depend on 'getting lucky' with context switching? Did somebody at Microsoft decide that the scheduler worked fine because it didn't lose keyboard strokes?)
-_Quinn