No it wasn't, WoW was derived from Diablo II with a few simularaties to WC3 thrown in, mostly in the story. D2 was 1st person, had all the same classes, had skill trees, loot, etc.
Mostly my point was that the system should be designed around FIFO, but there are many ways to solve this support sub-problem...
For one thing, a bar does not necessarily even need to support the CDs -- it can be just the opposite. With a U-shaped channel, the CDs can support themselves and the bar, with the bar providing structure and FIFO. On a human scale, a bar maybe two or three feet long should not weight too much for a person. Just pick it up, shift it by however many CDs you want accessible off the end, take them off, and slide the bar inside the CDs. Of course include various 'bookends' on the bar or channel to keep the CDs from slanting, which would put more stress on the center hole.
Or you can have two supports on either end and remove only one support at a time, air-lock style, to allow CDs to pass past the supports. This would require more machinations, but could let you compress the CDs a bit more and be 'safer' (put in interlocks and whatnot to prevent accidental droppage).
You're going to keep the CDs for a couple months and only need them for some legal/contract requirement, so you don't need to "file" them. Just get a long metal bar (or bars) and put the CDs on them as they come in. Of course label them and keep a database, but basically once the bar fills up you just start taking them off the back end and check the database whether they can be thrown out. If so, toss. If not, put back either on the back of bar or front.
This is way more space efficient than folders and prevents them from getting 'stuck' to the soft plastic if the environment is bad. It's far cheaper and also easier. A "proper" system will of course have small sections that can be taken out to retreive a particular CD without too much effort... take some out, check with database, do binary search to find CD. This should be such a rare occurrence that the time to locate a particular CD.
If you have other requirements please elaborate... such as having to return the CD when the work is done. If not, this is a great, cheap solution imho.
Let me elaborate on the soul issue. There are two basic definitions of a soul, the religious one where it is some bogeyman ghost that floats away to heaven / hell / purgatory, and the rational one where it is the collective description of a being's thoughts / feelings / knowledge / personality.
The science-based definition is simple. You clone somebody and each has its own soul.
The religious definition is more complicated. If you clone somebody then it either:
1) creates a new soul, thereby usurping the god's power
2) sucks a soul out of heaven/hell (and the god gets angry)
3) creates a soul-less being (that, by divine right, must be exploited / eaten)
4) each clone shares a single soul
Thus anything remotely related to cloning is already 3/4ths evil (case 1-3). And the remaining 1/4th that is not evil violates the prime directive of all religions: selfishness. They won't sacrifice their life/soul by just fucking dying, no they have to live forever on some cloud rejoicing (and 'preach the word' about how they'll be sipping lemonade while everybody else is in limbo). They won't confront the fear that they will just return to the earth. And Gods forbid they actually share their soul with clones, they "need" it all to themselves.
So you have to realize that when it comes to cloning, a religious person is like a cornered animal: they have no ideological escape. Anything even remotely clonish is met with completely irrational rabid fanaticism. So, no, it's far more likely that Bush round up the scientists involved than to let any reasearch money flow.
Turns out the internet buzz didn't matter in Iowa. Dean was doing great until his own party disowned him (ie Clinton wing) and the media lampooned him. Dean is a good example of how much influence these establishment groups have, but not really a good example of the internet not having much influence.
Also note that sometimes the internet is the only place to conduct a campaign. A while back Dean as head of DNC bought and paid for a billboard to basically say "what about iraq, (mr local senator)?" and the republican-owned company canceled the contract and refused to run the ad because it was "too controversial" (even though they had run pro-republican billboards more extreme). So sometimes I wonder how much is "internet buzz" and how much is unconstrained buzz that happens to only really be expressable on the internet.
As per title his answers were very thoughtful and balanced, but the questions...
1) Why don't we all just get along? 2) What are you (specific distribution) doing about drivers for the rest of us? 3) How have you improved? 4) What is your biggest flaw? 5) Does Vista scare you? 6) I am not a lawyer and neither are you, so please discuss the legal basis for not including NTFS? 7) I found a bug in a specific package's dependencies, can you fix it please? 8) What are the goals of Fedora? 9) When will Fedora Directory Server be integrated? 10) Have you tried Ubuntu?
These questions are such soft-ball. Half of these are "lame interview" questions. Most of the rest are things the poster could have just looked up in the FAQs (what's the mission statement? come on). Hell we would have gotten as much by asking that +5 funny "my date canceled, what are you doing Friday?" as most of these.
Next time please mod' up some difficult questions.
If you can make good use of 2 cores you can make good use out of 4 since pretty much either the work can be split up into N parallel task or it cannot.
That's why I bought a faster single-core for a much lower price than the dual. I have dual at work and I almost never actually make use of the other core. It's the kind of thing where you don't notice the 10% faster performance *all* the time, you notice double the performance 5% of the time and so you think it's really great. But unless you actually have things you do a lot that work in parallel, the 2x or 4x is not actually the better deal, you just think it is because of the wow factor.
What is this "native executable" you speak of? To quote morpheus, "Do you think those are instructions you are running?" Pretty much every so-called native program you run is passed through the ld.so interpreter that relocates the binary and loads shared libraries. Grep the kernel sources for "ld.so".
The only reason you have to ship a JVM with your app is because a) Microsoft intentionally sabotages compatibility (by strong-arming Dell, etc not to ship Java) and b) because Linux distros can't legally ship it because of license restrictions. Java apps work fine on a Mac without shipping their own JVM.
With a JVM installed as a standard system component you run your Java programs just like any other program. You just double-click or./ it.
Mono has convenient language syntax with C#, but that's it. The CLR bytecode cannot be interpreted well, so hotspot like optimizations are far harder to do. It's a VM trying to be everything to everybody, so it's not really great at anything. It's startup time is far slower than a gcj'd Java program and it's throughput is much less than a hotspot'd one. The only real benefit is that it is oss.
Rule 3 about naming a project -- don't use an acronym Rule 4 about naming a project -- should describe what the program actually does Rule 5 about naming a project -- make a list of > 100 names that could be good Rule 6 about naming a project -- do not make up a new word unless its compound
and...
Rule 0 about naming a project -- there are no rules
You like a lot of other Linux advocates are missing the forest for the trees. A normal user simple will not install or even try linux given the difficulty of current distros. It takes too long, requires too much, and is too dangerous for the average person. EOL.
But it does not have to be that way.
Drop the partitioning and bootloader to remove the risk. Drop the cd-rom to eliminate the logistic cost. Download on-demand to eliminate the initial time cost. Warm boot replacing host os to eliminate the difficulty.
You could literally have a <100mb download that the user clicks one icon in windows and <30 seconds later they are in an actual full linux system, no questions asked, that remembers their changes and is not emulated. This can be done.
Also, a "mini-CD" like damn small linux is a pretty poor introduction to linux. Nobody wants to downgrade to Flubox from XP-like or Vista interfaces. Livecds are many times slower than a normal boot and then they are slow after that. Get over it or fix it, don't apologize for it.
Uh, I guess I'm too daft to get a Ph. D, but it sure seems to me like optimizing on the instruction level with a stack machine is solving the wrong problem.
With a stack machine, running one instruction stream in parallel is very hard, while very easy on a register-based one. But the flip side of this is that on a stack machine running multiple instruction streams in parallel is incredibly easy while *Very* difficult on a register based CPU.
For instance, take "add 1 to each element of this 30-length array" and the optimization to unroll the loop by three:
The stack version can use parallel streams:
push array # "stack[2]" push 30 # "stack[1]" push 1 # "stack[0]" of stream #1 push 2 # "stack[0]" of stream #2 push 3 # "stack[0]" of stream #3 push 3 # number of parallel streams to run fork loop: add 1 to mem at (stack[2] + stack[0]) stack[0] += 3 if stack[0] < stack[1] goto loop join
You'll have to use your imagination to expand the loop body into what it would look like in stack-instructions, but basically the fork pops the number of parallel stacks to run and then the join waits for each parallel stack to complete. Of course in a real implementation you would also push a number of stack elements to copy, etc. Since instruction decoders for stack machines are so simple your cpu can have literally hundreds of them on a die and each one still doing useful work.
The register-based machine will unroll the loop:
set r1 to 30 set r2 to 0 set r3 to array loop: set r4 to r3[r2] set r5 to r3[r2+1] set r6 to r3[r2+2] add 1, r4 store in r4 add 1, r5 store in r5 add 1, r6 store in r6 store r4 to r3[r2] store r5 to r3[r2+1] store r6 to r3[r2+2] add 3 to r2 compare r2 to r1, jump to loop
Now try to run that in parallel and you get a couple memory fetches/write overlayed, but mostly it is pretty slow. Just one hiccup in the pipeline and all of the parallelism stops. Now to mention the code to catch the remainder of the loop if not an even multiple.
That's because the "big argument" is wrong, the reason for slow Linux adoption is the extremely high initial cost and not because of missing features. The initial cost is not even the learning curve, it's just getting Linux set up and running in the first place.
Just consider the simplest scenario, vmware:
PRO: Fairly easy to do (except few images are available) CON: Takes a couple hours, so they have to really want it CON: User gets really bad experience... slow to respond, graphics with few accellerations, screen size probably changes so it looks fuzzy on their fp monitor. CON: No upgrade path to real system CON: Requires a lot of RAM CON: Requires boot into native OS first
Or the 2nd simplest, the livecd:
PRO: Can be brought over to friends house CON: Takes a couple hours to download CON: Will often require changing BIOS settings CON: Takes 2+ minutes to start CON: Doesn't save changes for next boot CON: Requires CD burner, CD reader and a CD CON: Have to reboot to use
Or the one most distributions target, the install:
PRO: Get a fully-functional, working Linux CON: Takes hours to download CON: Takes a long time to install CON: Requires CD burner, CD reader, and CDs (or purchase) CON: Have to perform dangerous operations like repartitioning drives -or- erase all data on your system and start from scratch CON: Difficult to reverse install (have to delete/merge/resize partitions) CON: Have to reboot to use
I mean come on... *any* method out there is a complete turn-off to the vast majority of users.
Average users are going to run a system in vmware that requires lots more RAM and is visibly slower when they have to boot into their normal OS anyway? No way. Average users are going to mess with the BIOS, which the vast majority do not even know the first thing about, and wait 2 minutes for linux to start rather than 20 seconds for their native OS? Nope. Average users are going to risk destroying all their data and install linux? Hah.
The best bet is with a smarter live CD. One that includes a Windows setup.exe that:
1) creates a hard drive image file in the native system 2) on boot, automatically finds it's cd image on the native filesystem and overlays the hard drive image on top of it. 3) boots off this not the cd.
Then you get a small penalty on boot, say 10 seconds, to read the bootstrap from the actual cd and you have to possibly mess with the bios, but other than that it's like a real system.
An even better would be a small Windows installer that:
1) creates a large image file with only enough data to boot 2) uses a kernel driver to replace NT kernel with linux kernel (ie a warm / non-bios reset). 3) Linux uses this image file as its drive 4) In the background and on-demand loads the rest of the files needed for the complete system.
This does not require changes to the system at all. Initially some drivers may be an issue, but these bugs can be fixed whereas educating the masses how to change a BIOS to boot from cd first is basically impossible. User's initial experience is a) download ~50-100mb file, run installer, click "start linux" and 20 sec later they are in linux. They don't have to wait for xeyes and a thousand other things to download before starting to use Linux. If they don't like it reversing is just a matter of deleting a couple files.
An operating system emulator to allow us to run our legacy unix / foss applications. User must demonstrate compelling need in order to get linux.exe authorized and activated.
kexec is a system call the implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is independent of the system firmware. And like a reboot you can start any kernel with it, not just Linux.
Geez, how hard can this be? Disable interrupts, write a new page table, jump to new kernel. It's 28k of Linux code, and that is more complicated that need be since for Windows you only care about x86 versus linux that works on many architectures.
What is this 5 years of design work you mention? The pieces are all there. If they really wanted to Red Hat could put an initial (pre-alpha) version together in a week.
With VMware you get a pretty bad linux experience, and especially with Fedora Core where vmware actually has to interpret a lot of the code because of the virtual memory space FC uses. I've actually been able to watch the terminal redraw individual lines. You get poor disk performance, not much hardware acceleration for graphics, etc.
I have a suggestion instead. Red Hat should want Fedora to be a runaway hit like Firefox, not just another linux disto. Firefox is a hit because in addition to having features users want, it is easy to install, simple, and cool. My suggestion is for Red Hat to create a distribution that runs easily on Windows. As in click the button and it runs. Here's how you can do it:
1) A pre-built image file on C:\ that will be the linux hard drive. 2) A.exe program that loads a windows driver that syncs the disks and replaces the NT kernel with Linux kernel. 3) When run, this kernel boots off the image on NTFS.
I know this can be done with existing technology (or at least the hard parts are already working). The NTFS driver can write to an existing file if the size does not change. Linux kernel can init on an already powered up machine and reset the hardware. I know Red Hat does a lot of kernel work and other developement, so I know you guys capable of doing this very quickly.
This gives the vast majority of users a way to download linux like any other program, run it without rebooting into some scary 'repartition' software, and still get the full benefit and experience of linux. In fact, immediately after downloading they just click the program and say "Yes" to "Shutdown Windows and start Linux?" and 20 seconds later they are in a Fedora core system. If they like it, they can install a normal Fedora directly onto the system. If they don't like it, just delete the image file.
My question is, will you at least consider doing this? Something like this would be huge for linux adoption and therefore Red Hat mindshare.
I just want to know why these seemingly obvious patents keep getting given out.
The simple answer is because there is no penalty to filing a bogus patents other than the filing fee. A few tweaks to the system to make abusing it carry a cost and the system would work fine. And for that matter software algorithms should be patentable, just like any other process, the real problem is that there are so many bogus software patents like 'clicking a button to purchase goods' that are just criminally stupid.
* If a patent suit fails because the patent is found to be obvious or that due diligence was not taken to check for prior art than the holder should be fined a fixed percentage of how much they sought in damages (say 10%).
* If a suit fails because of prior art that invalidates the patent the filer should be required by law to pay the defendant's reasonable legal fees.
* If the patent is found to be "obscure" (based on "I know it when I see it doctrine"), even if valid, then the filer should be fined. If found purposely obscure the filer should be barred from patenting for a period and/or jailed. For example, when drafts are found showing plain language converted to 'legalese' (this would be for deterrent, but hardly ever enforced based on the difficulty to prove).
This clears up the patent problems, and without negatively affecting small inventors that have a genuinely new idea.
That is a good point, but it is still much harder to exploit a flaw when the driver can only access 50k of its memory space vs 10 megs of kernel. Also, many drivers could be run almost entirely as "safe" code like Java bytecodes / C# MSIL within the kernel itself with little performance impact while preventing the vast majority of possible bugs.
Or substitute with Inferno/Dis or D if you are one of the old-timers that think it absolutely must be compiled first. But just look at Berkely Packet Filter, it's 100% *interpreted bytecode* and faster than passing data off to a separate process.
In theory Linus and Tannenbaum are both wrong -- a safe kernel and apps written in safe languages are the best mix of performance/security. But in practice you have to support all the legacy unix/windows/mac software written using the 1970-era unix process model. What a shame really.
This is only because the cores are so heavyweight. For example, Cray/Tera MTA had 128 'cores' per processor and it flew. It was able to do that by not using a cache, thus each instruction took a long time to finish but 128 could be done at once.
The cache is the real scalability problem with multiple cores, and the reason is because it must do virtual memory mapping. With a single physical memory space, the cache is very simple and can be coherent across a great many cores on the same chip. It would also allow cores to 'change direction' and run small snippets of code without a lot of setup overhead. This is completely doable with 'safe' languages like Java/C#/LISP/etc because they have no pointers (so all apps can share the same memory space with no crashes or security flaws). In fact, the same JavaOS runs the same on hardware with and without VM and there are no differences to the user. The apps do not crash.
So while we are stuck with C/unix style processes the number of cores will be very small (4 or less) because not much use can be made out of more. I like C and unix, but they are just designed for an era that should have long since past by now.
Or get a bunch of IR-reflective stickers printed up with your plate number and place them all over.
Eventually the "fire in crowded theatre" clause of the constitution will be invoked to make printing 6 and 7-digit numbers illegal. And yes, there is such a clause, but it was ratified in secret session of the contitutional congress. That's why you've never heard of it before.
Slashdot Mirror
No it wasn't, WoW was derived from Diablo II with a few simularaties to WC3 thrown in, mostly in the story. D2 was 1st person, had all the same classes, had skill trees, loot, etc.
Just to piss off the lawyers I am naming my next company "Rappy Systems".
Mostly my point was that the system should be designed around FIFO, but there are many ways to solve this support sub-problem...
For one thing, a bar does not necessarily even need to support the CDs -- it can be just the opposite. With a U-shaped channel, the CDs can support themselves and the bar, with the bar providing structure and FIFO. On a human scale, a bar maybe two or three feet long should not weight too much for a person. Just pick it up, shift it by however many CDs you want accessible off the end, take them off, and slide the bar inside the CDs. Of course include various 'bookends' on the bar or channel to keep the CDs from slanting, which would put more stress on the center hole.
Or you can have two supports on either end and remove only one support at a time, air-lock style, to allow CDs to pass past the supports. This would require more machinations, but could let you compress the CDs a bit more and be 'safer' (put in interlocks and whatnot to prevent accidental droppage).
You're going to keep the CDs for a couple months and only need them for some legal/contract requirement, so you don't need to "file" them. Just get a long metal bar (or bars) and put the CDs on them as they come in. Of course label them and keep a database, but basically once the bar fills up you just start taking them off the back end and check the database whether they can be thrown out. If so, toss. If not, put back either on the back of bar or front.
This is way more space efficient than folders and prevents them from getting 'stuck' to the soft plastic if the environment is bad. It's far cheaper and also easier. A "proper" system will of course have small sections that can be taken out to retreive a particular CD without too much effort... take some out, check with database, do binary search to find CD. This should be such a rare occurrence that the time to locate a particular CD.
If you have other requirements please elaborate... such as having to return the CD when the work is done. If not, this is a great, cheap solution imho.
Let me elaborate on the soul issue. There are two basic definitions of a soul, the religious one where it is some bogeyman ghost that floats away to heaven / hell / purgatory, and the rational one where it is the collective description of a being's thoughts / feelings / knowledge / personality.
The science-based definition is simple. You clone somebody and each has its own soul.
The religious definition is more complicated. If you clone somebody then it either:
1) creates a new soul, thereby usurping the god's power
2) sucks a soul out of heaven/hell (and the god gets angry)
3) creates a soul-less being (that, by divine right, must be exploited / eaten)
4) each clone shares a single soul
Thus anything remotely related to cloning is already 3/4ths evil (case 1-3). And the remaining 1/4th that is not evil violates the prime directive of all religions: selfishness. They won't sacrifice their life/soul by just fucking dying, no they have to live forever on some cloud rejoicing (and 'preach the word' about how they'll be sipping lemonade while everybody else is in limbo). They won't confront the fear that they will just return to the earth. And Gods forbid they actually share their soul with clones, they "need" it all to themselves.
So you have to realize that when it comes to cloning, a religious person is like a cornered animal: they have no ideological escape. Anything even remotely clonish is met with completely irrational rabid fanaticism. So, no, it's far more likely that Bush round up the scientists involved than to let any reasearch money flow.
Turns out the internet buzz didn't matter in Iowa. Dean was doing great until his own party disowned him (ie Clinton wing) and the media lampooned him. Dean is a good example of how much influence these establishment groups have, but not really a good example of the internet not having much influence.
Also note that sometimes the internet is the only place to conduct a campaign. A while back Dean as head of DNC bought and paid for a billboard to basically say "what about iraq, (mr local senator)?" and the republican-owned company canceled the contract and refused to run the ad because it was "too controversial" (even though they had run pro-republican billboards more extreme). So sometimes I wonder how much is "internet buzz" and how much is unconstrained buzz that happens to only really be expressable on the internet.
Stallman vs. Torvalds
...rips kernel out of Linux...
Round GPL3... Fight!!!
Stalhman Wins.
Flawless Victory.
Finish Him!
[up,up,down,forward,L1,R2,back]
I wonder when the Hague will rule that freedom from mind-altering drugs and effects is a human right. It can't come soon enough.
As per title his answers were very thoughtful and balanced, but the questions...
1) Why don't we all just get along?
2) What are you (specific distribution) doing about drivers for the rest of us?
3) How have you improved?
4) What is your biggest flaw?
5) Does Vista scare you?
6) I am not a lawyer and neither are you, so please discuss the legal basis for not including NTFS?
7) I found a bug in a specific package's dependencies, can you fix it please?
8) What are the goals of Fedora?
9) When will Fedora Directory Server be integrated?
10) Have you tried Ubuntu?
These questions are such soft-ball. Half of these are "lame interview" questions. Most of the rest are things the poster could have just looked up in the FAQs (what's the mission statement? come on). Hell we would have gotten as much by asking that +5 funny "my date canceled, what are you doing Friday?" as most of these.
Next time please mod' up some difficult questions.
If you can make good use of 2 cores you can make good use out of 4 since pretty much either the work can be split up into N parallel task or it cannot.
That's why I bought a faster single-core for a much lower price than the dual. I have dual at work and I almost never actually make use of the other core. It's the kind of thing where you don't notice the 10% faster performance *all* the time, you notice double the performance 5% of the time and so you think it's really great. But unless you actually have things you do a lot that work in parallel, the 2x or 4x is not actually the better deal, you just think it is because of the wow factor.
What is this "native executable" you speak of? To quote morpheus, "Do you think those are instructions you are running?" Pretty much every so-called native program you run is passed through the ld.so interpreter that relocates the binary and loads shared libraries. Grep the kernel sources for "ld.so".
./ it.
The only reason you have to ship a JVM with your app is because a) Microsoft intentionally sabotages compatibility (by strong-arming Dell, etc not to ship Java) and b) because Linux distros can't legally ship it because of license restrictions. Java apps work fine on a Mac without shipping their own JVM.
With a JVM installed as a standard system component you run your Java programs just like any other program. You just double-click or
Mono has convenient language syntax with C#, but that's it. The CLR bytecode cannot be interpreted well, so hotspot like optimizations are far harder to do. It's a VM trying to be everything to everybody, so it's not really great at anything. It's startup time is far slower than a gcj'd Java program and it's throughput is much less than a hotspot'd one. The only real benefit is that it is oss.
You forgot...
Rule 3 about naming a project -- don't use an acronym
Rule 4 about naming a project -- should describe what the program actually does
Rule 5 about naming a project -- make a list of > 100 names that could be good
Rule 6 about naming a project -- do not make up a new word unless its compound
and...
Rule 0 about naming a project -- there are no rules
You like a lot of other Linux advocates are missing the forest for the trees. A normal user simple will not install or even try linux given the difficulty of current distros. It takes too long, requires too much, and is too dangerous for the average person. EOL.
But it does not have to be that way.
Drop the partitioning and bootloader to remove the risk.
Drop the cd-rom to eliminate the logistic cost.
Download on-demand to eliminate the initial time cost.
Warm boot replacing host os to eliminate the difficulty.
You could literally have a <100mb download that the user clicks one icon in windows and <30 seconds later they are in an actual full linux system, no questions asked, that remembers their changes and is not emulated. This can be done.
Also, a "mini-CD" like damn small linux is a pretty poor introduction to linux. Nobody wants to downgrade to Flubox from XP-like or Vista interfaces. Livecds are many times slower than a normal boot and then they are slow after that. Get over it or fix it, don't apologize for it.
Uh, I guess I'm too daft to get a Ph. D, but it sure seems to me like optimizing on the instruction level with a stack machine is solving the wrong problem.
With a stack machine, running one instruction stream in parallel is very hard, while very easy on a register-based one. But the flip side of this is that on a stack machine running multiple instruction streams in parallel is incredibly easy while *Very* difficult on a register based CPU.
For instance, take "add 1 to each element of this 30-length array" and the optimization to unroll the loop by three:
The stack version can use parallel streams:
push array # "stack[2]"
push 30 # "stack[1]"
push 1 # "stack[0]" of stream #1
push 2 # "stack[0]" of stream #2
push 3 # "stack[0]" of stream #3
push 3 # number of parallel streams to run
fork
loop:
add 1 to mem at (stack[2] + stack[0])
stack[0] += 3
if stack[0] < stack[1] goto loop
join
You'll have to use your imagination to expand the loop body into what it would look like in stack-instructions, but basically the fork pops the number of parallel stacks to run and then the join waits for each parallel stack to complete. Of course in a real implementation you would also push a number of stack elements to copy, etc. Since instruction decoders for stack machines are so simple your cpu can have literally hundreds of them on a die and each one still doing useful work.
The register-based machine will unroll the loop:
set r1 to 30
set r2 to 0
set r3 to array
loop:
set r4 to r3[r2]
set r5 to r3[r2+1]
set r6 to r3[r2+2]
add 1, r4 store in r4
add 1, r5 store in r5
add 1, r6 store in r6
store r4 to r3[r2]
store r5 to r3[r2+1]
store r6 to r3[r2+2]
add 3 to r2
compare r2 to r1, jump to loop
Now try to run that in parallel and you get a couple memory fetches/write overlayed, but mostly it is pretty slow. Just one hiccup in the pipeline and all of the parallelism stops. Now to mention the code to catch the remainder of the loop if not an even multiple.
That's because the "big argument" is wrong, the reason for slow Linux adoption is the extremely high initial cost and not because of missing features. The initial cost is not even the learning curve, it's just getting Linux set up and running in the first place.
Just consider the simplest scenario, vmware:
PRO: Fairly easy to do (except few images are available)
CON: Takes a couple hours, so they have to really want it
CON: User gets really bad experience... slow to respond, graphics with few accellerations, screen size probably changes so it looks fuzzy on their fp monitor.
CON: No upgrade path to real system
CON: Requires a lot of RAM
CON: Requires boot into native OS first
Or the 2nd simplest, the livecd:
PRO: Can be brought over to friends house
CON: Takes a couple hours to download
CON: Will often require changing BIOS settings
CON: Takes 2+ minutes to start
CON: Doesn't save changes for next boot
CON: Requires CD burner, CD reader and a CD
CON: Have to reboot to use
Or the one most distributions target, the install:
PRO: Get a fully-functional, working Linux
CON: Takes hours to download
CON: Takes a long time to install
CON: Requires CD burner, CD reader, and CDs (or purchase)
CON: Have to perform dangerous operations like repartitioning drives -or- erase all data on your system and start from scratch
CON: Difficult to reverse install (have to delete/merge/resize partitions)
CON: Have to reboot to use
I mean come on... *any* method out there is a complete turn-off to the vast majority of users.
Average users are going to run a system in vmware that requires lots more RAM and is visibly slower when they have to boot into their normal OS anyway? No way. Average users are going to mess with the BIOS, which the vast majority do not even know the first thing about, and wait 2 minutes for linux to start rather than 20 seconds for their native OS? Nope. Average users are going to risk destroying all their data and install linux? Hah.
The best bet is with a smarter live CD. One that includes a Windows setup.exe that:
1) creates a hard drive image file in the native system
2) on boot, automatically finds it's cd image on the native filesystem and overlays the hard drive image on top of it.
3) boots off this not the cd.
Then you get a small penalty on boot, say 10 seconds, to read the bootstrap from the actual cd and you have to possibly mess with the bios, but other than that it's like a real system.
An even better would be a small Windows installer that:
1) creates a large image file with only enough data to boot
2) uses a kernel driver to replace NT kernel with linux kernel (ie a warm / non-bios reset).
3) Linux uses this image file as its drive
4) In the background and on-demand loads the rest of the files needed for the complete system.
This does not require changes to the system at all. Initially some drivers may be an issue, but these bugs can be fixed whereas educating the masses how to change a BIOS to boot from cd first is basically impossible. User's initial experience is a) download ~50-100mb file, run installer, click "start linux" and 20 sec later they are in linux. They don't have to wait for xeyes and a thousand other things to download before starting to use Linux. If they don't like it reversing is just a matter of deleting a couple files.
Target's intellect is too low for Abolish Desease (rank 1)
An operating system emulator to allow us to run our legacy unix / foss applications. User must demonstrate compelling need in order to get linux.exe authorized and activated.
Geez, how hard can this be? Disable interrupts, write a new page table, jump to new kernel. It's 28k of Linux code, and that is more complicated that need be since for Windows you only care about x86 versus linux that works on many architectures.
What is this 5 years of design work you mention? The pieces are all there. If they really wanted to Red Hat could put an initial (pre-alpha) version together in a week.
With VMware you get a pretty bad linux experience, and especially with Fedora Core where vmware actually has to interpret a lot of the code because of the virtual memory space FC uses. I've actually been able to watch the terminal redraw individual lines. You get poor disk performance, not much hardware acceleration for graphics, etc.
I have a suggestion instead. Red Hat should want Fedora to be a runaway hit like Firefox, not just another linux disto. Firefox is a hit because in addition to having features users want, it is easy to install, simple, and cool. My suggestion is for Red Hat to create a distribution that runs easily on Windows. As in click the button and it runs. Here's how you can do it:
.exe program that loads a windows driver that syncs the disks and replaces the NT kernel with Linux kernel.
1) A pre-built image file on C:\ that will be the linux hard drive.
2) A
3) When run, this kernel boots off the image on NTFS.
I know this can be done with existing technology (or at least the hard parts are already working). The NTFS driver can write to an existing file if the size does not change. Linux kernel can init on an already powered up machine and reset the hardware. I know Red Hat does a lot of kernel work and other developement, so I know you guys capable of doing this very quickly.
This gives the vast majority of users a way to download linux like any other program, run it without rebooting into some scary 'repartition' software, and still get the full benefit and experience of linux. In fact, immediately after downloading they just click the program and say "Yes" to "Shutdown Windows and start Linux?" and 20 seconds later they are in a Fedora core system. If they like it, they can install a normal Fedora directly onto the system. If they don't like it, just delete the image file.
My question is, will you at least consider doing this? Something like this would be huge for linux adoption and therefore Red Hat mindshare.
I just want to know why these seemingly obvious patents keep getting given out.
The simple answer is because there is no penalty to filing a bogus patents other than the filing fee. A few tweaks to the system to make abusing it carry a cost and the system would work fine. And for that matter software algorithms should be patentable, just like any other process, the real problem is that there are so many bogus software patents like 'clicking a button to purchase goods' that are just criminally stupid.
* If a patent suit fails because the patent is found to be obvious or that due diligence was not taken to check for prior art than the holder should be fined a fixed percentage of how much they sought in damages (say 10%).
* If a suit fails because of prior art that invalidates the patent the filer should be required by law to pay the defendant's reasonable legal fees.
* If the patent is found to be "obscure" (based on "I know it when I see it doctrine"), even if valid, then the filer should be fined. If found purposely obscure the filer should be barred from patenting for a period and/or jailed. For example, when drafts are found showing plain language converted to 'legalese' (this would be for deterrent, but hardly ever enforced based on the difficulty to prove).
This clears up the patent problems, and without negatively affecting small inventors that have a genuinely new idea.
That is a good point, but it is still much harder to exploit a flaw when the driver can only access 50k of its memory space vs 10 megs of kernel. Also, many drivers could be run almost entirely as "safe" code like Java bytecodes / C# MSIL within the kernel itself with little performance impact while preventing the vast majority of possible bugs.
Or substitute with Inferno/Dis or D if you are one of the old-timers that think it absolutely must be compiled first. But just look at Berkely Packet Filter, it's 100% *interpreted bytecode* and faster than passing data off to a separate process.
In theory Linus and Tannenbaum are both wrong -- a safe kernel and apps written in safe languages are the best mix of performance/security. But in practice you have to support all the legacy unix/windows/mac software written using the 1970-era unix process model. What a shame really.
This is only because the cores are so heavyweight. For example, Cray/Tera MTA had 128 'cores' per processor and it flew. It was able to do that by not using a cache, thus each instruction took a long time to finish but 128 could be done at once.
The cache is the real scalability problem with multiple cores, and the reason is because it must do virtual memory mapping. With a single physical memory space, the cache is very simple and can be coherent across a great many cores on the same chip. It would also allow cores to 'change direction' and run small snippets of code without a lot of setup overhead. This is completely doable with 'safe' languages like Java/C#/LISP/etc because they have no pointers (so all apps can share the same memory space with no crashes or security flaws). In fact, the same JavaOS runs the same on hardware with and without VM and there are no differences to the user. The apps do not crash.
So while we are stuck with C/unix style processes the number of cores will be very small (4 or less) because not much use can be made out of more. I like C and unix, but they are just designed for an era that should have long since past by now.
That was the 36% sexy Mrs. Pacman
Or get a bunch of IR-reflective stickers printed up with your plate number and place them all over.
Eventually the "fire in crowded theatre" clause of the constitution will be invoked to make printing 6 and 7-digit numbers illegal. And yes, there is such a clause, but it was ratified in secret session of the contitutional congress. That's why you've never heard of it before.