Lets say x86 instead, and then the meaning becomes clear. The reason we say "Intel" when we mean "x86" is because, no matter how many other manufacturers make x86 chips (Via, AMD, and doesn't Unisys have there own x86 chip?) the technology is Intel's. All the other companies are niche players when it comes to controlling x86 technology. Via is for embedded, AMD is for price to power in the midrange market, and Unisys is x86 for mainframes.
The fact that AMD seems to be getting the upperhand in driving x86 technology doesn't change the fact that there is one technology which dominates the market, and everybody else either controls a nice slice with another technology, or competes with the major x86 player in a more specialized niche.
Alpha is dead, UltraSPARC is in doubt, and Via seems intent on shoving ARM out of the market. m68k is an abberation. There are two battles left. The battle of the archetecture (x86-64 vs POWER5/PowerPC), and the battle of x86 innovation (AMD vs Intel). That's sad.
Also, to clarify some other posts, Barbara McClintock, while a brilliant scientist who did some facintating genetic work (transposons being the most famous, but her work on crossing over also worth a look), was not the unsung female hero of the double helix. Unlike Franklin, who did get shafted, McClintock won the Noble Prize in 1983, just like she deserved. I am astounded how many people get righteous about the Rosalind Franklin, but use McClintock's name. Sad really, that she had so little hold that even her champions have forgotten her name.
This is semi objective. I have a very minor presence in the X.org mailing lists.
XFree86 seems to be mostly listing, with it's major focus being drivers. It was always easier to get new extensions in XFree than in the reference implementation, but that was still hard, so driver's and performance were much of it's force and they seem to think that it still will be. XFree seems to think that they will be the application that people upgrade to from X.org for their value added improvements. Short term assessment, this is a load of crap. People are moving from distro's X.org and XFree ONLY for stability concerns, and those are easily assuaged.
X.org is all about two things. One, take the protocol to the next level, through the judicious use of extensions. X.org has support from Sun and HP, for example, Sun is moving much of their Looking Glass work into the tree.
Second, get the implementation out of the stone age. Modularize the build, and use a more modern build system. Clean up the DDX (device dependent X) get extensions playing well with each other, havea faster release cycle and get security and bug fixes from vendors incorperated more quickly. All of this seems to be happening. Hop on the X.org mailing lists and take a look.
It's 1988 and the X Consortium is the maintainer of the X protocol and it's reference implementation. The reference implementation goes through 6 major releases. Release 6 goes through (i think) 3 minor revisions with the X Consortium. X11R6.3.0
X consortium dissolves, and maintainance passes to the Open Group.
The Open Group establishes X.org an independent group to maintain the standard, after TOG make a serious licencing blunder with X11R6.4.0 which pisses off XFree86. XF86 basically threatens to perform a complete fork rather than a parrallel implementation if the licence changes, TOG backs out and X.org gets formed.
X.org makes a few releases - keep in mind that they maintain a reference implementation, whereas XFree86 seems to be focused on drivers and features, based on the X.org code. This starts with (again, I think) R6.5.1.
Fast forward, David Dawes of XF86 pisses off everybody whose an important developer in his project (notably Keith Packard), and then threatens to change the licence. X.org has been thinking of making their position in their relationship with XF86 more dominant anyway and the whole thing culminates in a full fledged fork of XF86 prior to the licence change. This code is worked on, some random bug fixes are included, and many of the GPL incompatible licence cahnges are released by the original developers under the X.org licence, bada boom bada bing, X11R6.7.0.
There are two (well, three) buffers for clipboard-like functionality.
The first is maintained by the X server, this is the Ctrl+c/v that you expect in windows. The second is maintained by the application, which is the middle click behavior. These are orthogonal.
The problem is applications screw it up. The first way they could screw this up is to confuse these buffers, so ctrl+c clobbers your application buffer, or vice versa. More complicating is that GNOME preserves the highlight buffer it makes it persistent across closing apps - not really broken, but is unexpected (to me at least).
The other way to screw up is to not use a standard keyboard shortcut for copy and paste, forcing you to use the highlight-middle click tactic inappropriately. It's really only intended for quick fixes, usually within the application. I use it to copy to the URL bar from a webpage.
One could argue that it's X's problem for making it hard on developers, but at this point we're stuck. Trillian on Windows kills me by implementing the highlight and click on Windows, and NOT Copy/Paste.
For the kinds of complaints about Linux swap I've been seeing of late, it would be bogus to call swap the issue, really. People looking to eliminate swap entirely on desktop machines are cutting off the arm for the sake of a finger.
The issue with swapping in a desktop system is that perception of system responsiveness is almost as important as real performance, and swapping in (actually, it's paging in, but that's semantics) causes high latecy. This is especially noticeable when returning to an idle machine. So we want to cut latency.
People say "the kernel shouldn't swap unless it can't fit everything it needs in system memory." Duh! And it doesn't! It's swapping to increase the size of the file cache, a huge performance win. If the file cache gets too small (say, because this Wal-Mart PC only has 128 megs of RAM, and you've turned off swap, so Moz is eating it all) then you wind up with disk seeks for harddrive intensive applications, causing the same latency as swap.
What's clear to me from these complaints is that the file cache isn't smart enough. People with lots of RAM want to cut down on all these disk reads - that's why they got gobs of RAM. (Ain't it funny that the same Linux heads who say that Linux makes a little machine fly also say that a desktop has no reason to have less than 512MB or 1GB of RAM). At the same time, smaller machines should still be supported, and even folks with gobs of RAM don't want to elimiate swap, otherwise disk bound apps suffer the same latency they're trying to eliminate.
The Linux file cache seems too aggressive for most users. Ext2 loves a file cache like no other filesystem, and this probably influenced the design. If the file cache can be smarter about when to swap to grow itself, and when it should just be content to use up all available system memory, then lots of these latency issues can be fixed in a way which will scale across both hardware and multiple use environments.
I train Tech Support agents to use a Macintosh. Screenshots, to a tech support agent, means thorough screenshots that illustrate how to use and OS or application.
Recently, there has been a tendency to use image maps to simulate an OS using screenshots. But I've been looking for a decent flash based view of System 8 or 9 that agents could use at their desks. Kept meaning to do it myself, but I'd have to teach myeslf Actionscript . . .
I've been working tech support for an ISP for years, and this guys fundamental conclusion is correct - Joe User can't keep his system secure - he just can't. And Joe Sysadmin has a damn hard time of it himself.
The amount of "repair" functionality inside of MS products is a huge sign that users and developers are sick of the reinstall cycle, but that the OS design makes it very difficult to fix. Internet Explorer, Outlook Express, Office all have "repair my installation" tools built in, XP and ME have System Restore.
I have watched users get the Sasser virus, run system restore, have system restore break the XP firewall, cause a port lockdown, resolve the port lockdown so they can run windows update, only to become reinfected with the sasser. Maintainence of Windows is hard, OS reinstall is easy. OEM aren't value adding to the OS by providing solid maintanence tools, their providing restore disks, because writing such a maintanence tool is INCREDIBLY difficult.
I understand MS's need to stay commited to this design, at least through Longhorn and it's revs. But as long as you are, MS, please give us a non network dependent tool for maintaining and distributing patches and updates. Let OEMs and (in my case) ISPs ship critical fixes on CD so that we can help our users. Make System Restore a fine grained tool, where I can back up critical system files and DLLs, as well as the registry. Don't force me to go to a third party for a "registry cleaner". Provide me with the OS for the tools that I need and that vendors need to maintain the OS.
Remind Anyone of Blaster
on
A Worm's Worm
·
· Score: 5, Interesting
Gosh, this whole mess looks just like Blaster from down here in the trenches.
I'm tech support for Tremendously Large ISP. From down here this looks just like Blaster did. Customers calling in complaining that their machine is restarting without their consent. And now someone has a follow up virus that attacks the virus - as some may recall there was a Blaster variant that patched systems AGAINST Blaster. This was terrible - if you got this variant inside a corporate network not only would your bandwidth use skyrocket, but since NAT tends to fubar Windows Update, the variant never managed to patch a system. God that was hell . ..
It's almost enough to make you want to write a virus in revenge . . .
How is this any different from, say AbiWord, where the app is GPL, but some of the underlying classes derive from the closed source unerpinings of the OS?
I'm not trying to be snarky - is there a real substantive difference?
The text isn't "backwards looking". It is a discussion of how one man implented a file system, and how filesystems are generally implemented. Dominic himself comments that his book is a textbook of sorts (or the textbook he wishes he's had in Graduate School, where he did FS work) and that BeFS is an attempt to implement already existing functionality of the BeOS (where they were using a true database as a file system) using tried and true methods. In fact he bemoans that he couldn't do any real research.
Additionally, the relational model is a great way to organize your data. You want to know how x relates to y in your data set. A file system is a way to store and retrieve arbitrary, heterogenous data, with loose or no relationship. File system metadata should be arbitrary, extensible, and changable on the fly. I don't want a "MAIL:From" entry to persist in any sort of DB where said entry exists for the kernel image, or my C compiler.
A file system is not a data set where a mathematical model can be used to express tight relationships between said data. The so called "database" like qualities of the BeOS were seperate from a true relational model. The true essence of the relational model is just that - the ability to talk about complex interactions and tight linkages between data, the fact that I can then use that to do things I'd like my filesystem to do, is not a reason to build all that ridiculous overhead, in terms of performance, disk usage, and potentially buggy implementation complexity into my filesystem.
Last I checked, the number of female gamers was skyrocketing. It doesn't matter that the medium was (or even still is predominately) male. Bored housewives are surfing - check your spam. Those breast enhancement boobs (haha - it's a pun!) know something about their market.
Just because it's a predominately male medium doesn't mean that there isn't money to be made by innovating and deploying in that medium. In fact, the person who does it right and does it first will probably make the biggest impact.
Besides, the internet is good at being able to track niche markets, so even though though women are only 1/3 of the market it's still a potentially high yielding enterprise. And eventually the number of women online will increase, once they have something they want to see.
(Additional questions - where did you get your numbers? Are there stats for who spends more money online, which demographic has higher ad clickthrough rates, what kind of sites does each demographic tend to view, or in fact, any relevant statistic at all?)
Tell the truth, this could probably be successful. It's an extension of a traditional idea that has been moved to a medium which is actually superior for delivering that kind of content.
People already lap up blogs and celebrity websites, and watch webcams with frightening regularity, and soap fans already have a large stream of spolier mags and dedicated websites. Now that the dotcom boom has passed, it's more likely that someone will actually generate a decent way to generate money from the system rather than think "it's on the intarweb! It must be profitable".
The only real issue I see with this is there is real competition with actual weblogs and "legitimate" celebrity webpages, where the content is free and more "true to life".
Wine and ReactOS *are* sharing code and ideas. Wine is really a reimplementation of the Win32 API, and ReactOS is working with them both to improve the Wine DLLs as well as port those DLLs to the ReactOS kernel.
Wine does work with native Windows DLLs, and so will ReactOS (may now, not sure). As for how hard it is to emulate Windows, it's hard. The Windows runtime is a twist maze of libraries all alike, and it's not just source compat were after here, its binary compat.
And as for lusers and their software, the disadvantages of a closed system have been widely discussed here on/. This could allow companies to upgrade at their own pace, rather than at Microsoft's, and allows public code review for security holes. This isn't just lusers, this is large corporate installs of NT gaining a signifigantly different and more flexible upgrade path.
Every P2P application since napster has started in the Windows system tray in order to increase the amount of stuff available at once. BT's design means that it can't work quite the same way - stuff is only shared while your downloading the thing, and rather than share a pool of files, you share individual files while your connected to a tracker.
It's not unusual (though thankfully not too usual) to be downloading via BT and all your seeders vanish or no current seeder has all parts of the file your after. Staying connected for an extra 5-10 minutes is a simple way to increase traffic, and is generally considered polite.
When we say "Open Sourcing" why do we really mean "GPL"? Granted, the GPL has the advantage from Sun's point of view, as they get any changes back.
But Perl was released for the longest time under the Artistic licence, which (IIRC) allows derivitive works, but doesn't allow you to call them Perl. This could keep the one, true source of Java unsullied by broken or incompatible implementations yet gives everybody else the hope that when Sun tanks Java won't.
Think about it this way - Groklaw has been respected for a while, after all, much more respected than Joe Slashdot poster.
Plus, they're putting they're money where their mouth is. Although a look at the numbers says that it might still be cost prohibitive to go with OSRM rather than pay $699 to SCO, but OSRM has some pretty powerful arguments on their side.
There was some talk of a drop in PCI card which had the old chips on it. This has since proven to be an unworkable solution, mostly because the whole OS 4/AmigaOne enterprise has got about as much cash as my 8 year old sister now that she's lost some teeth.
A more workable, and highly likely solutions, is the integration of AmigaForever into a point release of OS 4. I've heard some talk that this is in the works.
I won't get into the full history of the Amiga hardware platform, a clever frankenstein of processors. The old Amiga was a 68k platform primarily, the "new" Amiga runs on a PowerPC platform called the AmigaOne. For those who care, the OS was ported using the same technique that Apple used to port the MacOS from 68k to PPC, using a 68k emulator for as yet unported code.
Actually, I can find several references after a quick google search, but most of them seem bogus.
The most reputable paper I could find was this, which refers to testing possible side effects of the fluid when used on dogs. Could be full of horse shit.
My uncle is the head network admin over Coke's leagal department in Atlanta. His biggest amazement is the lawyers who say "But I love Gator!" They are numerous. The danger is not people who install Gator, never use it for anything, and never cry when the junk is removed. It's the people with slightly more grey matter who install it willingly and want it's features, and then become entrenched users.
Surprisingly, it's really the lawyers who are the biggest culprits over the secretaries and clerical staff. Most of those folks recognize that they are dealing with company property designed for business, whereas the lawyer gets a 2GHz laptop for company work and considers it hers. Then they jam a Cap'n Crunch CD packaged with their kids cereal, and boom they've got Gator (and sugar on the CD lazer).
Slashdot Mirror
Lets say x86 instead, and then the meaning becomes clear. The reason we say "Intel" when we mean "x86" is because, no matter how many other manufacturers make x86 chips (Via, AMD, and doesn't Unisys have there own x86 chip?) the technology is Intel's. All the other companies are niche players when it comes to controlling x86 technology. Via is for embedded, AMD is for price to power in the midrange market, and Unisys is x86 for mainframes.
The fact that AMD seems to be getting the upperhand in driving x86 technology doesn't change the fact that there is one technology which dominates the market, and everybody else either controls a nice slice with another technology, or competes with the major x86 player in a more specialized niche.
Alpha is dead, UltraSPARC is in doubt, and Via seems intent on shoving ARM out of the market. m68k is an abberation. There are two battles left. The battle of the archetecture (x86-64 vs POWER5/PowerPC), and the battle of x86 innovation (AMD vs Intel). That's sad.
Here, here!
Also, to clarify some other posts, Barbara McClintock, while a brilliant scientist who did some facintating genetic work (transposons being the most famous, but her work on crossing over also worth a look), was not the unsung female hero of the double helix. Unlike Franklin, who did get shafted, McClintock won the Noble Prize in 1983, just like she deserved. I am astounded how many people get righteous about the Rosalind Franklin, but use McClintock's name. Sad really, that she had so little hold that even her champions have forgotten her name.
This is semi objective. I have a very minor presence in the X.org mailing lists.
XFree86 seems to be mostly listing, with it's major focus being drivers. It was always easier to get new extensions in XFree than in the reference implementation, but that was still hard, so driver's and performance were much of it's force and they seem to think that it still will be. XFree seems to think that they will be the application that people upgrade to from X.org for their value added improvements. Short term assessment, this is a load of crap. People are moving from distro's X.org and XFree ONLY for stability concerns, and those are easily assuaged.
X.org is all about two things. One, take the protocol to the next level, through the judicious use of extensions. X.org has support from Sun and HP, for example, Sun is moving much of their Looking Glass work into the tree.
Second, get the implementation out of the stone age. Modularize the build, and use a more modern build system. Clean up the DDX (device dependent X) get extensions playing well with each other, havea faster release cycle and get security and bug fixes from vendors incorperated more quickly. All of this seems to be happening. Hop on the X.org mailing lists and take a look.
A quick check of hashes pending results shows that not only will you know, but also the 52 dronelike /.ers who submitted the same hash.
Tip: Change your password.
That's what linuxpackages.net is for. It's an independent location for slack packages.
It's 1988 and the X Consortium is the maintainer of the X protocol and it's reference implementation. The reference implementation goes through 6 major releases. Release 6 goes through (i think) 3 minor revisions with the X Consortium. X11R6.3.0
X consortium dissolves, and maintainance passes to the Open Group.
The Open Group establishes X.org an independent group to maintain the standard, after TOG make a serious licencing blunder with X11R6.4.0 which pisses off XFree86. XF86 basically threatens to perform a complete fork rather than a parrallel implementation if the licence changes, TOG backs out and X.org gets formed.
X.org makes a few releases - keep in mind that they maintain a reference implementation, whereas XFree86 seems to be focused on drivers and features, based on the X.org code. This starts with (again, I think) R6.5.1.
Fast forward, David Dawes of XF86 pisses off everybody whose an important developer in his project (notably Keith Packard), and then threatens to change the licence. X.org has been thinking of making their position in their relationship with XF86 more dominant anyway and the whole thing culminates in a full fledged fork of XF86 prior to the licence change. This code is worked on, some random bug fixes are included, and many of the GPL incompatible licence cahnges are released by the original developers under the X.org licence, bada boom bada bing, X11R6.7.0.
we should say OS 9 is dead. The death of an entire OS is more notable than the change from 32 to 64 bit.
There are two (well, three) buffers for clipboard-like functionality.
The first is maintained by the X server, this is the Ctrl+c/v that you expect in windows. The second is maintained by the application, which is the middle click behavior. These are orthogonal.
The problem is applications screw it up. The first way they could screw this up is to confuse these buffers, so ctrl+c clobbers your application buffer, or vice versa. More complicating is that GNOME preserves the highlight buffer it makes it persistent across closing apps - not really broken, but is unexpected (to me at least).
The other way to screw up is to not use a standard keyboard shortcut for copy and paste, forcing you to use the highlight-middle click tactic inappropriately. It's really only intended for quick fixes, usually within the application. I use it to copy to the URL bar from a webpage.
One could argue that it's X's problem for making it hard on developers, but at this point we're stuck. Trillian on Windows kills me by implementing the highlight and click on Windows, and NOT Copy/Paste.
For the kinds of complaints about Linux swap I've been seeing of late, it would be bogus to call swap the issue, really. People looking to eliminate swap entirely on desktop machines are cutting off the arm for the sake of a finger.
The issue with swapping in a desktop system is that perception of system responsiveness is almost as important as real performance, and swapping in (actually, it's paging in, but that's semantics) causes high latecy. This is especially noticeable when returning to an idle machine. So we want to cut latency.
People say "the kernel shouldn't swap unless it can't fit everything it needs in system memory." Duh! And it doesn't! It's swapping to increase the size of the file cache, a huge performance win. If the file cache gets too small (say, because this Wal-Mart PC only has 128 megs of RAM, and you've turned off swap, so Moz is eating it all) then you wind up with disk seeks for harddrive intensive applications, causing the same latency as swap.
What's clear to me from these complaints is that the file cache isn't smart enough. People with lots of RAM want to cut down on all these disk reads - that's why they got gobs of RAM. (Ain't it funny that the same Linux heads who say that Linux makes a little machine fly also say that a desktop has no reason to have less than 512MB or 1GB of RAM). At the same time, smaller machines should still be supported, and even folks with gobs of RAM don't want to elimiate swap, otherwise disk bound apps suffer the same latency they're trying to eliminate.
The Linux file cache seems too aggressive for most users. Ext2 loves a file cache like no other filesystem, and this probably influenced the design. If the file cache can be smarter about when to swap to grow itself, and when it should just be content to use up all available system memory, then lots of these latency issues can be fixed in a way which will scale across both hardware and multiple use environments.
I train Tech Support agents to use a Macintosh. Screenshots, to a tech support agent, means thorough screenshots that illustrate how to use and OS or application.
Recently, there has been a tendency to use image maps to simulate an OS using screenshots. But I've been looking for a decent flash based view of System 8 or 9 that agents could use at their desks. Kept meaning to do it myself, but I'd have to teach myeslf Actionscript . . .
I've been working tech support for an ISP for years, and this guys fundamental conclusion is correct - Joe User can't keep his system secure - he just can't. And Joe Sysadmin has a damn hard time of it himself.
The amount of "repair" functionality inside of MS products is a huge sign that users and developers are sick of the reinstall cycle, but that the OS design makes it very difficult to fix. Internet Explorer, Outlook Express, Office all have "repair my installation" tools built in, XP and ME have System Restore.
I have watched users get the Sasser virus, run system restore, have system restore break the XP firewall, cause a port lockdown, resolve the port lockdown so they can run windows update, only to become reinfected with the sasser. Maintainence of Windows is hard, OS reinstall is easy. OEM aren't value adding to the OS by providing solid maintanence tools, their providing restore disks, because writing such a maintanence tool is INCREDIBLY difficult.
I understand MS's need to stay commited to this design, at least through Longhorn and it's revs. But as long as you are, MS, please give us a non network dependent tool for maintaining and distributing patches and updates. Let OEMs and (in my case) ISPs ship critical fixes on CD so that we can help our users. Make System Restore a fine grained tool, where I can back up critical system files and DLLs, as well as the registry. Don't force me to go to a third party for a "registry cleaner". Provide me with the OS for the tools that I need and that vendors need to maintain the OS.
Gosh, this whole mess looks just like Blaster from down here in the trenches.
.
I'm tech support for Tremendously Large ISP. From down here this looks just like Blaster did. Customers calling in complaining that their machine is restarting without their consent. And now someone has a follow up virus that attacks the virus - as some may recall there was a Blaster variant that patched systems AGAINST Blaster. This was terrible - if you got this variant inside a corporate network not only would your bandwidth use skyrocket, but since NAT tends to fubar Windows Update, the variant never managed to patch a system. God that was hell . .
It's almost enough to make you want to write a virus in revenge . . .
How is this any different from, say AbiWord, where the app is GPL, but some of the underlying classes derive from the closed source unerpinings of the OS?
I'm not trying to be snarky - is there a real substantive difference?
Well. I'll bite.
The text isn't "backwards looking". It is a discussion of how one man implented a file system, and how filesystems are generally implemented. Dominic himself comments that his book is a textbook of sorts (or the textbook he wishes he's had in Graduate School, where he did FS work) and that BeFS is an attempt to implement already existing functionality of the BeOS (where they were using a true database as a file system) using tried and true methods. In fact he bemoans that he couldn't do any real research.
Additionally, the relational model is a great way to organize your data. You want to know how x relates to y in your data set. A file system is a way to store and retrieve arbitrary, heterogenous data, with loose or no relationship. File system metadata should be arbitrary, extensible, and changable on the fly. I don't want a "MAIL:From" entry to persist in any sort of DB where said entry exists for the kernel image, or my C compiler.
A file system is not a data set where a mathematical model can be used to express tight relationships between said data. The so called "database" like qualities of the BeOS were seperate from a true relational model. The true essence of the relational model is just that - the ability to talk about complex interactions and tight linkages between data, the fact that I can then use that to do things I'd like my filesystem to do, is not a reason to build all that ridiculous overhead, in terms of performance, disk usage, and potentially buggy implementation complexity into my filesystem.
Like video games?
Last I checked, the number of female gamers was skyrocketing. It doesn't matter that the medium was (or even still is predominately) male. Bored housewives are surfing - check your spam. Those breast enhancement boobs (haha - it's a pun!) know something about their market.
Just because it's a predominately male medium doesn't mean that there isn't money to be made by innovating and deploying in that medium. In fact, the person who does it right and does it first will probably make the biggest impact.
Besides, the internet is good at being able to track niche markets, so even though though women are only 1/3 of the market it's still a potentially high yielding enterprise. And eventually the number of women online will increase, once they have something they want to see.
(Additional questions - where did you get your numbers? Are there stats for who spends more money online, which demographic has higher ad clickthrough rates, what kind of sites does each demographic tend to view, or in fact, any relevant statistic at all?)
Tell the truth, this could probably be successful. It's an extension of a traditional idea that has been moved to a medium which is actually superior for delivering that kind of content.
People already lap up blogs and celebrity websites, and watch webcams with frightening regularity, and soap fans already have a large stream of spolier mags and dedicated websites. Now that the dotcom boom has passed, it's more likely that someone will actually generate a decent way to generate money from the system rather than think "it's on the intarweb! It must be profitable".
The only real issue I see with this is there is real competition with actual weblogs and "legitimate" celebrity webpages, where the content is free and more "true to life".
I think you mean poplar. *snicker*
You know! Like the tree!
Apples grow on trees! It's a tree joke!
Anybody? Please? *sigh*
There goes my hope for ever having a +5 Funny post . . .philistines . . .
Well. To clarify I guess . . .
/. This could allow companies to upgrade at their own pace, rather than at Microsoft's, and allows public code review for security holes. This isn't just lusers, this is large corporate installs of NT gaining a signifigantly different and more flexible upgrade path.
Wine and ReactOS *are* sharing code and ideas. Wine is really a reimplementation of the Win32 API, and ReactOS is working with them both to improve the Wine DLLs as well as port those DLLs to the ReactOS kernel.
Wine does work with native Windows DLLs, and so will ReactOS (may now, not sure). As for how hard it is to emulate Windows, it's hard. The Windows runtime is a twist maze of libraries all alike, and it's not just source compat were after here, its binary compat.
And as for lusers and their software, the disadvantages of a closed system have been widely discussed here on
Courtesy.
Every P2P application since napster has started in the Windows system tray in order to increase the amount of stuff available at once. BT's design means that it can't work quite the same way - stuff is only shared while your downloading the thing, and rather than share a pool of files, you share individual files while your connected to a tracker.
It's not unusual (though thankfully not too usual) to be downloading via BT and all your seeders vanish or no current seeder has all parts of the file your after. Staying connected for an extra 5-10 minutes is a simple way to increase traffic, and is generally considered polite.
When we say "Open Sourcing" why do we really mean "GPL"? Granted, the GPL has the advantage from Sun's point of view, as they get any changes back.
But Perl was released for the longest time under the Artistic licence, which (IIRC) allows derivitive works, but doesn't allow you to call them Perl. This could keep the one, true source of Java unsullied by broken or incompatible implementations yet gives everybody else the hope that when Sun tanks Java won't.
In a word - yes.
Think about it this way - Groklaw has been respected for a while, after all, much more respected than Joe Slashdot poster.
Plus, they're putting they're money where their mouth is. Although a look at the numbers says that it might still be cost prohibitive to go with OSRM rather than pay $699 to SCO, but OSRM has some pretty powerful arguments on their side.
There was some talk of a drop in PCI card which had the old chips on it. This has since proven to be an unworkable solution, mostly because the whole OS 4/AmigaOne enterprise has got about as much cash as my 8 year old sister now that she's lost some teeth.
A more workable, and highly likely solutions, is the integration of AmigaForever into a point release of OS 4. I've heard some talk that this is in the works.
I won't get into the full history of the Amiga hardware platform, a clever frankenstein of processors. The old Amiga was a 68k platform primarily, the "new" Amiga runs on a PowerPC platform called the AmigaOne. For those who care, the OS was ported using the same technique that Apple used to port the MacOS from 68k to PPC, using a 68k emulator for as yet unported code.
Actually, I can find several references after a quick google search, but most of them seem bogus.
6 77 08350/p1/article.jhtml?term=
The most reputable paper I could find was this, which refers to testing possible side effects of the fluid when used on dogs. Could be full of horse shit.
http://www.findarticles.com/cf_dls/m0984/5_118/
My uncle is the head network admin over Coke's leagal department in Atlanta. His biggest amazement is the lawyers who say "But I love Gator!" They are numerous. The danger is not people who install Gator, never use it for anything, and never cry when the junk is removed. It's the people with slightly more grey matter who install it willingly and want it's features, and then become entrenched users.
Surprisingly, it's really the lawyers who are the biggest culprits over the secretaries and clerical staff. Most of those folks recognize that they are dealing with company property designed for business, whereas the lawyer gets a 2GHz laptop for company work and considers it hers. Then they jam a Cap'n Crunch CD packaged with their kids cereal, and boom they've got Gator (and sugar on the CD lazer).