I understand that. That's why I pointed out L4Ka. The problem is with early microkernels and the original Mach design in particular. Without specifically taking the context switching into account, performance is terrible. Embedded realtime operating systems such as QNX are not a good example. They are designed in such a way that they can guarantee realtime performance up to a specific system load, which must not be exceeded for the system to function properly. Remember though, that as of yet QNX is not a general purpose operating system. Further, I suggest you check out the recent performance issues of XNU as compared to Linux for common server applications such as Apache, MySQL, etc. Speed is most certainly an issue, and until a general purpose operating system is designed in such a way as to minimize context switching across system calls, it always will be an issue with separating drivers from kernel and user space.
The problem is that we do not have a modern operating system architecture that is fast enough to allow for drivers to run in another privilege level. Seen the wonderful server performance of OSX? That's what happens when you put drivers at a different privilege level than the kernel. The real issue is twofold. Firstly, context switches are extremely slow, even on modern processors. In the IA-32 architecture, which has three privilege levels, most microkernels have put kernel code at ring 0 (most privileged), drivers at ring 1, and user code in ring 2. But what you end up with is every system call going from user -> driver -> kernel -> driver -> user. This greatly slows down the system, especially in a uniprocessor multitasking operating system. Things get even more complicated when you're trying to write a portable operating system (Linux/*BSD/NT Kernel), since most other chip architectures only offer two privilege levels (user & supervisor).
I guess my point is simply that we've tried this isolation you speak of, but it truly offers horrendous performance, especially graphics subsystems. Take a look at some of the research on Mach, why no one uses it (well, except Apple). Check out Jochen Leudtke's research on the L4Ka microkernel, and how they've gotten near monolithic type speed out of a microkernel by caching calls between privilege levels to minimize context switching.
OS Development is fun! It also allows you to look at the common (and not so common) operating systems in a whole new light. And don't get me started on the Linux kernel. Until the 2.4 series, I could have done better with 6 months and an unlimited supply of pizza and Sun Drop (and no, I can't get the good Sun Drop where I live!!)
So in short, every modern operating system (sans OSX) runs drivers in Kernel mode. It's a necessary evil. Maybe one day, the speed decline will be negligible, but as long as context switches take over 1,000 cycles, and as long as you can trigger tens of thousands of context switches relatively easily in user/driver/system interactions, with very few user-level instructions (i.e. libc), we'll always have this problem.
You are so wrong it's not even funny. Do 4 or 5 years of actual OS Development on the x86 and you'll see that your first paragraph alone contains so many errors that I'm actually having a hard time of where to start.
Modern operating systems RARELY use the BIOS. In fact, a protected mode operating system has ZERO need for it. The only reason a modern operating system would ever have for using the BIOS is during development when protected mode drivers have not been written for all devices yet (and you have chicken or egg issues). Stop spreading FUD, please! The BIOS is for backwards compatibility (yes, you can still install DOS 1.0 on any modern machine and it will work fine -- VERY FAST -- but fine) Further, IRQs are handled by the LAPIC and IOAPIC (Local APIC (on chip since Pentium) and IOAPIC (usually present in newer Intel systems and all MP systems for several years)). Your logic is as it related to the 8259 PIC chip (which is still the default at bootup, but is disabled by most modern operating systems soon thereafter). Sorry, but your comment about transformations is simply wrong. Windows (and Linux, *BSD, and I'm sure OSX too) all do these "transformations." It's called using the modern facilities present in the IA32 (and x86-64) architecture for controlling hardware interrupts, non-maskable interrupts (NMI), software interrupts, call gates, and task gates. There is no sham going on, it really is different.
Apple is not going to use something that is non-standard because it is not cost effective. Why continue to design chipsets and motherboards when they don't have to? Why do redundant R&D? Asus has made Mac motherboards for years. Apple has no fabs. It only costs them money (of which they could never pour in as much as the Wintel PC industry). Apple isn't doing these things because Apple has engineers that understand the PC platform, understand the progress it's made over the last 20 years, and are not running around like chicken little talking about OpenFirmware, BIOS, EFI, Itanium, and all the other nonsense being spewed forth by Mac users who just don't understand that the arguments they were fed for years about the PC Platform simply do not exist anymore (or only exist in legacy and/or compatibility configurations).
Did you even read the quote you quoted? Where does it say that Apple would not be based on x86? This is an incorrect quote by whoever wrote the second part of this comment. The new Macintoshes will MOST CERTAINLY be x86. Go and read Apple's Universal Binary Development Guide. I don't know what's so hard to understand about #1) They're NOT using OpenFirmware; #2) The Intel platform IS x86 and 32-bit (although this article seems to suggest that OSX 10.5 Leopard will be the first 64-bit OSX from the ground up on both PPC and Intel Platforms); #3 speculation is that Apple is going to use a custom chip to prevent OSX from running on non-Apple hardware, which it will most certainly do (for a time), but it will not prevent Windows from running (as Apple has said, time and again -- showing that the Intel Macs will be close enough to vanilla x86 architecture to run it without too much trouble).
Too many Mac users that know NOTHING about hardware because they've been in Steve's RDF for 20 years. I can't tell you how many rants I've seen from third-party Mac hardware developers complaining about BIOS and how crappy it is and even, *gasp* real-mode! What idiots! What does BIOS and/or real-mode have to do with a modern operating system running in protected mode? What do 16 IRQs have to do with modern IOAPIC/APIC which can trigger up to 256 different interrupt lines? Nothing. FUD. They're upset because now they have to compete with PC hardware vendors, where they'll get roasted on quality, price and performance... Here's a hint to Apple users: If you want to know about PC Hardware, where the industry is going, what has happened in the past 20 years on this side of the fence -- ASK A PC USER, OR GO TO A PC HARDWARE WEB-SITE. STOP READING MAC SITES WHERE THE JOURNALISTS ACTUALLY KNOW LESS THAN THE USERS.
Whoops. Everytime I submit without previewing this happens. Sorry... I meant to say that unless you're still using Office 97, you won't have a problem with reading or writing the new formats, thus taking care of the interoperability issue.
Except for the fact that, at least according to this ZDNet article, Microsoft is backporting the XML reading and writing capability to Office 2000, XP & 2003. So unless you're still using Office 97 (admittedly, there are still many, but it IS 9 years old!). So, what about your point now??
You should try AerialLink. They have several fixed wireless plans that are competitively priced. The speeds can be phenomenal as well. I've set up a few clients with the service, and it's been great. You do have to worry about signal degradation, so if you're in a heavily wooded area this might not be an option, but if you're not, you should check them out.
Yeah whatever. Let me know when it's *REALLY* an OS. As soon as I can build the tools that I want (99% GNU), without heavy modification, I don't consider OSX to be anything other than part of Steve Jobs' reality distortion field. Maybe simple apps work fine, but have you seen all of the work that goes into porting just for OSX (check out DarwinPorts and/or Fink). Hell, I can get the same functionality from Windows through Cygwin, MinGW, or SFU. As a matter of fact, most development tools i've had the (mis)pleasure of building on OSX have worked flawlessly on Linux and Cygwin. And don't get me started on the GUI. I'm so sick of hearing about how great the OSX GUI is. So it's got slick animations. BFD. Why is it so difficult to know what programs are open? Why can't I jump quickly between my windows? What's the point of the "spatial" orientation? It's just ass-backward. The mouse support sucks (even with an MS Intellimouse Explorer). Context menus are weak, and offer very few options. Why should I have to hit a key combination to go to any folder on my hard drive? Why can't I easily view the contents of the *nix filesystem? The list goes on and on.
I'm sure you MacHeads have valid explanations for all of my issues, and it probably is relatively simple, however I simply prefer the Windows/KDE way of doing things. You know, I really am disappointed, because I heard how great OSX was, with the *BSD-like underpinnings, etc. It just didn't live up to the hype. As a matter of fact, it behaves pretty much like every other MacOS that was released previously, with the exception of being prettier and having a little more muscle under the hood.
Very true, and I was thinking the same thing when I read the blurb. Further, they don't include sales of DVD players themselves either, whereas the games industry most certainly includes the hardware sales dollars from dedicated consoles. Then you can also talk about international distribution and other market's native films, etc., etc.. Hollywood (and television in general) still makes many, many times what the videogame industry does.
Well, that's *sorta* true. If you noticed, I went on a mission on Friday, just about an hour after I found out that SP2 had been released. I could not be sure that what I was getting on a P2P network was in fact a true copy (and as a matter of fact, I didn't see *any* copies), while I had several sources on various message boards verify the one in the newsgroup. So, while it looks like a pain, it really is just three steps, since the newsleecher software was pretty straightforward, the verifier took about 4 seconds to run, and WinRAR extracted all 19 parts in one step. By now, three days later, more people have had the opportunity to d/l the file, and obviously there are a ton of torrents and I'm sure it's all over Kazaa, etc.
Just another method that happens to be very fast, although you are correct that there are easier ones. This was for the hardcore user who wants the file quickly and is not able to get through to MS, doesn't have good d/l on a torrent, or who cannot get decent speed from a P2P app.
Ok guys, this is the quickest and easiest way (especially if on broadband) to get SP2. Get newsleecher, then go to alt.binaries.wares.ibm-pc.ms-beta, and download the WindowsXP-SP2-2180-ENU-FINAL files (there's 28 of them). Yes, one small file is missing (about 22k). The file ships with a Parchive parity file (.PAR2) to reconstruct and/or correct any data that did not come through. You can get the PAR2 verifier from here. Now what do you do? Well, you will be left with 19.rar files, so UNRAR them!! You will be left with a filename slightly different from the original, but this is in fact the correct build. MD5 Sum and crc32 verified with fsum (59A98F181FE383907E520A391D75B5A7 & 046F12B1, respectively). Have fun! And best of all?? If you're on broadband, it's fast, especially since you're not leaving the local provider's network (assuming your provider hosts their own news servers).
By the way, I do not normally get software this way, but on Friday it was my mission to get SP2, and get the real one. This worked and was fairly simple. If you've just got to have it, you can use this method. It is the correct service pack, and it works fine! Hope this helps..
I personally think this has been the big delay in getting VPC7 to market. The performance must be abysmal. While the PPC970 can still perform endian swapping calculations quickly (as can the x86), the inability to mark specified regions of memory (code, data, stack) as big or little endian was of great importance. Now, every time an instruction is executed, the calculations must be performed. My guess is that MS is going to be very careful about performance on this issue. Everyone already has their eye out for their sinister intentions after having purchased Connectix, and imagine the ammo it'll give their detractors if VPC7 runs slower on G5s than it did on previous generation Apple hardware. I personally think the real reason for MS's purchase of Connectix was for their server virtualization technology which they needed in order to keep pace with VMWare's GSX Server and IBM's work on running multiple Linux kernels on big iron. But, I guess everywhere there's smoke, there's fire...
Actually, with the G5 (PPC970) chip, IBM did away with the endian swapping feature. This is what has kept VirtualPC from running on the G5s. Wonder why they got rid of the feature? My guess is that die size limitations simply would not allow the required support logic anymore, especially when multiple 970 cores get lumped together on a single chip in the POWER family.
I'll bite, even though you're an AC. You must understand that everything evolves in the computer world. We do not simply make new things up. The tools available at our disposal are the result of an evolutionary process that has gone on for 50+ years.
That being said,.NET is most certainly not any of those things you presented..NET is the new version of Win32, which we all know, as a subsystem to a pretty amazing kernel (nt/2k/xp), really drags the entire system down. You should be excited that Linux is getting in on the ground floor of a fresh, robust, and USEFUL framework so early in the game. Heck, how many Windows apps are written in.NET right now? How many will be in 5-10 years? Exactly. How many years did it take to wean people from Win16? I can tell you that I still have a couple of apps that haven't migrated, and that it took a LOT of other apps more than 3-4 years after Windows 95 was released to make the switch.
The lesson? MS is going to win, because they have the advantage, at least on the desktop. Paradigm shifts (unix->dos->windows->linux) don't happen very often, and you need a lot of geurilla tactics to even have a fighting chance. The best thing I can see is to support.NET on both sides of the coin (hey, you'll soon even be able to throw OSX in there too), and in three or four years, when someone says: "I can't switch from Windows, because app X won't work, or is too slow through Wine," or blah, blah, blah, you'll be able to retort that all of their favorite apps will run natively on Linux or OSX, thus freeing them from any sort of platform dependence.
As an added bonus,.NET is a great tool. C# really does allow some very neat and timesaving features for development. That's the number one reason more people don't develop for Linux/Unix. Some people are too young to remember WHY we left Unix on the big-iron all those years ago, but if we insist on repeating those mistakes, let's at least provide an evironment that can muster some developer support. Not everyone is writing a Word/Excel/Photoshop. Some people like to site down and bang out a few lines of code, and be confident that it'll work as intended, where intended. VB has gone a long way toward keeping the Mom & Pop development shops on Windows. If we can begin to get these folks to consider making cross-platform apps, then half the battle will be over. Now we just need to convince the users of those apps that there are advantages to running them on Linux. Better hurry before Longhorn comes out, too... That may set OSS back 10 years or more, but at least MS has given us an extra three years to innovate in the meantime!
The pointers are actually 64-bit, and the non-used address space at this point is still reserved. They will increase the address space as necessary. So the code would compile and the computer would understand it, but it would point to non-existant memory.
Actually, Nvidia and Alienware are both working on solutions that accomplish this goal. Nvidia's solution is their own (called SLI, probably because they gobbled up 3d Labs -- remember the Voodoo2 boards you could link up?), while Alienware's is (video card) manufacturer independent and based on technology from Metabyte a/k/a Wicked3D. The performance is promising (with gains from 70-90% on various benchmarks).
You can read about Nvidia's solution here, and Alienware's here. The problem is that two x16 PCIe slots are required (PCI-Express, not to be confused with PCI-X which is a different beast altogether). Right now, the only manufacturer shipping PCIe enabled boards is Intel, and even they didn't last too long (see The Grantsdale Recall), but none as of yet have two x16 PCIe slots, other than the "x2" motherboards which are custom OEM to Alienware. I'm sure that in the near future the major tier one motherboard manufacturers like Asus and Gigabyte will provide these solutions as well, but it remains to be seen what kind of price premium can be expected (other than the cost of a second video card!).
That's nothing. In Troy, MI on I-75, about 15 miles north of Detroit, there is Exit 69 - Big Beaver Road.
You know, it took a friend from down south seeing the sign for me to really think about it. It still amazes me that no one noticed before the damage was done. Especially since Big Beaver is a/k/a 16 Mile Road.
You know, unlike Apple, Microsoft is quite capable of writing a very advanced kernel on their own. The NT codebase (not the Win32 API,.NET, the registry, etc.) is actually quite modern, and in fact, surpasses Linux (and old-skool Unix) in many respects. It's a shame, because what you advocate would essentially be a step backwards.
Now if you would have said that you wished they'd get rid of the registry, lock down the system, re-do the privelages (and locations of files), and get rid of all of the crud that has built up since Windows 3.0 I would agree. But to give up on a kernel with so much invested, and a lot of brains behind it would be foolish. Linux, Unix and *BSD are NOT the only kernels in existance, and are certainly not the most modern.
It makes you wonder though, would people cut Microsoft any slack if they did use a different kernel? Nope. At least not on./. The fact of the matter is that NT on Alpha was one of the most rock-stable OSes I ever had the pleasure to use. Guess what? Same kernel. Just a little more sane hardware platform.
It makes you wonder further why MS is waiting so long to release Longhorn. My guess is that they are going to drop another Win95-like bombshell (still using the NT-based kernel), and blow us away with what they have been able to accomplish. Remember, MS is an 800-lb gorilla. It takes her a while to get running, but once she's up to speed (i.e. sick of security problems, buggy drivers, bad PR, etc.), watch out...
Sorry, IANAL, but I AM anal... The judge will put the money into escrow.
A lien is an encumberance to some type of property (real or personal), preventing its sale or other disposition until the terms of the lien are satisfied. So, you'd escrow the funds with the court until they decide who gets what (which is atypical), or in the absence of funds, a judgment would be issued, which would then entitle the judgment holder to execute upon the real and personal property of the loser. Thus, depending upon your state of residence, may include the right to file a lien, execute (i.e. take) on personal property or cash, or even foreclose upon the real property of the loser.
There's a whole host of caveats that I won't go into here, but no one's going to shell out any money for a while in this case simply because our courts move too slow, and SCO is going to counter-sue and also allege a breach of contract on Baystar's part. This is not going to slow down the SCO train in the interim by any means. But down the road it may be the final straw that puts SCO out of business, since most of their frivelous lawsuits should have been dismissed by then.
I'm pretty sure a court of law has the ultimate jurisdiction. Any orgranization can have its own laws and/or bylaws, but a court (U.S. or otherwise) will always have the final say. Look at the NFL and how their rules were recently overturned with respect to Maurice Clarett (age issues). Last I checked, ICANN was not a government body with any *real* authority. While they may make binding decisions, you can always fight them in court and get them overturned.
I was going through my previous orders for systems that I have built over the years, and I thought for sure they were 75GXPs. Unfortunately I was wrong. I purchased over 20 hard drives, all IBM Deskstars: 60GXPs, 120GXPs but only a couple 75GXPs. EVERY SINGLE DRIVE HAS FAILED. What a crock. I still have several sitting here. It would have been nice for IBM to let us know about these failures at the outset, because I had to eat the cost of those drives, and I'm not a multi-billion dollar multinational corporation. I was just a college student who made money during that time of my life selling white boxes. And now, since I only have two 75GXPs, I'll still never see any restitution from IBM.
It makes you wonder what the world would be like if there had never been Microsoft... Not that it's a lot better now, but think of what could have been.... shudder...
Slashdot Mirror
I understand that. That's why I pointed out L4Ka. The problem is with early microkernels and the original Mach design in particular. Without specifically taking the context switching into account, performance is terrible. Embedded realtime operating systems such as QNX are not a good example. They are designed in such a way that they can guarantee realtime performance up to a specific system load, which must not be exceeded for the system to function properly. Remember though, that as of yet QNX is not a general purpose operating system. Further, I suggest you check out the recent performance issues of XNU as compared to Linux for common server applications such as Apache, MySQL, etc. Speed is most certainly an issue, and until a general purpose operating system is designed in such a way as to minimize context switching across system calls, it always will be an issue with separating drivers from kernel and user space.
The problem is that we do not have a modern operating system architecture that is fast enough to allow for drivers to run in another privilege level. Seen the wonderful server performance of OSX? That's what happens when you put drivers at a different privilege level than the kernel. The real issue is twofold. Firstly, context switches are extremely slow, even on modern processors. In the IA-32 architecture, which has three privilege levels, most microkernels have put kernel code at ring 0 (most privileged), drivers at ring 1, and user code in ring 2. But what you end up with is every system call going from user -> driver -> kernel -> driver -> user. This greatly slows down the system, especially in a uniprocessor multitasking operating system. Things get even more complicated when you're trying to write a portable operating system (Linux/*BSD/NT Kernel), since most other chip architectures only offer two privilege levels (user & supervisor).
I guess my point is simply that we've tried this isolation you speak of, but it truly offers horrendous performance, especially graphics subsystems. Take a look at some of the research on Mach, why no one uses it (well, except Apple). Check out Jochen Leudtke's research on the L4Ka microkernel, and how they've gotten near monolithic type speed out of a microkernel by caching calls between privilege levels to minimize context switching.
OS Development is fun! It also allows you to look at the common (and not so common) operating systems in a whole new light. And don't get me started on the Linux kernel. Until the 2.4 series, I could have done better with 6 months and an unlimited supply of pizza and Sun Drop (and no, I can't get the good Sun Drop where I live!!)
So in short, every modern operating system (sans OSX) runs drivers in Kernel mode. It's a necessary evil. Maybe one day, the speed decline will be negligible, but as long as context switches take over 1,000 cycles, and as long as you can trigger tens of thousands of context switches relatively easily in user/driver/system interactions, with very few user-level instructions (i.e. libc), we'll always have this problem.
Actually, it requires the RTDSC instruction, which is Pentium+. CPUs dating back to the 286 (I believe) support the CPUID instruction.
You are so wrong it's not even funny. Do 4 or 5 years of actual OS Development on the x86 and you'll see that your first paragraph alone contains so many errors that I'm actually having a hard time of where to start.
Modern operating systems RARELY use the BIOS. In fact, a protected mode operating system has ZERO need for it. The only reason a modern operating system would ever have for using the BIOS is during development when protected mode drivers have not been written for all devices yet (and you have chicken or egg issues). Stop spreading FUD, please! The BIOS is for backwards compatibility (yes, you can still install DOS 1.0 on any modern machine and it will work fine -- VERY FAST -- but fine) Further, IRQs are handled by the LAPIC and IOAPIC (Local APIC (on chip since Pentium) and IOAPIC (usually present in newer Intel systems and all MP systems for several years)). Your logic is as it related to the 8259 PIC chip (which is still the default at bootup, but is disabled by most modern operating systems soon thereafter). Sorry, but your comment about transformations is simply wrong. Windows (and Linux, *BSD, and I'm sure OSX too) all do these "transformations." It's called using the modern facilities present in the IA32 (and x86-64) architecture for controlling hardware interrupts, non-maskable interrupts (NMI), software interrupts, call gates, and task gates. There is no sham going on, it really is different.
Apple is not going to use something that is non-standard because it is not cost effective. Why continue to design chipsets and motherboards when they don't have to? Why do redundant R&D? Asus has made Mac motherboards for years. Apple has no fabs. It only costs them money (of which they could never pour in as much as the Wintel PC industry). Apple isn't doing these things because Apple has engineers that understand the PC platform, understand the progress it's made over the last 20 years, and are not running around like chicken little talking about OpenFirmware, BIOS, EFI, Itanium, and all the other nonsense being spewed forth by Mac users who just don't understand that the arguments they were fed for years about the PC Platform simply do not exist anymore (or only exist in legacy and/or compatibility configurations).
Breathe guys... Everything will be fine!
Did you even read the quote you quoted? Where does it say that Apple would not be based on x86? This is an incorrect quote by whoever wrote the second part of this comment. The new Macintoshes will MOST CERTAINLY be x86. Go and read Apple's Universal Binary Development Guide. I don't know what's so hard to understand about #1) They're NOT using OpenFirmware; #2) The Intel platform IS x86 and 32-bit (although this article seems to suggest that OSX 10.5 Leopard will be the first 64-bit OSX from the ground up on both PPC and Intel Platforms); #3 speculation is that Apple is going to use a custom chip to prevent OSX from running on non-Apple hardware, which it will most certainly do (for a time), but it will not prevent Windows from running (as Apple has said, time and again -- showing that the Intel Macs will be close enough to vanilla x86 architecture to run it without too much trouble).
Too many Mac users that know NOTHING about hardware because they've been in Steve's RDF for 20 years. I can't tell you how many rants I've seen from third-party Mac hardware developers complaining about BIOS and how crappy it is and even, *gasp* real-mode! What idiots! What does BIOS and/or real-mode have to do with a modern operating system running in protected mode? What do 16 IRQs have to do with modern IOAPIC/APIC which can trigger up to 256 different interrupt lines? Nothing. FUD. They're upset because now they have to compete with PC hardware vendors, where they'll get roasted on quality, price and performance... Here's a hint to Apple users: If you want to know about PC Hardware, where the industry is going, what has happened in the past 20 years on this side of the fence -- ASK A PC USER, OR GO TO A PC HARDWARE WEB-SITE. STOP READING MAC SITES WHERE THE JOURNALISTS ACTUALLY KNOW LESS THAN THE USERS.
Sorry for yelling....
Whoops. Everytime I submit without previewing this happens. Sorry... I meant to say that unless you're still using Office 97, you won't have a problem with reading or writing the new formats, thus taking care of the interoperability issue.
Except for the fact that, at least according to this ZDNet article, Microsoft is backporting the XML reading and writing capability to Office 2000, XP & 2003. So unless you're still using Office 97 (admittedly, there are still many, but it IS 9 years old!). So, what about your point now??
You should try AerialLink. They have several fixed wireless plans that are competitively priced. The speeds can be phenomenal as well. I've set up a few clients with the service, and it's been great. You do have to worry about signal degradation, so if you're in a heavily wooded area this might not be an option, but if you're not, you should check them out.
Yeah whatever. Let me know when it's *REALLY* an OS. As soon as I can build the tools that I want (99% GNU), without heavy modification, I don't consider OSX to be anything other than part of Steve Jobs' reality distortion field. Maybe simple apps work fine, but have you seen all of the work that goes into porting just for OSX (check out DarwinPorts and/or Fink). Hell, I can get the same functionality from Windows through Cygwin, MinGW, or SFU. As a matter of fact, most development tools i've had the (mis)pleasure of building on OSX have worked flawlessly on Linux and Cygwin. And don't get me started on the GUI. I'm so sick of hearing about how great the OSX GUI is. So it's got slick animations. BFD. Why is it so difficult to know what programs are open? Why can't I jump quickly between my windows? What's the point of the "spatial" orientation? It's just ass-backward. The mouse support sucks (even with an MS Intellimouse Explorer). Context menus are weak, and offer very few options. Why should I have to hit a key combination to go to any folder on my hard drive? Why can't I easily view the contents of the *nix filesystem? The list goes on and on.
I'm sure you MacHeads have valid explanations for all of my issues, and it probably is relatively simple, however I simply prefer the Windows/KDE way of doing things. You know, I really am disappointed, because I heard how great OSX was, with the *BSD-like underpinnings, etc. It just didn't live up to the hype. As a matter of fact, it behaves pretty much like every other MacOS that was released previously, with the exception of being prettier and having a little more muscle under the hood.
Flame on!
Very true, and I was thinking the same thing when I read the blurb. Further, they don't include sales of DVD players themselves either, whereas the games industry most certainly includes the hardware sales dollars from dedicated consoles. Then you can also talk about international distribution and other market's native films, etc., etc.. Hollywood (and television in general) still makes many, many times what the videogame industry does.
Words of wisdom from Slashdot regarding whether Microsoft is being racist or classist...
...blah, blah, blah..., oh yeah, and the conclusion:
Anyone with half a brain would pick classist, because it actually has some relevance.
So Microsoft really doesn't have a "pick" - they're being pretty racist here.
Where the hell'd that other half of my brain go again??
Well, that's *sorta* true. If you noticed, I went on a mission on Friday, just about an hour after I found out that SP2 had been released. I could not be sure that what I was getting on a P2P network was in fact a true copy (and as a matter of fact, I didn't see *any* copies), while I had several sources on various message boards verify the one in the newsgroup. So, while it looks like a pain, it really is just three steps, since the newsleecher software was pretty straightforward, the verifier took about 4 seconds to run, and WinRAR extracted all 19 parts in one step. By now, three days later, more people have had the opportunity to d/l the file, and obviously there are a ton of torrents and I'm sure it's all over Kazaa, etc.
Just another method that happens to be very fast, although you are correct that there are easier ones. This was for the hardcore user who wants the file quickly and is not able to get through to MS, doesn't have good d/l on a torrent, or who cannot get decent speed from a P2P app.
Ok guys, this is the quickest and easiest way (especially if on broadband) to get SP2. Get newsleecher, then go to alt.binaries.wares.ibm-pc.ms-beta, and download the WindowsXP-SP2-2180-ENU-FINAL files (there's 28 of them). Yes, one small file is missing (about 22k). The file ships with a Parchive parity file (.PAR2) to reconstruct and/or correct any data that did not come through. You can get the PAR2 verifier from here. Now what do you do? Well, you will be left with 19 .rar files, so UNRAR them!! You will be left with a filename slightly different from the original, but this is in fact the correct build. MD5 Sum and crc32 verified with fsum (59A98F181FE383907E520A391D75B5A7 & 046F12B1, respectively). Have fun! And best of all?? If you're on broadband, it's fast, especially since you're not leaving the local provider's network (assuming your provider hosts their own news servers).
By the way, I do not normally get software this way, but on Friday it was my mission to get SP2, and get the real one. This worked and was fairly simple. If you've just got to have it, you can use this method. It is the correct service pack, and it works fine! Hope this helps..
I personally think this has been the big delay in getting VPC7 to market. The performance must be abysmal. While the PPC970 can still perform endian swapping calculations quickly (as can the x86), the inability to mark specified regions of memory (code, data, stack) as big or little endian was of great importance. Now, every time an instruction is executed, the calculations must be performed. My guess is that MS is going to be very careful about performance on this issue. Everyone already has their eye out for their sinister intentions after having purchased Connectix, and imagine the ammo it'll give their detractors if VPC7 runs slower on G5s than it did on previous generation Apple hardware. I personally think the real reason for MS's purchase of Connectix was for their server virtualization technology which they needed in order to keep pace with VMWare's GSX Server and IBM's work on running multiple Linux kernels on big iron. But, I guess everywhere there's smoke, there's fire...
Actually, with the G5 (PPC970) chip, IBM did away with the endian swapping feature. This is what has kept VirtualPC from running on the G5s. Wonder why they got rid of the feature? My guess is that die size limitations simply would not allow the required support logic anymore, especially when multiple 970 cores get lumped together on a single chip in the POWER family.
I'll bite, even though you're an AC. You must understand that everything evolves in the computer world. We do not simply make new things up. The tools available at our disposal are the result of an evolutionary process that has gone on for 50+ years.
.NET is most certainly not any of those things you presented. .NET is the new version of Win32, which we all know, as a subsystem to a pretty amazing kernel (nt/2k/xp), really drags the entire system down. You should be excited that Linux is getting in on the ground floor of a fresh, robust, and USEFUL framework so early in the game. Heck, how many Windows apps are written in .NET right now? How many will be in 5-10 years? Exactly. How many years did it take to wean people from Win16? I can tell you that I still have a couple of apps that haven't migrated, and that it took a LOT of other apps more than 3-4 years after Windows 95 was released to make the switch.
.NET on both sides of the coin (hey, you'll soon even be able to throw OSX in there too), and in three or four years, when someone says: "I can't switch from Windows, because app X won't work, or is too slow through Wine," or blah, blah, blah, you'll be able to retort that all of their favorite apps will run natively on Linux or OSX, thus freeing them from any sort of platform dependence.
.NET is a great tool. C# really does allow some very neat and timesaving features for development. That's the number one reason more people don't develop for Linux/Unix. Some people are too young to remember WHY we left Unix on the big-iron all those years ago, but if we insist on repeating those mistakes, let's at least provide an evironment that can muster some developer support. Not everyone is writing a Word/Excel/Photoshop. Some people like to site down and bang out a few lines of code, and be confident that it'll work as intended, where intended. VB has gone a long way toward keeping the Mom & Pop development shops on Windows. If we can begin to get these folks to consider making cross-platform apps, then half the battle will be over. Now we just need to convince the users of those apps that there are advantages to running them on Linux. Better hurry before Longhorn comes out, too... That may set OSS back 10 years or more, but at least MS has given us an extra three years to innovate in the meantime!
That being said,
The lesson? MS is going to win, because they have the advantage, at least on the desktop. Paradigm shifts (unix->dos->windows->linux) don't happen very often, and you need a lot of geurilla tactics to even have a fighting chance. The best thing I can see is to support
As an added bonus,
The pointers are actually 64-bit, and the non-used address space at this point is still reserved. They will increase the address space as necessary. So the code would compile and the computer would understand it, but it would point to non-existant memory.
Actually, Nvidia and Alienware are both working on solutions that accomplish this goal. Nvidia's solution is their own (called SLI, probably because they gobbled up 3d Labs -- remember the Voodoo2 boards you could link up?), while Alienware's is (video card) manufacturer independent and based on technology from Metabyte a/k/a Wicked3D. The performance is promising (with gains from 70-90% on various benchmarks).
You can read about Nvidia's solution here, and Alienware's here. The problem is that two x16 PCIe slots are required (PCI-Express, not to be confused with PCI-X which is a different beast altogether). Right now, the only manufacturer shipping PCIe enabled boards is Intel, and even they didn't last too long (see The Grantsdale Recall), but none as of yet have two x16 PCIe slots, other than the "x2" motherboards which are custom OEM to Alienware. I'm sure that in the near future the major tier one motherboard manufacturers like Asus and Gigabyte will provide these solutions as well, but it remains to be seen what kind of price premium can be expected (other than the cost of a second video card!).
That's nothing. In Troy, MI on I-75, about 15 miles north of Detroit, there is Exit 69 - Big Beaver Road.
You know, it took a friend from down south seeing the sign for me to really think about it. It still amazes me that no one noticed before the damage was done. Especially since Big Beaver is a/k/a 16 Mile Road.
And yet you always have the option of hitting the back button in your browser instead of submit.
If only this choice was made more often....
You know, unlike Apple, Microsoft is quite capable of writing a very advanced kernel on their own. The NT codebase (not the Win32 API, .NET, the registry, etc.) is actually quite modern, and in fact, surpasses Linux (and old-skool Unix) in many respects. It's a shame, because what you advocate would essentially be a step backwards.
./. The fact of the matter is that NT on Alpha was one of the most rock-stable OSes I ever had the pleasure to use. Guess what? Same kernel. Just a little more sane hardware platform.
Now if you would have said that you wished they'd get rid of the registry, lock down the system, re-do the privelages (and locations of files), and get rid of all of the crud that has built up since Windows 3.0 I would agree. But to give up on a kernel with so much invested, and a lot of brains behind it would be foolish. Linux, Unix and *BSD are NOT the only kernels in existance, and are certainly not the most modern.
It makes you wonder though, would people cut Microsoft any slack if they did use a different kernel? Nope. At least not on
It makes you wonder further why MS is waiting so long to release Longhorn. My guess is that they are going to drop another Win95-like bombshell (still using the NT-based kernel), and blow us away with what they have been able to accomplish. Remember, MS is an 800-lb gorilla. It takes her a while to get running, but once she's up to speed (i.e. sick of security problems, buggy drivers, bad PR, etc.), watch out...
the only other code it uses are the .NET class libraries which are licensed under the LGPL.
.NET Class Libraries are licensed under the LGPL.
I don't know my ass from a hole in the ground, but I highly doubt Microsoft's
Sorry, IANAL, but I AM anal... The judge will put the money into escrow.
A lien is an encumberance to some type of property (real or personal), preventing its sale or other disposition until the terms of the lien are satisfied. So, you'd escrow the funds with the court until they decide who gets what (which is atypical), or in the absence of funds, a judgment would be issued, which would then entitle the judgment holder to execute upon the real and personal property of the loser. Thus, depending upon your state of residence, may include the right to file a lien, execute (i.e. take) on personal property or cash, or even foreclose upon the real property of the loser.
There's a whole host of caveats that I won't go into here, but no one's going to shell out any money for a while in this case simply because our courts move too slow, and SCO is going to counter-sue and also allege a breach of contract on Baystar's part. This is not going to slow down the SCO train in the interim by any means. But down the road it may be the final straw that puts SCO out of business, since most of their frivelous lawsuits should have been dismissed by then.
I'm pretty sure a court of law has the ultimate jurisdiction. Any orgranization can have its own laws and/or bylaws, but a court (U.S. or otherwise) will always have the final say. Look at the NFL and how their rules were recently overturned with respect to Maurice Clarett (age issues). Last I checked, ICANN was not a government body with any *real* authority. While they may make binding decisions, you can always fight them in court and get them overturned.
I was going through my previous orders for systems that I have built over the years, and I thought for sure they were 75GXPs. Unfortunately I was wrong. I purchased over 20 hard drives, all IBM Deskstars: 60GXPs, 120GXPs but only a couple 75GXPs. EVERY SINGLE DRIVE HAS FAILED. What a crock. I still have several sitting here. It would have been nice for IBM to let us know about these failures at the outset, because I had to eat the cost of those drives, and I'm not a multi-billion dollar multinational corporation. I was just a college student who made money during that time of my life selling white boxes. And now, since I only have two 75GXPs, I'll still never see any restitution from IBM.
It makes you wonder what the world would be like if there had never been Microsoft... Not that it's a lot better now, but think of what could have been.... shudder...