Unfortunately most of us live in capitalist societies where the price of something is based on the market demand for that something and has very little to do with the actual cost of that something.
Well, once the widget has been made this is true. This is why lots of analysis is done to figure out what people might pay. If those numbers are too low, then the comodity won't be produced. Likewise, when you have an excess, and the market sale price is too low, you may opt to do something other than sell it.. For example, if I have a car, and the resale value is too low, I might strip it down and sell the pieces.
You say unfortunately, but this is a very efficient model. In the case of essential goods, the government can step in an regulate (such as the power industry, telephone, welfare, etc). In a non-market-based society, it's like having every resource regulated, which makes most services sold at inefficient levels. Often, there are pricing departments that supposedly try and find the "right" levels, but the market is too dynmic. This year, more people will want to buy the PT cursuer than next. How can you best determine who gets what? Is it first come first serve? Or should the market price adapt based on Supply and Demand, and the very first are just lucky, while towards the end, only those that really want it (or happen to be rich) get it. The difference is that it's more difficult to determine who really deserves to get the widget a-priori. Much like it's more difficult to maintain accounting on IP or CPU traffic for the entire net.
Ouch. I assume thats in addition to the shared memory (of course -- what else could it be? You say "per worker process"). So, I suppose you're looking looking at a 25 - 35 meg httpd daemon. That's pretty darned heavy
When you start using things like embPerl (a php-like extension to perl), and you have a large project (dozens of perl modules), all cached in memory, you can easily bring your perl-space alone to 6- 12 meg. With mod-perl off, Apache is like 2-3 meg per worker for me. With everything turned on, I usually get 10meg... If you don't properly manage your perl code, then things like database accesses can consume a meg or more for a single variable.. This is hard to de-allocate in such a way to free up the process's memory space.. That coupled with fragmentation can grow your memory size considerably. It's virtual memory, to be sure, but it still counts as disk swapping.
The size of the daemon totally depends on how much code is loaded at apache startup time.. If your.htaccess files actually load the code, then your workers are going to be larger than the central daemon. If the size is due to dynamicaly loaded data, then each worker will be a different size... I've had all of these situations occur.
I suppose, though, that no-one thought to make perl interact well with copy-on-write memory semantics. It would be cool if it did.
Well, so long as you initialize _all_ your perl code in your httpd.conf or vhost files, then you'll get essentially that. Anything generated after the dameon spawns off workers is lost, needs to be reloaded / recompiled. In the first case, you take advantage of UNIX's copy-on-write. This means most of the constant data-sections (namely the in-memory text copy of the perl source code), won't be physically duplicated.
Unfortunately, unlike most programs, most of perl's memory is writable. Meaning, you have the core perl-interpreter which is static code, then you have the hundreds of K of perl-code-text, and their intermediate meta-data or compiled form. This compiled form does not get shared between forks, since the execution tree can change over-time. At the very least, it can't be registered as "shared memory", since it's possible for the contents to change. At best, you have multiple forked processes temporarily sharing a segment with the copy-on-write flag set. If ANYTHING in that 2, 4 or 8K page changes, you have to copy out the code.
Could you explain what you mean by "the cache lines are valid for all threads." Obviously, the code cache is going to be valid (just like in Unix, obviously), and the data cache is also going to be valid (unfortunitely, not like unix). But is the stack cache going to be valid?
Ok, thinking this over, I may not have all my facts straight. I know that the x86 uses a legacy addressing scheme, unlike most modern CPU's which have a flat virtual address space, the x86 uses segment selectors. This allows a process to utilize two segments that have the exact same virtual address but really be mapped to totally different physical addresses. A segment is an offset to the CPU address register which occurs prior to page-table mapping. It also provided an upper address bound to provide a first-tier memory-protection scheme.. It worked great in the 386 days, but in our UNIX flat-virtual-memory model it's not terribly useful. I think NT still uses it for some optimization tricks.
My problem is that I do not know exactly how Linux deals with this.. My assumption was that since each process got it's own segment selector, it would have a completely different virtual memory offset, and thus the addresses that the cache lines get are different for each process. From this, I assumed that two context switches would require cache-flushing. If anyone knows differently, please come forward. If this were true (as I assumed), then MT would have the added benifit of sharing a segment selector, and thus not requiring a cache flush.
As you can see, if my original assumption was correct, then none of the code, or data cache lines would be valid. If I was incorrect, then it's just like most any other processor. Both your code and data lines are valid for all MT context switches. It's true that you have independant stacks for threads, but they're in the same memory space, they shouldn't do too much harm to each other's cache. With MP, even here, you have the issue of starving neighboring process's data caches, since for for all copy-on-write operations, you have additional memory to cache and compete against. Still, unless my origional assumption was true, none of this really will affect much.
Also, what on earth can you possibly mean when you say "the apache processes run round robin". When did apache start including a task scheduler? Will it start coming with disk drivers soon, too?
Ok, I have made assumptions based on empirical evidence. The daemon process opens port 80 (or what-ever), THEN forks off a bunch of processes with port 80 still open.. This is a very bizzar situation. Normally you'd think of it as simply having the forked processing maintaining the file-handle from the original guy. For STDOUT, it's just the luck of the draw who prints out in which order when they're both performing prints. But for server TCP sockets, things get wierd. Lets say the central daemon never listens to sockets (
it's main role is to monitor the number of workers and fork off working copies as necessary), but all 5 of your workers ARE listening on that same socket. What happens when a browers establishes a connection on port 80? You have 5 guys listening and waiting to accept a new connection, which gets it? Well, it's the OS's job to decide, and evidence on my installtion suggests it's round robin.
Here's how I did my experiement. I used mod perl in order to have a persistent memory structure. I went to a web page that would print out to the screen it's process id (since it was mod-perl, it was the same ID as that of the worker). You'd think that you'd always use the first worker, and only use additional workers if the first was busy. But instead, I'd get a random worker. I don't recall if I worked out whether it was indeed round robin.
Think of it like MT with cond_wait and cond_signal.
All workers cond_wait on the port-connection. A seperate thread (the kernel in this case) finds a new connection to port 80, so it signals a cond_signal, and some undetermined guy wakes up first and establishes the connection.. The other guys go back to sleep until the next cond_signal. When the worker is done with the connection, it does another cond_wait, reentering itself to the queue.
The most simple implementation of such a conditional broadcasting structure would be to have a round-robin queue. cond_signal activates the guy at the head of the queue, and all people initiating cond_wait go to the end of the queue.
All of this is hidden by the socket "accept" function call, which should just be an interface into the inet kernel routines. I don't know how much of libnet is done in user space and how much in kernel space, but I'm sure that no actual MT programming is going on, since I don't see any IPC resources being consumed when children listen to the same socket.
To experiement on your own, just do the following (written in perl code for brevity).
#!/usr/bin/perl
use IO::Socket;
$sock = new IO::Socket::INET( Listen => 5, LocalPort => 5000, Reuse => 1 );
Then repeatedly telnet to port 5000, and watch how it cycles.
I just tried it out, and it produces 4 processes. Telneting shows me that at least on my implementation with this few processes it is perfectly round-robin. This may not be the general case, but we can't deny that having 50 web servers is always going to spawn the first one (thereby reusing it's cach lines). If I am correct, then if you are underloaded, then having 50 apache processes will actually hurt your performance (especially if any of it goes out to disk).
I was assuming that much. We're talking about 500 THOUSAND connections though. I seriously doubt that a single connection is going to have 499,999 image links.:)
putting something complex like a webserver (or browser for that matter) into kernelspace is just asking for it
I assume you mean IE. I was under the impression that IE did NOT live in OS-space. I base this on the fact that when i?explorer dies, I can restart it without affect independant proceses (course, if anyone had a file-dialog box open, they'd freeze too).
Please correct me if I'm wrong, but Windows runs their utility DLL's in user-space. It's only the vxd's (for the win 9x world that is) that runs in kernel-space. Likewise NT 4.0 didn't let any utilities in that space. 4.0 allowed all things video to probagate, but that was it. No clue about 2k.
Hmm, I'd be curious to learn more about TUX. I was wondering what kind of performance you could get if you used an X-type event model using UNIX's select. Divide your apps into tiny chunks that take very little time each, give the apps priority queue's where tasks that take longer than one time-unit queue subsequent activities on lower-prio-q's. Then periodically poll for IO (for both disk-reads and Socket activity).
This is kind of like an RT system, where IO is garunteed to not be pending for longer than a certain amount of time. This allows thousands or millions of simultaneous connections with only the overhead of short-term context-information.
You get very fast connection-response time, and you could internally prioritize activities so as to minimize overloading (though this probably couldn't be true in general).
The bueaty of the system is that if you actually HAD multiple CPU's you could run multiple worker processes in a very similar fashion as Apache currently does. From this, there would be no incentive to run more workers than CPU's, since a given worker can handle an infinite number of connections (limited only by practicality).
This obviously wouldn't not support external API's such as CGI or mod-perl, though it MIGHT work with FastCGI or servlets, since all you need do is probagate IO.
With Apache everything is running in user space as multiple processes - Speed Hit Here?
Yup, The apache processes run round robin (far as I know), and that means that you have to flush the CPU cache for each new connection (rotating the memory space). Note, this won't be noticable for anything but the heaviest loads (since regularly scheduled OS context-switches will have the same effect). Additionally, unless you put in enough memory, you're going to have to swap to disk throughout the rotation. This is likely when you have large mod-perl code (I've gotten apache up to 20 meg / worker-process). Additionally, AFAIK, all IO caching is redundant with MP. I THINK there was a shared memory segment that resolved this, but I don't know.
An MT version has no such problem, since the cache lines are valid for all threads, AND if you had 40 threads with 4 - 12 Meg each, it's unlikely that you'll push yourself out to disk.
We're assuming, of course that nobody is using flat-out CGIs. If anyone was, then Apache would win out-right. In a single-tasked, MT environment, you have to initiate an entirely new process space, and before that, you'd have to configure your environment. In Apache, you have ready-to-go worker-processes than can easily exec the CGI, a new worker thread is recreated at a later time. In Windows, I believe there is less process-creation overhead than in UNIX (assumption based on the non-forked model of windows), so the distinction may not be as great.
I definately agree with the added stability inherent with discrete processes. However, it can actually be harder to debug when you have faulty embedded applications (mod-perl), since each worker will have a seperate work-space, you get a different answer every web-page access. Course, on the other hand, MT perl is even less secure.
With MT, you have all the fun of race-conditions and hidden shared variables that clobber each other. Debugging that can be a nightmare. IIS gives you their equivalant of perl / visual basic. I don't really know much about it, but I speculate that it's more integral to IIS than perl is to Apache, and thus is more efficient. Not to mention, perl wasn't designed for the web whereas ASP was.
Now I know we're not focusing on perl here; you could very easily substitute php, or SSI static pages. I discount servlets, since most of your processing time supposedly is taken up in the servlet, and that's independant of the web-server. I assume that servlets are available (in one form or another) for IIS. Hell, if you really liked servlets, you would use it AS the web server.
I've heard that Apache is comming out with an MT version, BUT, here's the problem. In a windows platform, you still have all the negatives of being in server windows platform. Not to mention, Apache is a text-file configuration while windows is a gui based configuration. The two do not mix well. In the UNIX environment, however, our kernel MT model leaves much to be desired. I vaguely recall reports that showed how poorly Linux did in MT compared to other platforms (obviously Solaris, but I think we even lost to Windows). If you compare MT Apache on Linux to Windows, you might get a nasty surprise. I don't know if the situation has been improved for the 2.4 kernel. Hell, Linux isn't even POSIX compliant with MT.
For simple static-page serving, MT apache should accel. Highly optimized C code in tight loops with a fixed number of worker threads could do magic. This avoids all that BS VC++ MFC stuff. But unfortunately, you can't make a sophisticated business around static pages (unless you're into pr0n I guess).
I would like to propose that it would be impossible (take that as a challenge if you like.. I don't mind), to successfully inhabit any other planet around Sol.
In order for life to exist, you need variety (Note this says nothing about the origin of that life). There also needs to be massive feed-back loops in the environment / ecosystem.
We have had multiple past failed attempts at the Geo-dome (or what-ever it's called). I lost interest in it after the first major flop, so they might have had some prolonged success since then. One of the major problem was that you couldn't control the paracitic life-forms. Much like the situation of importing a new animal life-form to a region; you affect the feed-back system in a dramatic way, which may or may not be stable.
On Earth, our Bio-domes have a safety net (you can leave the dome if things go wrong). On a hostile world, you may not have that luxury. It is human arrogance to assume that we'll be able to adapt to the situation. We're de-evolving as a people as it is. We're less required to adapt to situation, since we're "standardizing" our environments.
Recently, I've read Arthor C Clark's "Rama" series, and there is an interesting and very subtle side-plot involving the colonization of other planets. In the first book, it is assumed that we'll have colonized all the other planets. Mercury, for example, though brute force due to the supposed energy sources abundant there (read solar). Then, for what I can only assume was plot convinience, in the second book, there was another massive great Chaos (similar in effect to the great depression) which started on Earth. It destroyed all the economics and social infrastructures of every planet (since obviously everyone was dependant on everyone else). It is implied that the colonists all perished.
In the movie 2010 (another by Arthor C Clark), we saw a glimps of what can happen when those in space have to deal with political squabbling back home. Though total anarchy or great depressions may not decimate a remote colony, home-wars very well could - Trade routes could be blocked (for fear of feeding the enemy).
My point in all this is to remove the utopian "start over" that occured on terrestrial colonies. We had the exact same resources in the new Americas that we did in the Europes. Here we're talking about the ability of man to terraform another world. We can't even do this on a smaller scale currently. My guess is that we have not the capacity to comprehend the dynamics of an ecosystem sufficiently to play God with an entire planet.
From this, my suggestion (for hope) is that we must learn to travel great distances (to other solar systems) and find other pre-existing eco-systems - The class-M planet if you will. This will be closer to discovering new land, and will be far less of an engineering feet than building a planet from the undersoil-up. Assuming the travel is long (at least relative to the inhabitants of the world.. read relativity), we will find a situation very similar to the original explorers, which I find to be rather poetic. We'd reintroduce the majesty of sailing ships and their long perelous voyage. Well beyond the reach of the established governmental society gone bad.
We're getting better at theoretical deep space drives (read ion-propulsion), so it's just a matter of getting you there fast enough your food and energy supplies don't run out. Probes probably aren't that practical since relativity would have them returning hundreds of years in the future. I like to think of it more like the Battle-tech saga with the Clan's and their deep space exhile.
As a possible scenareo...
Step 1:
Research _miniature_ externally fueled eco-systems. Nothing as grand a scale as Bio-dome, since I don't believe it's possible to be 100% self-contained AND be stable. Design constraints involve a limitless power-source (no sun out in deep-space), plus the ability to totally recycle minerals (If you can fuse atoms, you can split / make ionic bonds.. We would do well to put research into plant-micro-physics).
Step 2:
progress propulsion systems (along with the above power-source) for moderate / constant acceleration with a near c (.75 -.999) upper-bound. Note this doesn't mean we can travel this fast, just that we would never achieve the max velocity, even after years of travel. At a minimum, this gives you artificial gravity.
Step 3:
Advance observational sensors so as to identifiy possible planetary candidates; Those with similar ambient temperatures and other such atmospherics. It's more likely that we'd have to adapt as a race to the new chemical makeup abroad than to attempt to recreate Earth's atmosphere.. Those that live there long enough would probably never be able to return to Earth. The goal would be to reproduce often to offset the eminant fatalities.
Who knows, this might provide evidence that Darwin was wrong (maybe we _were_ engineered for a specific habitat, and we're unfit for anything else). If that's the case, then we'll just have to accept our fate. But that's not a very useful conclusion.
Step 4:
Advance biological understanding. We only have two choices in adaptation: We can either use natural selection and hope that what-ever larger force is active (either statistics or supernatural intervention(read either God or benevolant aliens)) is on our side, OR we learn to control the mutations of our bodies.
This method currently isn't socially acceptible. But the minimal requirement would be to achieve 90% understanding of how our bodies would react under varying conditions - In the hopes of developing counter-measures.
Step 4:
Kiss your wives good-bye and take a journey.
Realize that this too is sci-fi. But I find it more plausible, since it's based on the exact same challenge as not too long ago - Build bigger, faster, more robust ships, guess how many resources you needed to make a journey, and make lots of failed attempts (with real lives at stake).
Part of the drama is that many of those worlds will be hazzardous to us. Hopefully, our terrestrial observation points will be able to weed out the bad candidates.
In short, don't pretend for one minute that Star Trek is science-fiction. It is purely space-fantancy, based on little factual evidence. Any colonization out of this world would involve factors far beyond our near-term capabilities. To make things worse, the establishment is hindering further development of the sorts of radical new sciences required to progress towards colonization. Leaps are made when a totally new paradigm is used. Traditional education biases our minds, and leads us back to the same wrong turns that have generally been accepted.
We need more true science-fiction. More theoreticians, and sadly, more cataclysmic events that drive our global values towards change and evolution.
So why isn't CVS patented then? Or for that matter, why has nobody thought to patent an Office suite, or the concept of an operating system. Hell, a device that adds numbers should be able to be patentable even today (provided the method is bizzar enough).
Folks, are we the whining majority ignorant of the true evils that patenting foster?
Patents are supposed to foster new technology. They assure rewards for the hard/expensive labor required in R&D. There is a similar situation for copy-rights. Software has copyrights/lefts to prevent the free rider problem, but now patents are being applied in totally inappropriate ways.
What development time is spent figuring out that you can press a button and purchase something? What development time is there to "figure out that you can do a complete process on the web"? Sure, it takes R&D to make the actual software, and if it can be shown that someone has blatantly reused code and logic from your work, then you can sue them (in essence, forcing competitors to do their own work). But what we have here is the great "idea grab".
The government is selling off ideas to the first people that can think of something no-one else has _registered_. This is a total perversion of the goals. Blind enforcement of the system is going to lead to the ownership (and hence leasing) of every conceivable aspect of our lives.
Imagine if Newton patented Calculous, or Fourier spectral analysis. If they were morally-independant corporate types, we wouldn't be allowed do disseminate the advanced mathematics that can be highly profitable when applied to various production schemes - especially in academic environments. Newton and Einstein spent a hell of a lot more of their lives devising their mathematics than modern R&D departments do, and they were more efficient with their results (fewer total man-years, including support personelle).
Patents and copy-protection are arguably valuable. But it sickens me to see people defend obsurd patents simply because they fit to the letter of the law. People, laws adapt to the times in which they govern. We are a a changing point of history (forgot the name of the mathematical equivalent), and we can either defend the letter of the law (since it helps corporate America (or whichever country)), or we can have some foresight and extrapolate what will become in the not too distant future.
In case you bring "prior art" into the defence. 1-click is a button.. It's a *@# button. But it can not be used in certain circumstances. An OS has been around for years.. But what if MS patents the use of the OS in a certain fashion. Say, for some brand-new type of media. Once they get a foot-hold, they could carry it out to an extreme.
struct numeric { int mag, exp };
Just my numeric worth = { 2, -2 };
The only thing holding down the price of Windows right now is the that MS has been trying to fly "under the radar" of the government. Once the two companies are broken up, OpCO would be fools not to crank up the price. The remedy's already gone through at that point, competition is theoretically "restored", and let the market forces do their work! If OpCO is charging too much, other companies will barrel in there, creating spiffy new and better products.
I'd have to disagree.. There's supply and demand to deal with. If they offer a new version of windows, they have to convince people to purchase the "upgrade". They have to consider how much people will pay for it. The situation is similar with OEMs. If the newer version is much more expensive than an older, why would a person exclusively sell it? During transition periods, you can usually find the option to choose which OS you want from retailers.
MS is bound by supply and demand just as much as anyone else. Even monopolies are confined by it.
The Justice department concluded that MS _was_ in fact charging more for their OS than they could have due to competative supply and demand (though I suspect that it was well within intelligence for a Monopolistic economist).
The reason the price is so low is most likely to proliferate the newest versions, so that they can continue to squash the competition (the real threat). Take Netscape for example. They needed to squash them, so they needed to make sure that _everyone_ had IE. Best way to do it was to integrate into the OS. How do you get people to get that OS (since not everyone uses AutoUpdate), provide a new OS as a reasonable price. I'm sure it's the exact same thing for media players in win-me. I think MS also sees a threat from the iMac crowd. For the first time Apple is viable for the budget PC. So MS wanted to offer the exact same services as the iMac, so as to remove Apple from that exclusive Niche.
The _reason_ MS can get away with marginally profitable pricing schemes for the OS is because once their platform is secured, they can feature bloat their office products and super-charge for them.. Because Office is so expensive, it wouldn't be too painful to migrate to another office suite. But if people perceived that MS Office fullfilled all of their needs, then they might be more likely to stay with MS. MS has a solumn duty to fullfill all our needs (I'm still waiting for MS Pr0n), so this means making sure that they squash competition.. And this means giving as much away for free as possible. (Just read the Justice findings on their internal memos for IE).
I agree with you that after being broken up, their prices will rise.. But if they stick with the bloat-ware, single product, then theyr'e going to go under.. If they charge $1,000 for a product, then they'll get a hell of a lot less sales. Their only alternative would be to offer a cheaper version with less "crap". Their incentive to provide everything for free will go away, and we'll start to see comptition with the feature-ware once again. Netscape _might_ become a contender again, RealPlayer might not get squashed (if this happens in a timely manner), Symantec might be able to step up admin utils again. And most definately, Office competitors will spring back to life.
Office will most likely come down in price, while Windows will have to segment their products (though overall windows will be more expensive).
The sum total of all MS products will probably be $1,000, but the key will be that we'll have the opportunity to purchase the items seperately, and thus have choices (once again) about who we want to spend that $1,000 on.
How is this different from your current position, where you could just buy the competitor's product?
Well, in a purchase and forget model, the vendor has the responsibilty of looking flashy so people will make the initial purchase.. The concept of bug fixes is really just to avoid tarnishing their name (I don't think that the general public feels the same way we do about Windows.. Do they even know that there are alternatives that are more stable?). When MS pulls something like win98se which is just bug fixes (with a few "extras" for the showroom floor), they can get away with it. In a leasing structure, MS gains nothing by trying to sell you "se", since you pay the same monthly / annual rate. If MS really wanted to innovate, or make their development life easier (or their migration to NT), then they'd do it, and offer the new version of windows, just like a new version of AIM or ICQ.
In fact, you remove the incentive for them to provide flash and feature-bloat. Most likely, their strategy would have to shift from sell this box with as much marketing hype as possible, to sell a basic service, and charge for additional features. They could treat features as layers of the cake. To get all the really cool features, you'd have to pay the most money. But then a poor college student wouldn't have to spend as much as a yuppee middle class or tech-head who values this stuff more.
In another posting, I suggested the problems associated with home-users switching to other OS's, so I doubt that MS would fear people terminating their licenses in favor of alternatives.
But look at this side of the coin. If MS actually offered a minimal cost version of their OS with no bells and whistles (leave it to them to take out the damn calculator), then it opens up a new market of competition for OS services again. If a competitor could offer the same services for less overall cost than the next higher version of Windows, or more importantly with a different bundle of software, then this would prevent MS from only putting the useful features in with useless things, just so they could charge more.
Of course, MS would probably consider this and continue their crushing of competition (under the familiar mantra of not wanting to confuse the market place with "too many" options).
I've pointed out before, in regard to Word, and I will point out again, if you use proprietary software that stores your data in a proprietary format, the vendor of said software owns your data . Now imagine the can of hell-worms you open when you add a monthly subscription to propritary software. Don't pay your software bill, you can't use your data. You are then seriously fux0r3d. Never mind the morass this would create for future archivists.
Umm. Ok.. Explain Oracle / Sybase then. If you don't pay your anual licensing fee, you database doesn't work anymore.. period. Thankfully they provide data-dumps (in csv's / tsv's).
The key is that if you can extract your data into another format, then you, as the customer, can freely migrate from platform to platform if you don't like the functionality / services of an existing supplier.
In things like Quicken (MS Money), Word, etc, it might be hard to completely dump / restore your data into newer formats (csv's, and RTF may not be completely reliable for this).
That said, an OS is arguably much harder to lease. The average user does not have the resources for which to migrate all of their information from one platform to another.. They don't have ethernet, nor tape backup nor multiple partitions nor most importantly, the know-how.
Are we going to give Comp USA tons of business by sending lay people to have their OS swapped? Most likely the leasing structure would not work as for the home-user as it would for a business.
Unfortunately this is the single most important point, and you have no supporting proof supporting. It's merely here-say.
How do you suggest he prove the lack of historical precedence?
The FCC, as a government agency, should not impose regulations to solve a problem whose very existence has not been substantiated.
It's more difficult than this. It is definately plausible that free riders _could_ undermine the entertainment industry (given the right conditions). It's easier to argue that point than to say, naah, it's too unlikely; we don't have any good examples of any big company's going under because of free riders, so they have no reason to fear, and much less reason to enforce new ledgislation.
The problem is historically there were stabalizing factors. Signal quality and the seediness of the organization that would sell you pirated copies kept the threat low enough to tolerate. But with Digital, it is trivial to share or even sell the content. What's more, we, as consumers know it. Why pay for HBO, when I can just use HBO-napster to get my free rebroad-casting.
Sure, today it's a stretch to get away with broadcasting premium channels. BW + liability get in the way. But what's to say that 10 years from now we won't be able to download entire DVD's in seconds? What's more, I'm sure we'll devise better ways of maintaining anonymity on the web (thus removing liability for providing such services).
Many campuses, for example, don't get premium channels in the dorms. I'm sure that there would be a pressing demand for such streamed content. To say nothing of the pr0n channels.
My point is not to defend the MPAA / RIAA, etc. I'm simply saying that the argument we have to make has to be more intelligent than this. We can't just say "It won't happen", or merely suggest that past trends will continue. The above (or it's like) is what their lawers are likely to argue. The entire argument should really only be about whether or not digital media can undermine premium TV.
Though I idealize a restriction-free society (read free-speech), I can understand the fear of the industry of losing content to digital mass-reproduction. The only thing that concerns me is in the use of speech quelching. As was pointed out in this thread, if they control the media devices, they could actually erase all public records of an event ever having happened. (say a corporate embarrasement) Orwellian to say the least. THAT is the fear that must be fought. Media control will probably continue. The industry won't put their content on unsafe media, period! Fight for open-stuff all you want, they'll just refuse. What we should fight for is to limit how they can enforce their copy-protection. Limit it only for digital redistribution purposes.
If you fight for the ability to make analog recordings, then it's another sordid problem. Currently I can take a decent VHS recording and digitally encode it, then distribute it out ad infinitum. If I were allowed to go from Digital to VHS somehow, then the problem comes back up. But the sick thing is that it's no different than today.
"If you want to reduce corruption, get rid of the power that politicians have to dole out special treatment to different corporations and industries."
I'm not political active, and this may seem like a dumb question. But excactly HOW does this reduce corruption? Isn't this just the matter of pushing power completely over to corporations, including the corruption?
The government has a monopoly on the use of force. They have military and local police. That's it. No other organization can do so. Force is the coersion of last resort. The more organizational power you give to this force, the more of a dictatorship/fashist state you have.
Government should be like a hierarchical micro-kernel. The government should have a general principle that it upholds through the use of force. And it should fight to maintain it's monopoly of force (namely, getting ride of foreign agressors, violent crime, or mafia type). The laws at this level should be very simple and general. The problem is that sub-levels of government can make millions of special-interest laws, then back them up with force.
Libertarianism suggests that by making all special interests laws based on other forms of coersion, a citizen has the right to choose his course of action. If I choose to defy the RIAA, then the RIAA can choose to exclude me from their patrionage. They may also be able to colude with others to do the same. BUT, I could still live my life. Currently the RIAA can call apon civil legal justices which in turn can call apon the police and or the military to arrest you, confine you, and possibly even put you to death.. All because the RIAA's special interest conflicts with yours.
Here's the problem.. Let's say you elect a Lib. president. He takes power away from the fed. gov. and passes that power onto the states.. Then you have traditional republican + democratic officials controlling you at the local level. A state-constitution may not have as many civil liberties as the fed does. Also, special interests could more successfully target regional states (with less money, no likely). A state may not even have soft-money protection laws. The point of Libertarianism, is that you push all Force-based government out of special interests (including environmentalists and civil libertarians, for better or worse). You introduce Darwinian natural selection.. Supposedly states will have to compete for citizens, so it'll be in their interests to make good policy. But this is no defense against abuse.
No correct system, just better or worse for the time being.
11. Thus, there are no historical precedents or incidents justifying a need for copy protection measures. Further, there is no credible reason to believe the situation will be different for digital content delivered via broadcast or cable systems.
Unfortunately this is the single most important point, and you have no supporting proof supporting. It's merely here-say. The most popular arguement I can think of is Bill Gates in his development of "BASIC" for what I believe was the Sinclair. The famous story showed how before his debut, everyone already had a copy. I assume from this that sales were bismal (though rarely is the rest of the story told).
You claim that there is no justification for Copy protection, when I think you really only mean for audio / visual.
I'm pretty sure I remember lots of hype about Chinese pirating of American videos. I do not know that the Asian market is very big for the US because of such piracy. I do not know of any cases where foreign piracy has subverted the American market (anything large scale would be noticed and attacked). Though I'm sure lost markets scare profit seekers, no matter what, I think we can agree that we are not truely threatened by it's presence.
The issue however is that content producers have always had the support of the government in protecting their interests. It is really the level of said protection that we are debating here.
You are [alledgedly] trying to convince the FCC that the proposed level of copy-protection is excessive and unjust. However, the single most important argument is your number 11. This is what corporations will debate to no ends.. So I suggest that your submission was useless to the FCC, because your rebuttle of number 11 was heresay, and I might add, the smallest section.
Seeing as how it is not currently cheap to purchase an IP, I would have to say that 4.3G addresses is no where near enough. Though I agree that not everything needs an IP, subnetting will very quickly decimate the 32bit address space. If things continue for too long, then routers will extremely fragmented and bogged down, trying to allocate every last IP. Prices will most definately go up as demand increases and supply decreases.
Hell, I predict that subnetting will split up the 128bit adress space within 20-40 years. And the question of necessity of 16.7M addresses is not really one of current use, but future insurance.
I still think the BeamIT software was not a copyright infringement. How can it be an infringement if I can listen to only things that I own?
I HAVE IT! What we need to do is work with BeamIT and patent the idea of identifying serial numbers of owned copyrighted material, and making that material available through the web only to the owner.. We could abstract the concept to just about anything, including DVDs, OS backups, etc.
Now here's the genious.. NEVER implement it officially. Sure, give the go-ahead to rogue intranets, since we're not monsters. The trick is that MS, AOL or even better yet, some other major member of RIAA or MPAA is going to someday get a CLUE and figure this out. Charge them out the wazoo.. We're talking Billons to the patent holder, since MPAA and friends will learn that they either do it this way, or lose everything in time.:)
Thank God this Judge had some common sense. The advent of MP3 has been nothing more than a world wide conspiracy of THEFT of artistic rights from copyright holders.
Come on moderators.. Mark this guy up as funny. You can entertain the general public, and you get better moderator-karma points because it's an obvious non-flaming opinion.:)
IANAL. IF MP3 has done anything wrong, it is from their profiting off of the illegal distribution of copyrighted material. In that case, I can see their having to pay out any earned [advertisement] revenue's based on the market they've created.
Somehow I'm doubting that they really earn $400 million or even $100 million purely based on these advertisements. I could be wrong, I don't know how much advertising pulls in these days.
Hash lookup takes a constant amount of time, O(1),...
Open hashes are O(k + m) where k is the length of the string (which is almost always miniscule, though the overhead is pretty large), and m is the size of the linked list, which is generated from overlapping mappings of keys.
Perl allows you to view the statistics as follows:
$num_elements = keys %hash;
$used_and_free_cells = %hash; # "used_cells/total_cells"
An important problem with hashes is that when you get full you have to rehash. This has an incredible cost (much more than simply copying out an array to a new larger spot in memory). If you never rehash, but you keep growing your data, then your linked lists will grow so large that m will approach n. An alternative solution would be to use a tree instead of a linked-list. But for larger data-sets, this defeats the purpose of hashes.
They also have 128bit support. Don't know that any rendering software can actually make use of this though.
The 64bits should be able to make a difference in massively rendered scenes. Also, I don't think Solaris (on sparc) has any reachable file-size limits.
I still think of Solaris/ SPARC as a more robust / higher quality solution. If I had to guess, I'd even say better than IRIX / mips.
This isn't to say Linux isn't catching up. Just that, those extra dollars actually do go somewhere. In a farm-like situation, however, it's really doubtful that it's worth all the extra money.
If you think about it, with a couple GIG of ram on a server why *not* load the entire database to ram?:)
The simplest approach would be to have a massive ram-disk.
However, expanding on this possibility, there would be a fundamental change in database structure. Databases are optimized to allow tiny subsets of data to reside in memory. Most queries have to assume that only a couple pages will be addressable / comparable at a time. One of the biggest set-back with this is the lack of "data-pointers". You typically refer to data by it's primary key. Thus referencing data-items requires table-lookups. In most programming languages, you make use of references or even direct pointers (though in DB land, I'm sure references/handles would still be preferred). Thus, if table-joins were based on references (for primary / foreign keys), it would be trivial operation. I know that Oracle supports a sort of reference-type that performs just this sort of activity, but it has to still require disk-index-lookups, since the data is not in a static location.
Another big problems with relational databases is that it is very difficult to map them to program-code. A big push in DB land is to make Object Oriented DBs. Some systems have had more success than others. The biggest problem (as I see it) is to make these objects available to programming languages in a seamless fashion. In an all memory system, you might very well be able to have a local array of data-objects and use them with all the same performance as local objects. The DB would simply have triggers assigned to data-modification method which update internal relationships and enforce data-integrity rules. This much can already be done in a raw programming language, but it is impossible to separate the rule-set from the code (unlike in DB design).
This really does open up a whole new world of computing. Ideally, you have at least three completely independent designs (that can be changed independently of each other): The interface, the data-definition/rule-set, and the glue-code that makes it all work. Currently this is possible if the GUI designer (beit web pages or window-design) talks with the glue logic designer, and a relational DB is used. But there currently is not a seamless integration or high-performance connection between the data and the glue.
It [RAM] has things loaded into it every time you start a program, and whenever programs bring in more stuff. Why would you want, after you rebooted you computer, old information from programs sitting around in your RAM?
Programs free up memory all the time and it's cleared by the OS and given to other programs. That's part of the virtual memory subsystem. It's been that way for years and years. The only commonly used OS that didn't do that that I know of in the past 15 years is MS-DOS.
Just to elaborate. non-volitile memory would allow incredibly fast boot-times, since all of your drivers (and even your kernel) could remain resident across power-cycles. Assuming a robust enough OS that can withstand months of virtual-uptime (ruling out DOS-derived OSes), the boot-up process shifts from initializing your drivers to checking for HW-changes / crashes.
Just imagine the possibilities for OS robustness. Currently when we lose power (causeing an OS crash), rebooting involves checking for consistency on the file-systems (a painful process which usually involves loss of some information). Yes, you're supposed to UPS servers, but this is of no consolation to the millions of home-PC users who potentially lose hours of work. If memory was NV, then a copy of the write-buffer would still exist, and it would be possible to recover failed disk-updates.
This confuses me. I can see the need to have multiple 400MHZ channels from the RDRAM to the controller, but they shouldn't need 400MHZ from the controller to the CPU. It's 16bit vs 64bit, so they shouldn't need more than 100MHZ.
The traces from the memory to the controller shouldn't need to be that long, so I can't imagine that it's too terribly big of a problem.
I didn't see any mention of 3DNow. It's been a while since I've seen talk of it.
I _think_ that 3DNow was completely compatible with MMX, and so the reuse of the floating-point registers is all that was needed (If I could remember the name of a 3DNow op, I'd look in their table).
What I thought was interesting, however, was that Intel's SSE instructions were incorporated. I wonder if this was an admission of failure on the part of 3Dnow (since to my knowledge SSE was superior), or if they're just trying to capture that compatibility (while at the same time, upping it's potential performance by doubling the number of registers).
My favorite addition however was the new addressing scheme. The reduction of segment selector-dependency, plus the addition of IP-relative addressing just rocks; Finally, dynamically relocate able code.
As a hobby, I've followed the growth of x86 hardware since the 808[68], so it's really cool to see it finally catch up to the RISC big-boys in most arenas.
Now if they could only have provided 32 GPR and 32 FP-esk registers instead of the paltry 16 (including SSE).
Another interesting point is that the new "xHammer" design is truly an improvement over legacy design instead of scrapping then emulating (a la Italium). Basically, by using prefix op-codes, they maintain a tremendous amount of compatibility and CPU-reuse. In fact, the CPU should hardly even notice which mode it's in (minus how it deals with the upper 32-bits). Any future advancements in scheduling design, n-way execution, etc, should benefit both "long" and "legacy" modes.
Though I find much distaste for variable-length instructions, this is a beautiful case of human ingenuity solving a problem in an intelligent way (various NASA solutions come to mind).
AMD is sure to best Intel at overall value at this stage (Intel may still have a few 32bit tricks up it's sleeve). My real question, however, is how well AMD will fair against finely tuned 64bit solutions. Now that x86 is infiltrating more and more of the server market, does AMD really stand a chance of competing against raw FPU or multi-processing on say Sparc / Alpha / Power / HP / etc? They seem to be fairing well in the fabrication process micron and MHZ wise. Post-RISC chips still have an edge over x86 in that little translation of op-codes is required, and the over-all die-size can be smaller to perform the same functions. This facilitates less power-consumption and theoretically higher clock-speeds. Also, to my knowledge, many op-codes in these post-RISC chips are well suited for multi-CPU design (Off hand, I remember the Alpha's version of test-and-set).
How much life does x86 really have left in it? Can we just keep adding layers and layers of compatibility modes? And if Intel maintains a predominant market share, are they going to be able to purposefully produce incompatibilities to stifle innovation? We've already seen how they can gum up the works with RAMBUS / DDR-SDRAM and their biased chipsets.
Slashdot Mirror
Unfortunately most of us live in capitalist societies where the price of something is based on the market demand for that something and has very little to do with the actual cost of that something.
Well, once the widget has been made this is true. This is why lots of analysis is done to figure out what people might pay. If those numbers are too low, then the comodity won't be produced. Likewise, when you have an excess, and the market sale price is too low, you may opt to do something other than sell it.. For example, if I have a car, and the resale value is too low, I might strip it down and sell the pieces.
You say unfortunately, but this is a very efficient model. In the case of essential goods, the government can step in an regulate (such as the power industry, telephone, welfare, etc). In a non-market-based society, it's like having every resource regulated, which makes most services sold at inefficient levels. Often, there are pricing departments that supposedly try and find the "right" levels, but the market is too dynmic. This year, more people will want to buy the PT cursuer than next. How can you best determine who gets what? Is it first come first serve? Or should the market price adapt based on Supply and Demand, and the very first are just lucky, while towards the end, only those that really want it (or happen to be rich) get it. The difference is that it's more difficult to determine who really deserves to get the widget a-priori. Much like it's more difficult to maintain accounting on IP or CPU traffic for the entire net.
-Michael
Ouch. I assume thats in addition to the shared memory (of course -- what else could it be? You say "per worker process"). So, I suppose you're looking looking at a 25 - 35 meg httpd daemon. That's pretty darned heavy
When you start using things like embPerl (a php-like extension to perl), and you have a large project (dozens of perl modules), all cached in memory, you can easily bring your perl-space alone to 6- 12 meg. With mod-perl off, Apache is like 2-3 meg per worker for me. With everything turned on, I usually get 10meg... If you don't properly manage your perl code, then things like database accesses can consume a meg or more for a single variable.. This is hard to de-allocate in such a way to free up the process's memory space.. That coupled with fragmentation can grow your memory size considerably. It's virtual memory, to be sure, but it still counts as disk swapping.
The size of the daemon totally depends on how much code is loaded at apache startup time.. If your
I suppose, though, that no-one thought to make perl interact well with copy-on-write memory semantics. It would be cool if it did.
Well, so long as you initialize _all_ your perl code in your httpd.conf or vhost files, then you'll get essentially that. Anything generated after the dameon spawns off workers is lost, needs to be reloaded / recompiled. In the first case, you take advantage of UNIX's copy-on-write. This means most of the constant data-sections (namely the in-memory text copy of the perl source code), won't be physically duplicated.
Unfortunately, unlike most programs, most of perl's memory is writable. Meaning, you have the core perl-interpreter which is static code, then you have the hundreds of K of perl-code-text, and their intermediate meta-data or compiled form. This compiled form does not get shared between forks, since the execution tree can change over-time. At the very least, it can't be registered as "shared memory", since it's possible for the contents to change. At best, you have multiple forked processes temporarily sharing a segment with the copy-on-write flag set. If ANYTHING in that 2, 4 or 8K page changes, you have to copy out the code.
Could you explain what you mean by "the cache lines are valid for all threads." Obviously, the code cache is going to be valid (just like in Unix, obviously), and the data cache is also going to be valid (unfortunitely, not like unix). But is the stack cache going to be valid?
Ok, thinking this over, I may not have all my facts straight. I know that the x86 uses a legacy addressing scheme, unlike most modern CPU's which have a flat virtual address space, the x86 uses segment selectors. This allows a process to utilize two segments that have the exact same virtual address but really be mapped to totally different physical addresses. A segment is an offset to the CPU address register which occurs prior to page-table mapping. It also provided an upper address bound to provide a first-tier memory-protection scheme.. It worked great in the 386 days, but in our UNIX flat-virtual-memory model it's not terribly useful. I think NT still uses it for some optimization tricks.
My problem is that I do not know exactly how Linux deals with this.. My assumption was that since each process got it's own segment selector, it would have a completely different virtual memory offset, and thus the addresses that the cache lines get are different for each process. From this, I assumed that two context switches would require cache-flushing. If anyone knows differently, please come forward. If this were true (as I assumed), then MT would have the added benifit of sharing a segment selector, and thus not requiring a cache flush.
As you can see, if my original assumption was correct, then none of the code, or data cache lines would be valid. If I was incorrect, then it's just like most any other processor. Both your code and data lines are valid for all MT context switches. It's true that you have independant stacks for threads, but they're in the same memory space, they shouldn't do too much harm to each other's cache. With MP, even here, you have the issue of starving neighboring process's data caches, since for for all copy-on-write operations, you have additional memory to cache and compete against. Still, unless my origional assumption was true, none of this really will affect much.
Also, what on earth can you possibly mean when you say "the apache processes run round robin". When did apache start including a task scheduler? Will it start coming with disk drivers soon, too?
Ok, I have made assumptions based on empirical evidence. The daemon process opens port 80 (or what-ever), THEN forks off a bunch of processes with port 80 still open.. This is a very bizzar situation. Normally you'd think of it as simply having the forked processing maintaining the file-handle from the original guy. For STDOUT, it's just the luck of the draw who prints out in which order when they're both performing prints. But for server TCP sockets, things get wierd. Lets say the central daemon never listens to sockets (
it's main role is to monitor the number of workers and fork off working copies as necessary), but all 5 of your workers ARE listening on that same socket. What happens when a browers establishes a connection on port 80? You have 5 guys listening and waiting to accept a new connection, which gets it? Well, it's the OS's job to decide, and evidence on my installtion suggests it's round robin.
Here's how I did my experiement. I used mod perl in order to have a persistent memory structure. I went to a web page that would print out to the screen it's process id (since it was mod-perl, it was the same ID as that of the worker). You'd think that you'd always use the first worker, and only use additional workers if the first was busy. But instead, I'd get a random worker. I don't recall if I worked out whether it was indeed round robin.
Think of it like MT with cond_wait and cond_signal.
All workers cond_wait on the port-connection. A seperate thread (the kernel in this case) finds a new connection to port 80, so it signals a cond_signal, and some undetermined guy wakes up first and establishes the connection.. The other guys go back to sleep until the next cond_signal. When the worker is done with the connection, it does another cond_wait, reentering itself to the queue.
The most simple implementation of such a conditional broadcasting structure would be to have a round-robin queue. cond_signal activates the guy at the head of the queue, and all people initiating cond_wait go to the end of the queue.
All of this is hidden by the socket "accept" function call, which should just be an interface into the inet kernel routines. I don't know how much of libnet is done in user space and how much in kernel space, but I'm sure that no actual MT programming is going on, since I don't see any IPC resources being consumed when children listen to the same socket.
To experiement on your own, just do the following (written in perl code for brevity).
#!/usr/bin/perl
use IO::Socket;
$sock = new IO::Socket::INET( Listen => 5, LocalPort => 5000, Reuse => 1 );
for( 0
fork;
}
while(1) {
$client = $sock->accept;
$client->print( "Server $$\n" );
$client->close();
}
Then repeatedly telnet to port 5000, and watch how it cycles.
I just tried it out, and it produces 4 processes. Telneting shows me that at least on my implementation with this few processes it is perfectly round-robin. This may not be the general case, but we can't deny that having 50 web servers is always going to spawn the first one (thereby reusing it's cach lines). If I am correct, then if you are underloaded, then having 50 apache processes will actually hurt your performance (especially if any of it goes out to disk).
I was assuming that much. We're talking about 500 THOUSAND connections though. I seriously doubt that a single connection is going to have 499,999 image links. :)
-Michael
putting something complex like a webserver (or browser for that matter) into kernelspace is just asking for it
I assume you mean IE. I was under the impression that IE did NOT live in OS-space. I base this on the fact that when i?explorer dies, I can restart it without affect independant proceses (course, if anyone had a file-dialog box open, they'd freeze too).
Please correct me if I'm wrong, but Windows runs their utility DLL's in user-space. It's only the vxd's (for the win 9x world that is) that runs in kernel-space. Likewise NT 4.0 didn't let any utilities in that space. 4.0 allowed all things video to probagate, but that was it. No clue about 2k.
Hmm, I'd be curious to learn more about TUX. I was wondering what kind of performance you could get if you used an X-type event model using UNIX's select. Divide your apps into tiny chunks that take very little time each, give the apps priority queue's where tasks that take longer than one time-unit queue subsequent activities on lower-prio-q's. Then periodically poll for IO (for both disk-reads and Socket activity).
This is kind of like an RT system, where IO is garunteed to not be pending for longer than a certain amount of time. This allows thousands or millions of simultaneous connections with only the overhead of short-term context-information.
You get very fast connection-response time, and you could internally prioritize activities so as to minimize overloading (though this probably couldn't be true in general).
The bueaty of the system is that if you actually HAD multiple CPU's you could run multiple worker processes in a very similar fashion as Apache currently does. From this, there would be no incentive to run more workers than CPU's, since a given worker can handle an infinite number of connections (limited only by practicality).
This obviously wouldn't not support external API's such as CGI or mod-perl, though it MIGHT work with FastCGI or servlets, since all you need do is probagate IO.
With Apache everything is running in user space as multiple processes - Speed Hit Here?
Yup, The apache processes run round robin (far as I know), and that means that you have to flush the CPU cache for each new connection (rotating the memory space). Note, this won't be noticable for anything but the heaviest loads (since regularly scheduled OS context-switches will have the same effect). Additionally, unless you put in enough memory, you're going to have to swap to disk throughout the rotation. This is likely when you have large mod-perl code (I've gotten apache up to 20 meg / worker-process). Additionally, AFAIK, all IO caching is redundant with MP. I THINK there was a shared memory segment that resolved this, but I don't know.
An MT version has no such problem, since the cache lines are valid for all threads, AND if you had 40 threads with 4 - 12 Meg each, it's unlikely that you'll push yourself out to disk.
We're assuming, of course that nobody is using flat-out CGIs. If anyone was, then Apache would win out-right. In a single-tasked, MT environment, you have to initiate an entirely new process space, and before that, you'd have to configure your environment. In Apache, you have ready-to-go worker-processes than can easily exec the CGI, a new worker thread is recreated at a later time. In Windows, I believe there is less process-creation overhead than in UNIX (assumption based on the non-forked model of windows), so the distinction may not be as great.
I definately agree with the added stability inherent with discrete processes. However, it can actually be harder to debug when you have faulty embedded applications (mod-perl), since each worker will have a seperate work-space, you get a different answer every web-page access. Course, on the other hand, MT perl is even less secure.
With MT, you have all the fun of race-conditions and hidden shared variables that clobber each other. Debugging that can be a nightmare. IIS gives you their equivalant of perl / visual basic. I don't really know much about it, but I speculate that it's more integral to IIS than perl is to Apache, and thus is more efficient. Not to mention, perl wasn't designed for the web whereas ASP was.
Now I know we're not focusing on perl here; you could very easily substitute php, or SSI static pages. I discount servlets, since most of your processing time supposedly is taken up in the servlet, and that's independant of the web-server. I assume that servlets are available (in one form or another) for IIS. Hell, if you really liked servlets, you would use it AS the web server.
I've heard that Apache is comming out with an MT version, BUT, here's the problem. In a windows platform, you still have all the negatives of being in server windows platform. Not to mention, Apache is a text-file configuration while windows is a gui based configuration. The two do not mix well. In the UNIX environment, however, our kernel MT model leaves much to be desired. I vaguely recall reports that showed how poorly Linux did in MT compared to other platforms (obviously Solaris, but I think we even lost to Windows). If you compare MT Apache on Linux to Windows, you might get a nasty surprise. I don't know if the situation has been improved for the 2.4 kernel. Hell, Linux isn't even POSIX compliant with MT.
For simple static-page serving, MT apache should accel. Highly optimized C code in tight loops with a fixed number of worker threads could do magic. This avoids all that BS VC++ MFC stuff. But unfortunately, you can't make a sophisticated business around static pages (unless you're into pr0n I guess).
-Michael
I would like to propose that it would be impossible (take that as a challenge if you like.. I don't mind), to successfully inhabit any other planet around Sol.
...
.999) upper-bound. Note this doesn't mean we can travel this fast, just that we would never achieve the max velocity, even after years of travel. At a minimum, this gives you artificial gravity.
In order for life to exist, you need variety (Note this says nothing about the origin of that life). There also needs to be massive feed-back loops in the environment / ecosystem.
We have had multiple past failed attempts at the Geo-dome (or what-ever it's called). I lost interest in it after the first major flop, so they might have had some prolonged success since then. One of the major problem was that you couldn't control the paracitic life-forms. Much like the situation of importing a new animal life-form to a region; you affect the feed-back system in a dramatic way, which may or may not be stable.
On Earth, our Bio-domes have a safety net (you can leave the dome if things go wrong). On a hostile world, you may not have that luxury. It is human arrogance to assume that we'll be able to adapt to the situation. We're de-evolving as a people as it is. We're less required to adapt to situation, since we're "standardizing" our environments.
Recently, I've read Arthor C Clark's "Rama" series, and there is an interesting and very subtle side-plot involving the colonization of other planets. In the first book, it is assumed that we'll have colonized all the other planets. Mercury, for example, though brute force due to the supposed energy sources abundant there (read solar). Then, for what I can only assume was plot convinience, in the second book, there was another massive great Chaos (similar in effect to the great depression) which started on Earth. It destroyed all the economics and social infrastructures of every planet (since obviously everyone was dependant on everyone else). It is implied that the colonists all perished.
In the movie 2010 (another by Arthor C Clark), we saw a glimps of what can happen when those in space have to deal with political squabbling back home. Though total anarchy or great depressions may not decimate a remote colony, home-wars very well could - Trade routes could be blocked (for fear of feeding the enemy).
My point in all this is to remove the utopian "start over" that occured on terrestrial colonies. We had the exact same resources in the new Americas that we did in the Europes. Here we're talking about the ability of man to terraform another world. We can't even do this on a smaller scale currently. My guess is that we have not the capacity to comprehend the dynamics of an ecosystem sufficiently to play God with an entire planet.
From this, my suggestion (for hope) is that we must learn to travel great distances (to other solar systems) and find other pre-existing eco-systems - The class-M planet if you will. This will be closer to discovering new land, and will be far less of an engineering feet than building a planet from the undersoil-up. Assuming the travel is long (at least relative to the inhabitants of the world.. read relativity), we will find a situation very similar to the original explorers, which I find to be rather poetic. We'd reintroduce the majesty of sailing ships and their long perelous voyage. Well beyond the reach of the established governmental society gone bad.
We're getting better at theoretical deep space drives (read ion-propulsion), so it's just a matter of getting you there fast enough your food and energy supplies don't run out. Probes probably aren't that practical since relativity would have them returning hundreds of years in the future. I like to think of it more like the Battle-tech saga with the Clan's and their deep space exhile.
As a possible scenareo
Step 1:
Research _miniature_ externally fueled eco-systems. Nothing as grand a scale as Bio-dome, since I don't believe it's possible to be 100% self-contained AND be stable. Design constraints involve a limitless power-source (no sun out in deep-space), plus the ability to totally recycle minerals (If you can fuse atoms, you can split / make ionic bonds.. We would do well to put research into plant-micro-physics).
Step 2:
progress propulsion systems (along with the above power-source) for moderate / constant acceleration with a near c (.75 -
Step 3:
Advance observational sensors so as to identifiy possible planetary candidates; Those with similar ambient temperatures and other such atmospherics. It's more likely that we'd have to adapt as a race to the new chemical makeup abroad than to attempt to recreate Earth's atmosphere.. Those that live there long enough would probably never be able to return to Earth. The goal would be to reproduce often to offset the eminant fatalities.
Who knows, this might provide evidence that Darwin was wrong (maybe we _were_ engineered for a specific habitat, and we're unfit for anything else). If that's the case, then we'll just have to accept our fate. But that's not a very useful conclusion.
Step 4:
Advance biological understanding. We only have two choices in adaptation: We can either use natural selection and hope that what-ever larger force is active (either statistics or supernatural intervention(read either God or benevolant aliens)) is on our side, OR we learn to control the mutations of our bodies.
This method currently isn't socially acceptible. But the minimal requirement would be to achieve 90% understanding of how our bodies would react under varying conditions - In the hopes of developing counter-measures.
Step 4:
Kiss your wives good-bye and take a journey.
Realize that this too is sci-fi. But I find it more plausible, since it's based on the exact same challenge as not too long ago - Build bigger, faster, more robust ships, guess how many resources you needed to make a journey, and make lots of failed attempts (with real lives at stake).
Part of the drama is that many of those worlds will be hazzardous to us. Hopefully, our terrestrial observation points will be able to weed out the bad candidates.
In short, don't pretend for one minute that Star Trek is science-fiction. It is purely space-fantancy, based on little factual evidence. Any colonization out of this world would involve factors far beyond our near-term capabilities. To make things worse, the establishment is hindering further development of the sorts of radical new sciences required to progress towards colonization. Leaps are made when a totally new paradigm is used. Traditional education biases our minds, and leads us back to the same wrong turns that have generally been accepted.
We need more true science-fiction. More theoreticians, and sadly, more cataclysmic events that drive our global values towards change and evolution.
-End
So why isn't CVS patented then? Or for that matter, why has nobody thought to patent an Office suite, or the concept of an operating system. Hell, a device that adds numbers should be able to be patentable even today (provided the method is bizzar enough).
Folks, are we the whining majority ignorant of the true evils that patenting foster?
Patents are supposed to foster new technology. They assure rewards for the hard/expensive labor required in R&D. There is a similar situation for copy-rights. Software has copyrights/lefts to prevent the free rider problem, but now patents are being applied in totally inappropriate ways.
What development time is spent figuring out that you can press a button and purchase something? What development time is there to "figure out that you can do a complete process on the web"? Sure, it takes R&D to make the actual software, and if it can be shown that someone has blatantly reused code and logic from your work, then you can sue them (in essence, forcing competitors to do their own work). But what we have here is the great "idea grab".
The government is selling off ideas to the first people that can think of something no-one else has _registered_. This is a total perversion of the goals. Blind enforcement of the system is going to lead to the ownership (and hence leasing) of every conceivable aspect of our lives.
Imagine if Newton patented Calculous, or Fourier spectral analysis. If they were morally-independant corporate types, we wouldn't be allowed do disseminate the advanced mathematics that can be highly profitable when applied to various production schemes - especially in academic environments. Newton and Einstein spent a hell of a lot more of their lives devising their mathematics than modern R&D departments do, and they were more efficient with their results (fewer total man-years, including support personelle).
Patents and copy-protection are arguably valuable. But it sickens me to see people defend obsurd patents simply because they fit to the letter of the law. People, laws adapt to the times in which they govern. We are a a changing point of history (forgot the name of the mathematical equivalent), and we can either defend the letter of the law (since it helps corporate America (or whichever country)), or we can have some foresight and extrapolate what will become in the not too distant future.
In case you bring "prior art" into the defence. 1-click is a button.. It's a *@# button. But it can not be used in certain circumstances. An OS has been around for years.. But what if MS patents the use of the OS in a certain fashion. Say, for some brand-new type of media. Once they get a foot-hold, they could carry it out to an extreme.
struct numeric { int mag, exp };
Just my numeric worth = { 2, -2 };
-Michael
I'd have to disagree.. There's supply and demand to deal with. If they offer a new version of windows, they have to convince people to purchase the "upgrade". They have to consider how much people will pay for it. The situation is similar with OEMs. If the newer version is much more expensive than an older, why would a person exclusively sell it? During transition periods, you can usually find the option to choose which OS you want from retailers.
MS is bound by supply and demand just as much as anyone else. Even monopolies are confined by it.
The Justice department concluded that MS _was_ in fact charging more for their OS than they could have due to competative supply and demand (though I suspect that it was well within intelligence for a Monopolistic economist).
The reason the price is so low is most likely to proliferate the newest versions, so that they can continue to squash the competition (the real threat). Take Netscape for example. They needed to squash them, so they needed to make sure that _everyone_ had IE. Best way to do it was to integrate into the OS. How do you get people to get that OS (since not everyone uses AutoUpdate), provide a new OS as a reasonable price. I'm sure it's the exact same thing for media players in win-me. I think MS also sees a threat from the iMac crowd. For the first time Apple is viable for the budget PC. So MS wanted to offer the exact same services as the iMac, so as to remove Apple from that exclusive Niche.
The _reason_ MS can get away with marginally profitable pricing schemes for the OS is because once their platform is secured, they can feature bloat their office products and super-charge for them.. Because Office is so expensive, it wouldn't be too painful to migrate to another office suite. But if people perceived that MS Office fullfilled all of their needs, then they might be more likely to stay with MS. MS has a solumn duty to fullfill all our needs (I'm still waiting for MS Pr0n), so this means making sure that they squash competition.. And this means giving as much away for free as possible. (Just read the Justice findings on their internal memos for IE).
I agree with you that after being broken up, their prices will rise.. But if they stick with the bloat-ware, single product, then theyr'e going to go under.. If they charge $1,000 for a product, then they'll get a hell of a lot less sales. Their only alternative would be to offer a cheaper version with less "crap". Their incentive to provide everything for free will go away, and we'll start to see comptition with the feature-ware once again. Netscape _might_ become a contender again, RealPlayer might not get squashed (if this happens in a timely manner), Symantec might be able to step up admin utils again. And most definately, Office competitors will spring back to life.
Office will most likely come down in price, while Windows will have to segment their products (though overall windows will be more expensive).
The sum total of all MS products will probably be $1,000, but the key will be that we'll have the opportunity to purchase the items seperately, and thus have choices (once again) about who we want to spend that $1,000 on.
-Michael
Well, in a purchase and forget model, the vendor has the responsibilty of looking flashy so people will make the initial purchase.. The concept of bug fixes is really just to avoid tarnishing their name (I don't think that the general public feels the same way we do about Windows.. Do they even know that there are alternatives that are more stable?). When MS pulls something like win98se which is just bug fixes (with a few "extras" for the showroom floor), they can get away with it. In a leasing structure, MS gains nothing by trying to sell you "se", since you pay the same monthly / annual rate. If MS really wanted to innovate, or make their development life easier (or their migration to NT), then they'd do it, and offer the new version of windows, just like a new version of AIM or ICQ.
In fact, you remove the incentive for them to provide flash and feature-bloat. Most likely, their strategy would have to shift from sell this box with as much marketing hype as possible, to sell a basic service, and charge for additional features. They could treat features as layers of the cake. To get all the really cool features, you'd have to pay the most money. But then a poor college student wouldn't have to spend as much as a yuppee middle class or tech-head who values this stuff more.
In another posting, I suggested the problems associated with home-users switching to other OS's, so I doubt that MS would fear people terminating their licenses in favor of alternatives.
But look at this side of the coin. If MS actually offered a minimal cost version of their OS with no bells and whistles (leave it to them to take out the damn calculator), then it opens up a new market of competition for OS services again. If a competitor could offer the same services for less overall cost than the next higher version of Windows, or more importantly with a different bundle of software, then this would prevent MS from only putting the useful features in with useless things, just so they could charge more.
Of course, MS would probably consider this and continue their crushing of competition (under the familiar mantra of not wanting to confuse the market place with "too many" options).
-Michael
Umm. Ok.. Explain Oracle / Sybase then. If you don't pay your anual licensing fee, you database doesn't work anymore.. period. Thankfully they provide data-dumps (in csv's / tsv's).
The key is that if you can extract your data into another format, then you, as the customer, can freely migrate from platform to platform if you don't like the functionality / services of an existing supplier.
In things like Quicken (MS Money), Word, etc, it might be hard to completely dump / restore your data into newer formats (csv's, and RTF may not be completely reliable for this).
That said, an OS is arguably much harder to lease. The average user does not have the resources for which to migrate all of their information from one platform to another.. They don't have ethernet, nor tape backup nor multiple partitions nor most importantly, the know-how.
Are we going to give Comp USA tons of business by sending lay people to have their OS swapped? Most likely the leasing structure would not work as for the home-user as it would for a business.
-Michael
It's more difficult than this. It is definately plausible that free riders _could_ undermine the entertainment industry (given the right conditions). It's easier to argue that point than to say, naah, it's too unlikely; we don't have any good examples of any big company's going under because of free riders, so they have no reason to fear, and much less reason to enforce new ledgislation.
The problem is historically there were stabalizing factors. Signal quality and the seediness of the organization that would sell you pirated copies kept the threat low enough to tolerate. But with Digital, it is trivial to share or even sell the content. What's more, we, as consumers know it. Why pay for HBO, when I can just use HBO-napster to get my free rebroad-casting.
Sure, today it's a stretch to get away with broadcasting premium channels. BW + liability get in the way. But what's to say that 10 years from now we won't be able to download entire DVD's in seconds? What's more, I'm sure we'll devise better ways of maintaining anonymity on the web (thus removing liability for providing such services).
Many campuses, for example, don't get premium channels in the dorms. I'm sure that there would be a pressing demand for such streamed content. To say nothing of the pr0n channels.
My point is not to defend the MPAA / RIAA, etc. I'm simply saying that the argument we have to make has to be more intelligent than this. We can't just say "It won't happen", or merely suggest that past trends will continue. The above (or it's like) is what their lawers are likely to argue. The entire argument should really only be about whether or not digital media can undermine premium TV.
Though I idealize a restriction-free society (read free-speech), I can understand the fear of the industry of losing content to digital mass-reproduction. The only thing that concerns me is in the use of speech quelching. As was pointed out in this thread, if they control the media devices, they could actually erase all public records of an event ever having happened. (say a corporate embarrasement) Orwellian to say the least. THAT is the fear that must be fought. Media control will probably continue. The industry won't put their content on unsafe media, period! Fight for open-stuff all you want, they'll just refuse. What we should fight for is to limit how they can enforce their copy-protection. Limit it only for digital redistribution purposes.
If you fight for the ability to make analog recordings, then it's another sordid problem. Currently I can take a decent VHS recording and digitally encode it, then distribute it out ad infinitum. If I were allowed to go from Digital to VHS somehow, then the problem comes back up. But the sick thing is that it's no different than today.
-Michael
The government has a monopoly on the use of force. They have military and local police. That's it. No other organization can do so. Force is the coersion of last resort. The more organizational power you give to this force, the more of a dictatorship
Government should be like a hierarchical micro-kernel. The government should have a general principle that it upholds through the use of force. And it should fight to maintain it's monopoly of force (namely, getting ride of foreign agressors, violent crime, or mafia type). The laws at this level should be very simple and general. The problem is that sub-levels of government can make millions of special-interest laws, then back them up with force.
Libertarianism suggests that by making all special interests laws based on other forms of coersion, a citizen has the right to choose his course of action. If I choose to defy the RIAA, then the RIAA can choose to exclude me from their patrionage. They may also be able to colude with others to do the same. BUT, I could still live my life. Currently the RIAA can call apon civil legal justices which in turn can call apon the police and or the military to arrest you, confine you, and possibly even put you to death.. All because the RIAA's special interest conflicts with yours.
Here's the problem.. Let's say you elect a Lib. president. He takes power away from the fed. gov. and passes that power onto the states.. Then you have traditional republican + democratic officials controlling you at the local level. A state-constitution may not have as many civil liberties as the fed does. Also, special interests could more successfully target regional states (with less money, no likely). A state may not even have soft-money protection laws. The point of Libertarianism, is that you push all Force-based government out of special interests (including environmentalists and civil libertarians, for better or worse). You introduce Darwinian natural selection.. Supposedly states will have to compete for citizens, so it'll be in their interests to make good policy. But this is no defense against abuse.
No correct system, just better or worse for the time being.
-Michael
Unfortunately this is the single most important point, and you have no supporting proof supporting. It's merely here-say. The most popular arguement I can think of is Bill Gates in his development of "BASIC" for what I believe was the Sinclair. The famous story showed how before his debut, everyone already had a copy. I assume from this that sales were bismal (though rarely is the rest of the story told).
You claim that there is no justification for Copy protection, when I think you really only mean for audio / visual.
I'm pretty sure I remember lots of hype about Chinese pirating of American videos. I do not know that the Asian market is very big for the US because of such piracy. I do not know of any cases where foreign piracy has subverted the American market (anything large scale would be noticed and attacked). Though I'm sure lost markets scare profit seekers, no matter what, I think we can agree that we are not truely threatened by it's presence.
The issue however is that content producers have always had the support of the government in protecting their interests. It is really the level of said protection that we are debating here.
You are [alledgedly] trying to convince the FCC that the proposed level of copy-protection is excessive and unjust. However, the single most important argument is your number 11. This is what corporations will debate to no ends.. So I suggest that your submission was useless to the FCC, because your rebuttle of number 11 was heresay, and I might add, the smallest section.
Seeing as how it is not currently cheap to purchase an IP, I would have to say that 4.3G addresses is no where near enough. Though I agree that not everything needs an IP, subnetting will very quickly decimate the 32bit address space. If things continue for too long, then routers will extremely fragmented and bogged down, trying to allocate every last IP. Prices will most definately go up as demand increases and supply decreases.
Hell, I predict that subnetting will split up the 128bit adress space within 20-40 years. And the question of necessity of 16.7M addresses is not really one of current use, but future insurance.
-Michael
write-in candidate:
None of the above
Reminicent of "Brewster's Millions" if anyone is an 80's fan.
-Michael
I HAVE IT! What we need to do is work with BeamIT and patent the idea of identifying serial numbers of owned copyrighted material, and making that material available through the web only to the owner.. We could abstract the concept to just about anything, including DVDs, OS backups, etc.
Now here's the genious.. NEVER implement it officially. Sure, give the go-ahead to rogue intranets, since we're not monsters. The trick is that MS, AOL or even better yet, some other major member of RIAA or MPAA is going to someday get a CLUE and figure this out. Charge them out the wazoo.. We're talking Billons to the patent holder, since MPAA and friends will learn that they either do it this way, or lose everything in time.
Better yet, screw you all, I'll do it myself.
-Michael
Making a better world..
For me!
Come on moderators.. Mark this guy up as funny. You can entertain the general public, and you get better moderator-karma points because it's an obvious non-flaming opinion.
-Michael
IANAL. IF MP3 has done anything wrong, it is from their profiting off of the illegal distribution of copyrighted material. In that case, I can see their having to pay out any earned [advertisement] revenue's based on the market they've created.
Somehow I'm doubting that they really earn $400 million or even $100 million purely based on these advertisements. I could be wrong, I don't know how much advertising pulls in these days.
Open hashes are O(k + m) where k is the length of the string (which is almost always miniscule, though the overhead is pretty large), and m is the size of the linked list, which is generated from overlapping mappings of keys.
Perl allows you to view the statistics as follows:
$num_elements = keys %hash;
$used_and_free_cells = %hash; # "used_cells/total_cells"
An important problem with hashes is that when you get full you have to rehash. This has an incredible cost (much more than simply copying out an array to a new larger spot in memory). If you never rehash, but you keep growing your data, then your linked lists will grow so large that m will approach n. An alternative solution would be to use a tree instead of a linked-list. But for larger data-sets, this defeats the purpose of hashes.
They also have 128bit support. Don't know that any rendering software can actually make use of this though.
The 64bits should be able to make a difference in massively rendered scenes. Also, I don't think Solaris (on sparc) has any reachable file-size limits.
I still think of Solaris/ SPARC as a more robust / higher quality solution. If I had to guess, I'd even say better than IRIX / mips.
This isn't to say Linux isn't catching up. Just that, those extra dollars actually do go somewhere. In a farm-like situation, however, it's really doubtful that it's worth all the extra money.
The simplest approach would be to have a massive ram-disk.
However, expanding on this possibility, there would be a fundamental change in database structure. Databases are optimized to allow tiny subsets of data to reside in memory. Most queries have to assume that only a couple pages will be addressable / comparable at a time. One of the biggest set-back with this is the lack of "data-pointers". You typically refer to data by it's primary key. Thus referencing data-items requires table-lookups. In most programming languages, you make use of references or even direct pointers (though in DB land, I'm sure references/handles would still be preferred). Thus, if table-joins were based on references (for primary / foreign keys), it would be trivial operation. I know that Oracle supports a sort of reference-type that performs just this sort of activity, but it has to still require disk-index-lookups, since the data is not in a static location.
Another big problems with relational databases is that it is very difficult to map them to program-code. A big push in DB land is to make Object Oriented DBs. Some systems have had more success than others. The biggest problem (as I see it) is to make these objects available to programming languages in a seamless fashion. In an all memory system, you might very well be able to have a local array of data-objects and use them with all the same performance as local objects. The DB would simply have triggers assigned to data-modification method which update internal relationships and enforce data-integrity rules. This much can already be done in a raw programming language, but it is impossible to separate the rule-set from the code (unlike in DB design).
This really does open up a whole new world of computing. Ideally, you have at least three completely independent designs (that can be changed independently of each other): The interface, the data-definition/rule-set, and the glue-code that makes it all work. Currently this is possible if the GUI designer (beit web pages or window-design) talks with the glue logic designer, and a relational DB is used. But there currently is not a seamless integration or high-performance connection between the data and the glue.
-Michael
Just to elaborate. non-volitile memory would allow incredibly fast boot-times, since all of your drivers (and even your kernel) could remain resident across power-cycles. Assuming a robust enough OS that can withstand months of virtual-uptime (ruling out DOS-derived OSes), the boot-up process shifts from initializing your drivers to checking for HW-changes / crashes.
Just imagine the possibilities for OS robustness. Currently when we lose power (causeing an OS crash), rebooting involves checking for consistency on the file-systems (a painful process which usually involves loss of some information). Yes, you're supposed to UPS servers, but this is of no consolation to the millions of home-PC users who potentially lose hours of work. If memory was NV, then a copy of the write-buffer would still exist, and it would be possible to recover failed disk-updates.
This confuses me. I can see the need to have multiple 400MHZ channels from the RDRAM to the controller, but they shouldn't need 400MHZ from the controller to the CPU. It's 16bit vs 64bit, so they shouldn't need more than 100MHZ.
The traces from the memory to the controller shouldn't need to be that long, so I can't imagine that it's too terribly big of a problem.
-Michael
I didn't see any mention of 3DNow. It's been a while since I've seen talk of it.
I _think_ that 3DNow was completely compatible with MMX, and so the reuse of the floating-point registers is all that was needed (If I could remember the name of a 3DNow op, I'd look in their table).
What I thought was interesting, however, was that Intel's SSE instructions were incorporated. I wonder if this was an admission of failure on the part of 3Dnow (since to my knowledge SSE was superior), or if they're just trying to capture that compatibility (while at the same time, upping it's potential performance by doubling the number of registers).
My favorite addition however was the new addressing scheme. The reduction of segment selector-dependency, plus the addition of IP-relative addressing just rocks; Finally, dynamically relocate able code.
As a hobby, I've followed the growth of x86 hardware since the 808[68], so it's really cool to see it finally catch up to the RISC big-boys in most arenas.
Now if they could only have provided 32 GPR and 32 FP-esk registers instead of the paltry 16 (including SSE).
Another interesting point is that the new "xHammer" design is truly an improvement over legacy design instead of scrapping then emulating (a la Italium). Basically, by using prefix op-codes, they maintain a tremendous amount of compatibility and CPU-reuse. In fact, the CPU should hardly even notice which mode it's in (minus how it deals with the upper 32-bits). Any future advancements in scheduling design, n-way execution, etc, should benefit both "long" and "legacy" modes.
Though I find much distaste for variable-length instructions, this is a beautiful case of human ingenuity solving a problem in an intelligent way (various NASA solutions come to mind).
AMD is sure to best Intel at overall value at this stage (Intel may still have a few 32bit tricks up it's sleeve). My real question, however, is how well AMD will fair against finely tuned 64bit solutions. Now that x86 is infiltrating more and more of the server market, does AMD really stand a chance of competing against raw FPU or multi-processing on say Sparc / Alpha / Power / HP / etc? They seem to be fairing well in the fabrication process micron and MHZ wise. Post-RISC chips still have an edge over x86 in that little translation of op-codes is required, and the over-all die-size can be smaller to perform the same functions. This facilitates less power-consumption and theoretically higher clock-speeds. Also, to my knowledge, many op-codes in these post-RISC chips are well suited for multi-CPU design (Off hand, I remember the Alpha's version of test-and-set).
How much life does x86 really have left in it? Can we just keep adding layers and layers of compatibility modes? And if Intel maintains a predominant market share, are they going to be able to purposefully produce incompatibilities to stifle innovation? We've already seen how they can gum up the works with RAMBUS / DDR-SDRAM and their biased chipsets.
-Michael