The ability to run Windows quickly would be a big plus. Even though it's difficult to provide the Win32 APIs (as the Wine project do), it would be (relatively) easy to make VMWare run competitively on this system.
Personally I can't really see Intel producing PPC chips in the foreseeable future. Whilst it'd be nice if they did, the fact that x86(_64) is horribly ugly doesn't really hurt its performance these days (sky high transistor densities mean that the cost of handling the ugliness is relatively low). Another factor is that they'd like to see IA-64 competing effectively with POWER (even that is a long way off, assuming IA-64 doesn't die in the meantime).
AFAIK the XScale was an Intel-designed derivative of the StrongARM, which was in turn a DEC derivative one of the ARM chips. Complicated!
Relative to the StrongARM, the XScale has a few extra pipeline stages and some MMX instructions.
To make the matter even more ironic, Acorn actually wanted to license parts of the 286 core from Intel. When Intel refused, they had to design the ARM. Later on, Apple wanted to use it in the Newton and had a key influence in making it a low power mobile chip. Fastforward to the recent past and ARM has become the only company to license processor IP back to Intel:-)
Switching the Mac over now would be really weird: for years Apple struggled with the G4's performance - then I might have understood. Now they've got IBM as a partner - one of the world leaders in CPU architecture, silicon fabrication, etc. It would seem truly bizare to ditch out from PPC at this point, especially given IBM's huge commitment to PPC world domination (and their manifest triumphs over Intel in another volume market - games consoles).
Using an XScale, I could understand. Intel are *the* market leader in high end portable processors at the moment (try to find a powerful PDA that *doesn't* have an XScale). An XScale would be the sensible choice for an Apple PDA or, indeed, the iPod / Phone combo that has been so talked about.
This "leak" might about buying Intel might a be deliberate publicity stunt but I find it really hard to believe the Mac will move away from PPC in the foreseeable future.
The third possibility is that Apple will introduce something new - something else they've not mentioned before. An ultra Apple / Windows friendly UNIX server? An appliance computer (e.g. a cross between iPod and a {web,file,database}server?) A set top box (*cough* *pippin* *cough*)? Personally, I think Apple could be good with appliance computing.
To be fair, IBM were already making PPCs - the architecture was partly their baby and was based on their POWER architecture.
Bear in mind that it takes about 4-5 years to go from an intention to make a processor, through all the design stages, to production fabrication, so if Intel are making a PPC chip, they would have to have been planning it for a long time in very great secrecy.
Actually, it's not totally useless on non-x86.
First, on a point of pedantry, Windows NT apps on Alpha can run on Alpha Linux using it. (not sure about PPC and MIPS)
Secondly, if you run Wine under QEmu's usermode emulation, you can run x86 Wine on PPC, ARM, Sparc, S390, etc. This is basically adding a translation layer (but not a whole system emulator) to Wine.
Finally, there's the Darwine project, which hopes to run Wine under Darwin, leveraging QEmu-user to emulate Linux userspace on the Mac. The idea is that you'll be able to seamlessly run Windows apps under MacOS X - pretty neat!
User level threads aren't necessarily slow, it depends on how well they are implemented, how much support the underlying system gives and what you are trying to do...
User level threading packages can switch threads *very* cheaply, without going into the kernel at all. They are sometimes limited to only run on one CPU but this is an implementation issue.
Purely kernel-based threads (like Linux 2.6's model) have their own problems (eg. scalability with those more expensive thread context switches).
Linux is not completely a monolithic OS. You can choose whether you like to incorporate a driver in the kernel (faster, but more complex) or in userspace (slower, but the kernel remains slimmer).
Which seems to be saying that kernel modules run in userspace. This isn't correct: when a kernel module is loaded, it is linked into the kernel itself and then runs with full kernel privileges. Since it's running as part of the kernel there should be no performance difference, after the initial latency of loading the module.
How about using the extra power to optimise crypto, checksumming for software raid, etc? These should be useful on a large subset of servers (and existing vector extensions are already used for these tasks).
It'd be strange to see Apple switch *now*. In the days of the G4 when Motorola were having difficulty scaling up the CPU frequency it might have made sense: for the foreseeable future, x86 CPUs are going to be at least as fast as any others (at the same price point).
Nowadays, with CPUs coming straight from IBM, keeping up the speed seems like much less of a problem. IBM's CPU fabrication technology is within a few months of Intel's (Intel are probably still the market leader in fabrication technology but they are losing lead) and the Power architecture is pretty neat. Also, with Cell, etc, IBM clearly has plans for greater world domination.
It's worth remembering, as others have pointed out, that Intel is not just x86. There's also: * IA-64 (very unlikely Apple would use that!) * the IXP network processors (not inconceivable Apple would use those to accelerate network-intensive performance but relatively unlikely IMHO) * The XScale (which is an enhanced StrongARM)
I tend to agree with other posters that the XScale would be a good choice for either an enhanced iPod or a new Newton. ARM is the de facto standard in mobile CPUs these days.
A really neat trick to pull off if they do bring back the Newton is to support Pocket Windows apps using a Wine-like library. I imagine that an Apple-supplied set of apps would be more than adequate for most uses, though.
I'm glad someone's using the Xendomains init script - it's not something we usually get feedback on.
Xm is a pretty nice tool (way better than the previous generation of tools, which were a bit of a hack, although they worked OK). The control tools are likely to get rewritten again at least twice before they reach full maturity.
Which web interface do you use? The Xend one? Xensv is rather more pretty but, again, it's not something we've had much feedback about.
The no-benchmarking clause seems like it could be legally dodgy but it's not something we'd like to challenge ourselves! As you say, it's apparent from their virtualisation approach that they *have* to do more work at runtime than Xen and that must cost them somewhere.
Heh, glad you like it:-) Out of curiosity, I assume you're comparing to VMWare workstation? The reason I ask is that I thought VMWare's server admin packages were some of the most advanced you can buy?
VMWare server products also have better performance than the workstation ones (I'd imagine they're still not better than Xen but it's not possible to publish benchmarks comparing the two for legal reasons)
I guess the ZDnet guy spoke to the Novell guy over the phone and thought "Aha! Xen!" because it's been getting a lot of press lately... I guess ZenWorks was just not at the top of his mind!
Given your nickname, maybe you'll get quoted in a future article:-)
Good question! Having virtual machines does make server management easier in many ways. Even something as simple as the fact Xen virtual machines rebooting quicker than physical machines might be helpful here.
That said, I think the Novell dude probably meant "Zen". They should probably start calling it "ZenWorks" to avoid this confusion, since they also ship Xen in SuSE 9.3.
Just to clarify, the Xen "testing" branch is not a development branch. -testing is used to test fixes to -stable (moderately paranaid I know:-). It is typically released as a new stable revision (2.0.x) periodically. The bugs are mostly corner-case fixes for problems the majority of uses don't ever see.
The -unstable tree is where all the really fun stuff happens:-) Unstable gets frozen into a release tree about once every 6-12 months.
Actually, if you're using SuSE (i.e. from the Novell PoV) you actually do have it now - it ships with SuSE Professional 9.3. They've also tweaked YaST to do "Install in a directory for Xen", although this feature of YaST is fairly basic right now.
Xen's running on lots of production systems but it's yet to get deployed fully by any "big names". Most sophisticated machine & cluster management tools are absolutely essential for this.
Monolithic kernels are dominant in practice (so far). Windows started off microkernel-y but has ended up rather monolithic (at least partly for performance reasons). Xnu (Darwin / MacOS kernel) also has strong monolithic leanings, despite being based on Mach.
The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...
Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.
Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.
Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).
The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
In general, monolithic kernels run in a single address space and use direct procedure calls / variable accesses to pass data and control flow between subsystems. This is true even if they support loadable modules (like Linux). Any driver or other subsystem in your kernel can (if it wants) access any other part of the kernel.
Although Mach itself is a microkernel, the "xnu" kernel which Darwin / MacOS X uses also hosts other components *in the same address space*. Some of the subsystems (e.g. the BSD subsystem) are large and resemble monolithic systems themselves. The overall system is not a "pure" microkernel, with lots of code moved out of privileged mode. Equally, it's not quite like a traditional monolithic UNIX because of the use of Mach and the other Darwin-specific components (e.g. a (relatively?) stable binary interface for drivers).
Bear in mind we're talking about pre-university institutions here.
The learning curve for running alternative OSs is *plenty* steep for schools like this. Although they might save money buy deploying Linux, it will also cost them to train / hire to get expertise to run their systems. I wonder how that balances out... Some schools may just lack the capital to make the switch regardless of long term savings.
That said, the perpetually cash-strapped education sector is clearly a good market for Linux distributors to target more closely with solutions. Maybe there's scope for (yet) another distributor to appear, or scope for growth by an existing distributor.
One final thing: given the choice, I think schools should perhaps retain at least some MS products. Why? Schools educate the workforce, so it seems to serve the students and their future employers best if they are familiar with a wide range of the tools they might encounter.
Whilst SF is an amazing site and do provide an impressive range of services, they do have their faults. The site is down surprisingly often and the mailing lists frequently suffer from huge delivery delays and message reordering.
Don't get me wrong: what SF do is great and it's a non trivial task. But when we had sufficient resources, we moved over to our own systems where we had better control over such technical issues.
It's not just the addition of F95, which obviously only benefits Fortran users.
GCC4 has a new optimisation architecture called "Tree SSA". This introduces a new representation (well, actually two: GENERIC and GIMPLE, although the latter is a subset if the former) for programs under compilation. The GIMPLE representation is used for advanced high-level optimisations before feeding the code into the compiler "back end" for architecture-specific optimisation and code generation.
The advantages of Tree SSA are multiple: * cleaner architecture * allows high level optimisations that were previously hard or impossible to do at the RTL (Register Transfer Language) level used by the backends * despite being "high level" many optimisations that take advantage of program structure can be made language independent because of the GENERIC / GIMPLE representation
However, it'll take a while for new optimisations that have been enabled by this framework to be written. The idea is that Tree SSA breaks a fundamental barrier to the continued improvement of optimisation in GCC and should yield gains in years to come.
There are some other nifty things in GCC4 like the "mudflap" system for detecting program errors. Enhanced type-checking fussiness is also welcome as far as I'm concerned, even if it results in some compile errors.
[ disclaimer: this is speculation but it's informed speculation - hopefully useful ]
It's worth bearing in mind this is unlikely to be an OS in the common sense. I'd rate it very unlikely that this OS supports such niceties as filesystems, network IO stacks, protected processes, etc - or that it ever will.
Rather, it's likely to be a shim (albeit a clever one) for insulating the developers of embedded-style applications from the real hardware. I wouldn't be surprised if this Toshiba OS is actually a "library operating system" which is linked into the application itself.
Don't think of it as an OS in the Linux sense, more as a toolkit / library for Cell programmers. Exactly how a "conventional" OS will run on the Cell is not clear to me but it seems certain that it can support a Linux-style OS well - otherwise it'd scupper Cell's World Domination plans;-)
It's not perfect. It's slower than Gecko and it's not able to correctly render so many pages.
OTOH, it loads faster than Gecko and the codebase is (allegedly) cleaner.
I use Konqueror for the integration with the rest of my environment but it would be nice to have Gecko available. In the KDE 2 era, at least Konqueror used to be able to embed a Gecko engine but that still used GTK so integration wasn't perfect. The Firefox port now in progress is a proper KDE-native version - much nicer!
Slashdot Mirror
Ack for most things the kernel does. Things like software RAID, IPSec, etc. would probably benefit from this, however.
The ability to run Windows quickly would be a big plus. Even though it's difficult to provide the Win32 APIs (as the Wine project do), it would be (relatively) easy to make VMWare run competitively on this system.
Personally I can't really see Intel producing PPC chips in the foreseeable future. Whilst it'd be nice if they did, the fact that x86(_64) is horribly ugly doesn't really hurt its performance these days (sky high transistor densities mean that the cost of handling the ugliness is relatively low). Another factor is that they'd like to see IA-64 competing effectively with POWER (even that is a long way off, assuming IA-64 doesn't die in the meantime).
AFAIK the XScale was an Intel-designed derivative of the StrongARM, which was in turn a DEC derivative one of the ARM chips. Complicated!
:-)
Relative to the StrongARM, the XScale has a few extra pipeline stages and some MMX instructions.
To make the matter even more ironic, Acorn actually wanted to license parts of the 286 core from Intel. When Intel refused, they had to design the ARM. Later on, Apple wanted to use it in the Newton and had a key influence in making it a low power mobile chip. Fastforward to the recent past and ARM has become the only company to license processor IP back to Intel
Switching the Mac over now would be really weird: for years Apple struggled with the G4's performance - then I might have understood. Now they've got IBM as a partner - one of the world leaders in CPU architecture, silicon fabrication, etc. It would seem truly bizare to ditch out from PPC at this point, especially given IBM's huge commitment to PPC world domination (and their manifest triumphs over Intel in another volume market - games consoles).
Using an XScale, I could understand. Intel are *the* market leader in high end portable processors at the moment (try to find a powerful PDA that *doesn't* have an XScale). An XScale would be the sensible choice for an Apple PDA or, indeed, the iPod / Phone combo that has been so talked about.
This "leak" might about buying Intel might a be deliberate publicity stunt but I find it really hard to believe the Mac will move away from PPC in the foreseeable future.
The third possibility is that Apple will introduce something new - something else they've not mentioned before. An ultra Apple / Windows friendly UNIX server? An appliance computer (e.g. a cross between iPod and a {web,file,database}server?) A set top box (*cough* *pippin* *cough*)? Personally, I think Apple could be good with appliance computing.
To be fair, IBM were already making PPCs - the architecture was partly their baby and was based on their POWER architecture. Bear in mind that it takes about 4-5 years to go from an intention to make a processor, through all the design stages, to production fabrication, so if Intel are making a PPC chip, they would have to have been planning it for a long time in very great secrecy.
Actually, it's not totally useless on non-x86. First, on a point of pedantry, Windows NT apps on Alpha can run on Alpha Linux using it. (not sure about PPC and MIPS) Secondly, if you run Wine under QEmu's usermode emulation, you can run x86 Wine on PPC, ARM, Sparc, S390, etc. This is basically adding a translation layer (but not a whole system emulator) to Wine. Finally, there's the Darwine project, which hopes to run Wine under Darwin, leveraging QEmu-user to emulate Linux userspace on the Mac. The idea is that you'll be able to seamlessly run Windows apps under MacOS X - pretty neat!
User level threads aren't necessarily slow, it depends on how well they are implemented, how much support the underlying system gives and what you are trying to do... User level threading packages can switch threads *very* cheaply, without going into the kernel at all. They are sometimes limited to only run on one CPU but this is an implementation issue. Purely kernel-based threads (like Linux 2.6's model) have their own problems (eg. scalability with those more expensive thread context switches).
How about using the extra power to optimise crypto, checksumming for software raid, etc? These should be useful on a large subset of servers (and existing vector extensions are already used for these tasks).
> Mind the jaguar
I guess that means Macs are everywhere too. Albeit old ones. I guess it takes a while for them to get the latest release in the jungle...
It'd be strange to see Apple switch *now*. In the days of the G4 when Motorola were having difficulty scaling up the CPU frequency it might have made sense: for the foreseeable future, x86 CPUs are going to be at least as fast as any others (at the same price point).
Nowadays, with CPUs coming straight from IBM, keeping up the speed seems like much less of a problem. IBM's CPU fabrication technology is within a few months of Intel's (Intel are probably still the market leader in fabrication technology but they are losing lead) and the Power architecture is pretty neat. Also, with Cell, etc, IBM clearly has plans for greater world domination.
It's worth remembering, as others have pointed out, that Intel is not just x86. There's also:
* IA-64 (very unlikely Apple would use that!)
* the IXP network processors (not inconceivable Apple would use those to accelerate network-intensive performance but relatively unlikely IMHO)
* The XScale (which is an enhanced StrongARM)
I tend to agree with other posters that the XScale would be a good choice for either an enhanced iPod or a new Newton. ARM is the de facto standard in mobile CPUs these days.
A really neat trick to pull off if they do bring back the Newton is to support Pocket Windows apps using a Wine-like library. I imagine that an Apple-supplied set of apps would be more than adequate for most uses, though.
I'm glad someone's using the Xendomains init script - it's not something we usually get feedback on.
Xm is a pretty nice tool (way better than the previous generation of tools, which were a bit of a hack, although they worked OK). The control tools are likely to get rewritten again at least twice before they reach full maturity.
Which web interface do you use? The Xend one? Xensv is rather more pretty but, again, it's not something we've had much feedback about.
The no-benchmarking clause seems like it could be legally dodgy but it's not something we'd like to challenge ourselves! As you say, it's apparent from their virtualisation approach that they *have* to do more work at runtime than Xen and that must cost them somewhere.
Heh, glad you like it :-) Out of curiosity, I assume you're comparing to VMWare workstation? The reason I ask is that I thought VMWare's server admin packages were some of the most advanced you can buy?
VMWare server products also have better performance than the workstation ones (I'd imagine they're still not better than Xen but it's not possible to publish benchmarks comparing the two for legal reasons)
I guess the ZDnet guy spoke to the Novell guy over the phone and thought "Aha! Xen!" because it's been getting a lot of press lately... I guess ZenWorks was just not at the top of his mind!
:-)
Given your nickname, maybe you'll get quoted in a future article
Good question! Having virtual machines does make server management easier in many ways. Even something as simple as the fact Xen virtual machines rebooting quicker than physical machines might be helpful here.
That said, I think the Novell dude probably meant "Zen". They should probably start calling it "ZenWorks" to avoid this confusion, since they also ship Xen in SuSE 9.3.
> the testing branch has been remarkably stable
:-). It is typically released as a new stable revision (2.0.x) periodically. The bugs are mostly corner-case fixes for problems the majority of uses don't ever see.
:-) Unstable gets frozen into a release tree about once every 6-12 months.
Just to clarify, the Xen "testing" branch is not a development branch. -testing is used to test fixes to -stable (moderately paranaid I know
The -unstable tree is where all the really fun stuff happens
Actually, if you're using SuSE (i.e. from the Novell PoV) you actually do have it now - it ships with SuSE Professional 9.3. They've also tweaked YaST to do "Install in a directory for Xen", although this feature of YaST is fairly basic right now. Xen's running on lots of production systems but it's yet to get deployed fully by any "big names". Most sophisticated machine & cluster management tools are absolutely essential for this.
Monolithic kernels are dominant in practice (so far). Windows started off microkernel-y but has ended up rather monolithic (at least partly for performance reasons). Xnu (Darwin / MacOS kernel) also has strong monolithic leanings, despite being based on Mach.
The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...
Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.
Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.
Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).
The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
That's a statement not a criticism by the way ;-)
In general, monolithic kernels run in a single address space and use direct procedure calls / variable accesses to pass data and control flow between subsystems. This is true even if they support loadable modules (like Linux). Any driver or other subsystem in your kernel can (if it wants) access any other part of the kernel.
Although Mach itself is a microkernel, the "xnu" kernel which Darwin / MacOS X uses also hosts other components *in the same address space*. Some of the subsystems (e.g. the BSD subsystem) are large and resemble monolithic systems themselves. The overall system is not a "pure" microkernel, with lots of code moved out of privileged mode. Equally, it's not quite like a traditional monolithic UNIX because of the use of Mach and the other Darwin-specific components (e.g. a (relatively?) stable binary interface for drivers).
Bear in mind we're talking about pre-university institutions here. The learning curve for running alternative OSs is *plenty* steep for schools like this. Although they might save money buy deploying Linux, it will also cost them to train / hire to get expertise to run their systems. I wonder how that balances out... Some schools may just lack the capital to make the switch regardless of long term savings. That said, the perpetually cash-strapped education sector is clearly a good market for Linux distributors to target more closely with solutions. Maybe there's scope for (yet) another distributor to appear, or scope for growth by an existing distributor. One final thing: given the choice, I think schools should perhaps retain at least some MS products. Why? Schools educate the workforce, so it seems to serve the students and their future employers best if they are familiar with a wide range of the tools they might encounter.
Whilst SF is an amazing site and do provide an impressive range of services, they do have their faults. The site is down surprisingly often and the mailing lists frequently suffer from huge delivery delays and message reordering.
Don't get me wrong: what SF do is great and it's a non trivial task. But when we had sufficient resources, we moved over to our own systems where we had better control over such technical issues.
It's not just the addition of F95, which obviously only benefits Fortran users.
GCC4 has a new optimisation architecture called "Tree SSA". This introduces a new representation (well, actually two: GENERIC and GIMPLE, although the latter is a subset if the former) for programs under compilation. The GIMPLE representation is used for advanced high-level optimisations before feeding the code into the compiler "back end" for architecture-specific optimisation and code generation.
The advantages of Tree SSA are multiple:
* cleaner architecture
* allows high level optimisations that were previously hard or impossible to do at the RTL (Register Transfer Language) level used by the backends
* despite being "high level" many optimisations that take advantage of program structure can be made language independent because of the GENERIC / GIMPLE representation
However, it'll take a while for new optimisations that have been enabled by this framework to be written. The idea is that Tree SSA breaks a fundamental barrier to the continued improvement of optimisation in GCC and should yield gains in years to come.
There are some other nifty things in GCC4 like the "mudflap" system for detecting program errors. Enhanced type-checking fussiness is also welcome as far as I'm concerned, even if it results in some compile errors.
[ disclaimer: this is speculation but it's informed speculation - hopefully useful ]
;-)
It's worth bearing in mind this is unlikely to be an OS in the common sense. I'd rate it very unlikely that this OS supports such niceties as filesystems, network IO stacks, protected processes, etc - or that it ever will.
Rather, it's likely to be a shim (albeit a clever one) for insulating the developers of embedded-style applications from the real hardware. I wouldn't be surprised if this Toshiba OS is actually a "library operating system" which is linked into the application itself.
Don't think of it as an OS in the Linux sense, more as a toolkit / library for Cell programmers. Exactly how a "conventional" OS will run on the Cell is not clear to me but it seems certain that it can support a Linux-style OS well - otherwise it'd scupper Cell's World Domination plans
It's not perfect. It's slower than Gecko and it's not able to correctly render so many pages.
OTOH, it loads faster than Gecko and the codebase is (allegedly) cleaner.
I use Konqueror for the integration with the rest of my environment but it would be nice to have Gecko available. In the KDE 2 era, at least Konqueror used to be able to embed a Gecko engine but that still used GTK so integration wasn't perfect. The Firefox port now in progress is a proper KDE-native version - much nicer!
> could we soon start seeing websites asking their users to download Firefox to get the best browsing experience?
:-(
:-)
Please noooooo! I use Konqueror for all my web browsing. It works for about 95% of the sites I want to visit - I don't want that number to go down
I think Konqueror supports SVG but I don't suppose it supports embedding it directly in XHTML.
OTOH, when the KDE port of Firefox is done (yes, there is one!) then I won't mind so much