Call it VR4, so you sound cool and hip and absolutely clueless. Why not call Linux LX, while you're at it? And change the picture (or face), whichever comes easiest. You _do_ happen to look like you could use a thorough thrashing with a cluestick, you idiot. Please stop discussing this troll of an article - it just encourages the asshats.
Well well, never expected to see _this_ sort of thing rear its ugly head again, at least on the desktop. To clarify, when buying N * SCO seats, you limit yourself to that number of sessions: your total of telnets, ftps, xdm logins and rsh sessions is N. Of course, this was circumvented by installing free versions of telnetd etc., which enabled our users to login however many times they wanted. Expect the same to happen with XP's Castrati Edition as well.
Get Pokemon Puzzle Challenge for the GameBoy - Crack Attack is a poor ripoff of this game. Puzzle Challenge does a good job of ramping up the difficulty, not just randomly throwing blocks at you.
I don't really understand what you are saying. Please explain how NGPT will make use of NPTL's architecture. I admit that I am really not familiar with the latter's internals - how is NPTL different from the current threading model, and how can NGPT make use of that?
Well, they might not have a patent (or copyright) on SysV-style init, but it is certainly an example of the things they will be pointing to. Consider IBM's Linux next-generation POSIX threads. One of the areas where there was much sharing between IBM and SCO during Project Monterey was LWP scalability (although AFAIK more technology was going in the IBM=>SCO direction on that one); would NGPT not be a potential smoking gun in SCO's opinion? Sure, every commercial SysV (or SysV-compliant) Unix on the market uses the LWP model, but the vendors selling those systems are already _paying_ licensees. By using SysV-derived "knowledge" (if not outright code segments) in enhancing a GPL'ed system , IBM is (at least seemingly) violating its license. A counter-example would be FreeBSD's Scheduler Activations (which is how Solaris's LWPs are implemented, and probably others). However, in FreeBSD's case they avoid using Solaris terminology etc., which make their case for being cleanroom, stronger.
Switching between user and kernel mode takes time. If all your primitive operations are implemented in user mode, synchronisation (for instance) takes several cycles in the best case (resource is free, lock it), and a bit over a hundred in the worst (resource is busy, context switch). When you also add the user/kernel mode transition (which may be a couple dozen cycles on some RISCs but takes more than a hundred on some x86 architectures), you can see how performance may degrade.
People have been writing multithreaded Unix apps for a very very long time (DCE and UI threads have been around for more than a decade, not to count "non-standardised" thread packages). The fact that many applications have been written with the multi-PROCESS model in mind (which is natural for Unix), has nothing to do with this.
File I/O, you mean. RTOS's are at least as good at direct device I/O as other types of OS.
> RTOSes are slow, because they trade off speed for determinism. This is in general _wrong_. Please explain, for instance, how context switching would be slower on a RTOS (compared to Unix, for instance), when it in general keeps less context info, and usually does not even need user/kernel mode transitions. If you want to make a real comparison, take a Unix/Linux system, disable all swap and restrict the buffer cache to a small percentage of your RAM. Then compare it to QNX or VxWorks (or, to get a better picture, LynxOS). QNX is "slower" at doing desktop/server stuff, because it was not designed to do these things. Which is why swapping is clunky and file access is slow.
SunOS=>SVR 4: Proper virtual memory. Vnodes. LWPs. Fine-grained, adaptive kernel locks. POSIX compliance. The list is very very very long. People forget that, vanilla as Solaris may seem, Sun was probably the biggest contributor to Unix "state of the art" (except for SGI and Sequent's work on integrating CC/NUMA into a Unix system). Linux is just barely starting to scratch the surface of where Sun was 5-7 years ago, as far as kernel and userspace libs are concerned.
is concerned. Linux's _kernel_ is years behind Solaris and AIX in scalability. What the benchmark shows is that if you had an application where many processes access memory concurrently (not using OS services), the SGI machine may be a good choice. As far as a memory bandwidth benchmark is concerned, you could have any multiprocessor OS on that and get the same performance, even with Big Kernel Lock architectures. So it seems to me that using Linux was just a way to bootstrap the machine cheaply (yes, I know SGI had invested a lot in Linux (however superior IRIX may be), and this is probably where it's paying off). Good way to get the geeks closer to management excited:)
Well, I think that NetHack will suit you just fine. Once you look past the character-based display (graphic tiles are available both for NetHack and variants like SlashEm), you'll find one of the best RPG's ever. Every time you start a game it's different (excellent randomly-generated dungeon), plenty of character classes and techniques to choose from. Check out www.nethack.org, www.nethack.de and the newsgroup rec.games.roguelike.nethack.
You can - just get a copy of Xenix. At least the old versions (pre-386) were nearly straight ports of V7. I think Xenix/386 is at most System III.
The Register's vultures wrong again.
on
No Solaris 9 for x86
·
· Score: 5, Insightful
UnixWare (now OpenUnix) is still in very active development. Check out the Caldera site.
It's only the best environment to run Linux apps on a multiprocessor, so I see why The Register would ignore it:)
> And as for hardware sales...you do know that the console makers lose money on hardware sales, right?
This is no longer true - the only console maker losing money on hardware sales is M$ - PS2 and GameCube are cheaper to make than sell. Sony practically manufactures the whole machine, and the GameCube is made of such cheap parts that it's still making a profit at $199.
Check out http://www.actsofgord.com/Proclamations/chapter02. html
is an example of nothing. It's just another Linux port. Good for enthusiasts (i'll be getting one if the PAL kit ever comes out), but not much more. I don't believe that many future PS2 games will be using Linux as their basis - there's a native RT OS for that, which is much more suitable.
A good example would be modifications to the protocol stack, for implementing a proprietary protocol or algorithm. This makes the kernel modifications part of the application.
Remember that this is an _embedded_ system, which is usually _not_ the same as taking a desktop OS and slapping some user-space application on it.
Frankly, as an embedded developer, I do not see the great value of using Linux over *BSD in embedded space (unless you use some hardware that no BSD supports); the license alone is an enormous turn-off for any company that needs to modify the kernel (see above) and does not want its competitors to get a glimpse into its code. And in any case, if you need true real-time, you'd be MUCH better off with LynxOS or somesuch rather than some half-baked Linux-RTOS microkernel solution; you'd be getting better POSIX compliance, and TRUE REAL TIME, from an experienced company.
And as far as real-time is concerned, Solaris and IRIX have had true realtime capabilities (for userspace processes too) for years. Linux is still a toy OS compared to commercial offerings in embedded (and, dare I say it, server) space.
I used to work for a SCO support branch. SCO Unix or OpenServer is what the majority of our customers were running.
It was not uncommon for customers to kill their support contracts because the systems ran for years and years without crashes or reboots, even on plain vanilla PC clones. One relatively extreme example: one day a customer brought in an 8 year old box which had been running Xenix386 since it was purchased. The machine was running custom software for controlling sprinklers in several large greenhouses, as well as accounting and inventory programs, with several VT100's attached. The reason he'd brought it in was that the HD had crashed. The amount of dust in the box was absolutely amazing:)
Consider that the machine hadn't crashed since it was purchased, and was rebooted only due to UPS problems. The whole livelihood of this guy was tied up in its reliability.
I think this is another testament to the reliability of Unix, even an ancient system like Xenix386 (which is an almost pure v7 derived system).
I have been working with VxWorks for the past year.
You pay through the nose to get any tiny little bit of functionality beyond the barest essentials, the development envorionment sucks (constant crashes, horrible IDE performance), the OS claims to be POSIX compliant but isn't, and support is absolutely TERRIBLE. They have blown us off several times when we needed problems solved and questions answered.
The three reasons for using VxWorks today are:
1) Hard real time. And if you can stand latency of a couple hundred ns, Solaris 8 or IRIX can fulfill your needs.
2) Experienced workforce. In the embedded arena, there are many experienced VxWorks developers. If your team is composed of such people, VxWorks may become a good choice when you need your product out the door in a hurry.
3) Availability of various software components and drivers. Many vendors create drivers and modules (e.g. net protocols) for VxWorks first and often exclusively. The quality of these products is often mediocre, however one still pays through the nose for them as there is no other solution.
WRS' monopoly may have been fraying at the edges (embedded Linux offerings and others such as QNX are beginning to show a following), however, the technological advantage these competitors are displaying may be erased by this move (the BSDi acquisition). At long last, WRS will have a Real Operating System which will show all those haughty bastards with their Protected and Virtual Memory, POSIX compliance and OSS tools who's the boss.
I'd be absolutely thrilled to work with BSD instead of VxWorks (FreeBSD is my workstation OS of choice), but I fear this may well seal the fate of other companies such as QSSL and Be, which are true innovators and do not have the financial clout to push their competitors out by buying them (or equivalent solutions) out.
Such changes as would necessitate a fork (e.g. Big Iron) are much more pervasive than just a driver/filesystem/workaround module load, or recompile. For example, kernel threads and locks will probably have to be added on many levels to keep concurrency levels high. The main reason that systems such as Solaris and Unixware display markedly lower performance on a uniprocessor than a simpler system such as Linux, but (near) linear scalability on multiprocessor systems (up to dozens of processors) is that they contain more abstraction layers and synchronization points. Enabling Linux to support massive multiprocessors/CCNUMA/Supercomputers while keeping performance high on simpler hardware will necessitate huge reams of code to be put under #ifdefs, which will render the code extremely hard to maintain reliably.
The result is that a kernel fork will probably be inevitable. I think the most productive direction for Linux on Big Iron will be by emulation/compatibility layers over OS's tailored to such high-end hardware. For example, UnixWare's Linux Kernel Personality. By running Linux applications on a kernel which is easily capable of scaling to dozens or hundreds of processors and many GB of memory, we get the best of both worlds: high performance, massive choice of applications, and Linux system behaviour. Once a compatibility layer is in place, all that remains is to arrange the Linux (sub)system management utilities to behave in a consistent manner, hence what will be needed is a Linux _distro_ tailored by the Big-Iron vendor who is pushing Linux on their boxen.
There is no reason to stick to a top-to-bottom "Linux Universe". Let the big boys do what they do best (big, expensive hardware and kernel tailored to that hardware); there is no need to replicate their work. Many sacrifices will have to be made (e.g. low-end performance and kernel code maintainability) if the Linux kernel goes the one-system-for-all way.
This sure seems like another big nail in the coffin of Nuon - or is it? Anyone have the scoop on these guys?
Welcome to Solaris/SVR4. Necessary? I wonder.
on
Java 2 For BSD
·
· Score: 1
Very good. Now we'll have FreeBSD starting up along the road Solaris (SVR4MP in some ways too) started on about 7 years ago. FreeBSD is an excellent system, and usually beats (performance-wise) any other Unix on a uniprocessor x86 in my experience. Scalability over more than 2 CPUs, however, is a question. Commercial Unixes have excellent scalability over dozens of CPUs; are we sure we really need this sort of performance for *BSD? Multithreading, however, is certainly becoming an important issue, and kernel scheduling of user thread groups (a la multiplexing over LWPs) is becoming something of a need. Are you sure that some sort of workaround cannot be done? Maybe add a signal to trigger rescheduling user threads, or enable the pthreads library to work over several rfork()ed processes? If it were possible to make rfork()ed processes multiplexed signal-wise over one PID, we could have something resembling LWP's.
Slashdot Mirror
That's FreeBSD, bubba. And NeXT started off on 68K, not x86 - they got to x86 late in their lifecycle.
Call it VR4, so you sound cool and hip and absolutely clueless. Why not call Linux LX, while you're at it? And change the picture (or face), whichever comes easiest. You _do_ happen to look like you could use a thorough thrashing with a cluestick, you idiot.
Please stop discussing this troll of an article - it just encourages the asshats.
Well well, never expected to see _this_ sort of thing rear its ugly head again, at least on the desktop. To clarify, when buying N * SCO seats, you limit yourself to that number of sessions: your total of telnets, ftps, xdm logins and rsh sessions is N.
Of course, this was circumvented by installing free versions of telnetd etc., which enabled our users to login however many times they wanted. Expect the same to happen with XP's Castrati Edition as well.
Get Pokemon Puzzle Challenge for the GameBoy - Crack Attack is a poor ripoff of this game. Puzzle Challenge does a good job of ramping up the difficulty, not just randomly throwing blocks at you.
I don't really understand what you are saying.
Please explain how NGPT will make use of NPTL's architecture. I admit that I am really not familiar with the latter's internals - how is NPTL different from the current threading model, and how can NGPT make use of that?
Well, they might not have a patent (or copyright) on SysV-style init, but it is certainly an example of the things they will be pointing to.
Consider IBM's Linux next-generation POSIX threads. One of the areas where there was much sharing between IBM and SCO during Project Monterey was LWP scalability (although AFAIK more technology was going in the IBM=>SCO direction on that one); would NGPT not be a potential smoking gun in SCO's opinion? Sure, every commercial SysV (or SysV-compliant) Unix on the market uses the LWP model, but the vendors selling those systems are already _paying_ licensees. By using SysV-derived "knowledge" (if not outright code segments) in enhancing a GPL'ed system , IBM is (at least seemingly) violating its license.
A counter-example would be FreeBSD's Scheduler Activations (which is how Solaris's LWPs are implemented, and probably others). However, in FreeBSD's case they avoid using Solaris terminology etc., which make their case for being cleanroom, stronger.
http://www.somethingawful.com/download.php?file=mo vies/sa/desktop-commander.wmv
Switching between user and kernel mode takes time. If all your primitive operations are implemented in user mode, synchronisation (for instance) takes several cycles in the best case (resource is free, lock it), and a bit over a hundred in the worst (resource is busy, context switch). When you also add the user/kernel mode transition (which may be a couple dozen cycles on some RISCs but takes more than a hundred on some x86 architectures), you can see how performance may degrade.
People have been writing multithreaded Unix apps for a very very long time (DCE and UI threads have been around for more than a decade, not to count "non-standardised" thread packages). The fact that many applications have been written with the multi-PROCESS model in mind (which is natural for Unix), has nothing to do with this.
File I/O, you mean.
RTOS's are at least as good at direct device I/O as other types of OS.
> RTOSes are slow, because they trade off speed for determinism.
This is in general _wrong_. Please explain, for instance, how context switching would be slower on a RTOS (compared to Unix, for instance), when it in general keeps less context info, and usually does not even need user/kernel mode transitions. If you want to make a real comparison, take a Unix/Linux system, disable all swap and restrict the buffer cache to a small percentage of your RAM. Then compare it to QNX or VxWorks (or, to get a better picture, LynxOS).
QNX is "slower" at doing desktop/server stuff, because it was not designed to do these things. Which is why swapping is clunky and file access is slow.
SunOS=>SVR 4:
Proper virtual memory.
Vnodes.
LWPs.
Fine-grained, adaptive kernel locks.
POSIX compliance.
The list is very very very long. People forget that, vanilla as Solaris may seem, Sun was probably the biggest contributor to Unix "state of the art" (except for SGI and Sequent's work on integrating CC/NUMA into a Unix system). Linux is just barely starting to scratch the surface of where Sun was 5-7 years ago, as far as kernel and userspace libs are concerned.
is concerned. :)
Linux's _kernel_ is years behind Solaris and AIX in scalability. What the benchmark shows is that if you had an application where many processes access memory concurrently (not using OS services), the SGI machine may be a good choice. As far as a memory bandwidth benchmark is concerned, you could have any multiprocessor OS on that and get the same performance, even with Big Kernel Lock architectures.
So it seems to me that using Linux was just a way to bootstrap the machine cheaply (yes, I know SGI had invested a lot in Linux (however superior IRIX may be), and this is probably where it's paying off). Good way to get the geeks closer to management excited
Well, I think that NetHack will suit you just fine. Once you look past the character-based display (graphic tiles are available both for NetHack and variants like SlashEm), you'll find one of the best RPG's ever. Every time you start a game it's different (excellent randomly-generated dungeon), plenty of character classes and techniques to choose from.
Check out www.nethack.org, www.nethack.de and the newsgroup rec.games.roguelike.nethack.
You can - just get a copy of Xenix. At least the old versions (pre-386) were nearly straight ports of V7. I think Xenix/386 is at most System III.
UnixWare (now OpenUnix) is still in very active development. Check out the Caldera site. :)
It's only the best environment to run Linux apps on a multiprocessor, so I see why The Register would ignore it
> And as for hardware sales...you do know that the console makers lose money on hardware sales, right?. html
This is no longer true - the only console maker losing money on hardware sales is M$ - PS2 and GameCube are cheaper to make than sell. Sony practically manufactures the whole machine, and the GameCube is made of such cheap parts that it's still making a profit at $199.
Check out http://www.actsofgord.com/Proclamations/chapter02
is an example of nothing. It's just another Linux port. Good for enthusiasts (i'll be getting one if the PAL kit ever comes out), but not much more. I don't believe that many future PS2 games will be using Linux as their basis - there's a native RT OS for that, which is much more suitable.
A good example would be modifications to the protocol stack, for implementing a proprietary protocol or algorithm. This makes the kernel modifications part of the application.
Remember that this is an _embedded_ system, which is usually _not_ the same as taking a desktop OS and slapping some user-space application on it.
Frankly, as an embedded developer, I do not see the great value of using Linux over *BSD in embedded space (unless you use some hardware that no BSD supports); the license alone is an enormous turn-off for any company that needs to modify the kernel (see above) and does not want its competitors to get a glimpse into its code. And in any case, if you need true real-time, you'd be MUCH better off with LynxOS or somesuch rather than some half-baked Linux-RTOS microkernel solution; you'd be getting better POSIX compliance, and TRUE REAL TIME, from an experienced company.
And as far as real-time is concerned, Solaris and IRIX have had true realtime capabilities (for userspace processes too) for years. Linux is still a toy OS compared to commercial offerings in embedded (and, dare I say it, server) space.
I used to work for a SCO support branch. SCO Unix or OpenServer is what the majority of our customers were running. :)
It was not uncommon for customers to kill their support contracts because the systems ran for years and years without crashes or reboots, even on plain vanilla PC clones. One relatively extreme example: one day a customer brought in an 8 year old box which had been running Xenix386 since it was purchased. The machine was running custom software for controlling sprinklers in several large greenhouses, as well as accounting and inventory programs, with several VT100's attached. The reason he'd brought it in was that the HD had crashed. The amount of dust in the box was absolutely amazing
Consider that the machine hadn't crashed since it was purchased, and was rebooted only due to UPS problems. The whole livelihood of this guy was tied up in its reliability.
I think this is another testament to the reliability of Unix, even an ancient system like Xenix386 (which is an almost pure v7 derived system).
I have been working with VxWorks for the past year.
You pay through the nose to get any tiny little bit of functionality beyond the barest essentials, the development envorionment sucks (constant crashes, horrible IDE performance), the OS claims to be POSIX compliant but isn't, and support is absolutely TERRIBLE. They have blown us off several times when we needed problems solved and questions answered.
The three reasons for using VxWorks today are:
1) Hard real time. And if you can stand latency of a couple hundred ns, Solaris 8 or IRIX can fulfill your needs.
2) Experienced workforce. In the embedded arena, there are many experienced VxWorks developers. If your team is composed of such people, VxWorks may become a good choice when you need your product out the door in a hurry.
3) Availability of various software components and drivers. Many vendors create drivers and modules (e.g. net protocols) for VxWorks first and often exclusively. The quality of these products is often mediocre, however one still pays through the nose for them as there is no other solution.
WRS' monopoly may have been fraying at the edges (embedded Linux offerings and others such as QNX are beginning to show a following), however, the technological advantage these competitors are displaying may be erased by this move (the BSDi acquisition). At long last, WRS will have a Real Operating System which will show all those haughty bastards with their Protected and Virtual Memory, POSIX compliance and OSS tools who's the boss.
I'd be absolutely thrilled to work with BSD instead of VxWorks (FreeBSD is my workstation OS of choice), but I fear this may well seal the fate of other companies such as QSSL and Be, which are true innovators and do not have the financial clout to push their competitors out by buying them (or equivalent solutions) out.
I'd suggest you first see how high-level concepts are handled. Try papers from the UW Cecil/Vortex project:c il/www/Papers/papers.html
c il/www/Papers/whole-program.html
http://www.cs.washington.edu/research/projects/ce
And maybe start from:
http://www.cs.washington.edu/research/projects/ce
Such changes as would necessitate a fork (e.g. Big Iron) are much more pervasive than just a driver/filesystem/workaround module load, or recompile. For example, kernel threads and locks will probably have to be added on many levels to keep concurrency levels high. The main reason that systems such as Solaris and Unixware display markedly lower performance on a uniprocessor than a simpler system such as Linux, but (near) linear scalability on multiprocessor systems (up to dozens of processors) is that they contain more abstraction layers and synchronization points. Enabling Linux to support massive multiprocessors/CCNUMA/Supercomputers while keeping performance high on simpler hardware will necessitate huge reams of code to be put under #ifdefs, which will render the code extremely hard to maintain reliably.
The result is that a kernel fork will probably be inevitable. I think the most productive direction for Linux on Big Iron will be by emulation/compatibility layers over OS's tailored to such high-end hardware. For example, UnixWare's Linux Kernel Personality. By running Linux applications on a kernel which is easily capable of scaling to dozens or hundreds of processors and many GB of memory, we get the best of both worlds: high performance, massive choice of applications, and Linux system behaviour. Once a compatibility layer is in place, all that remains is to arrange the Linux (sub)system management utilities to behave in a consistent manner, hence what will be needed is a Linux _distro_ tailored by the Big-Iron vendor who is pushing Linux on their boxen.
There is no reason to stick to a top-to-bottom "Linux Universe". Let the big boys do what they do best (big, expensive hardware and kernel tailored to that hardware); there is no need to replicate their work. Many sacrifices will have to be made (e.g. low-end performance and kernel code maintainability) if the Linux kernel goes the one-system-for-all way.
Do you lip-synch?
This sure seems like another big nail in the coffin of Nuon - or is it? Anyone have the scoop on these guys?
Very good. Now we'll have FreeBSD starting up along the road Solaris (SVR4MP in some ways too) started on about 7 years ago.
FreeBSD is an excellent system, and usually beats (performance-wise) any other Unix on a uniprocessor x86 in my experience. Scalability over more than 2 CPUs, however, is a question. Commercial Unixes have excellent scalability over dozens of CPUs; are we sure we really need this sort of performance for *BSD?
Multithreading, however, is certainly becoming an important issue, and kernel scheduling of user thread groups (a la multiplexing over LWPs) is becoming something of a need. Are you sure that some sort of workaround cannot be done? Maybe add a signal to trigger rescheduling user threads, or enable the pthreads library to work over several rfork()ed processes? If it were possible to make rfork()ed processes multiplexed signal-wise over one PID, we could have something resembling LWP's.