Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
However, it probably looks enough like actual Unix systems that one could ask whether it violates the "Unix philosophy"(TM) or not; given that its userland is GNU, Doug McIlroy might argue that it's been fed enough goodies to bring it to a disheartening state of obesity (joining Linux, for much the same reason, and, I suspect, most other Un*xes these days in McIlroy's opinion). On the other hand, the usual flavors of pipeline continue to work on it, Linux, and those other Un*xes, the obesity notwithstanding, which is good enough for me.
OSX uses a microkernel. Besides, there are/were plenty of Unix that used microkernels: OSF/1, Digital Unix/Tru64, etc.
The point is moot any way, most of you aspies don't understand the debate is moot because Linux is not unix.
The debate is moot because too many people involved in the debate are using "Unix" as a hammer to beat down anything that provokes their nerd rage.
I'd say that "the Unix philosophy" is spelled out by the various documents that the Wikipedia "Unix philosophy" page cites. Whether it covers mechanisms such as the init system, much less the kernel-mode code, is, well, subject to debate.
And something doesn't have to "be Unix" in the trademark sense or in the "you can draw some line of descent by which the code derives from Bell Labs Unix" sense to be Unix-like enough for people to debate whether it conforms to the Unix philosophy or not. As far as I'm concerned, Linux is Unix-like enough for that, and it pretty much works as well as other Unix-like systems, whether they're "Unix(R)" or "V7-derived" or not, in that regard. (And most of those systems probably support the -v flag to cat.:-))
Systemd does the exact opposite of that. One monolithic service doing everything
Presumably by "service" you're not referring only to what process 1 does by itself (rather than by services it runs) on a system with systemd.
Re:When you have a hammer
on
KDE Turns 19
·
· Score: 1
Binary compatibility shouldn't be a problem on Linux, assuming you're using the same architecture as was built for (e.g., 32-bit x86, 64-bit x86, etc.). The problem is libraries: open-source stuff always links to a lot of libraries which are included with the distros, so you can't easily just take a binary from one distro and run it on another, because the libs won't match up.
Yes, by "Linux" I meant "full Linux distribution", not just "Linux kernel".
For proprietary stuff, this shouldn't be a problem: they just need to statically link everything. I'm pretty sure that's how actual proprietary software on Linux is distributed (there is some out there, you know; most of it is really high-end stuff).
Probably because all they can count on being binary-compatible between distributions is the kernel. Some might prefer not to have to statically link everything, but that's not the way it works in Linuxland.
(That is the way it works in OS X and, as far as I know, Solaris; for SunOS, all the way back to SunOS 4.0, the idea was that the ABI was expressed in terms of calls to dynamically-linked library routines, not system calls, and the system call interface was not guaranteed to remain binary compatible from OS release to OS release, and that was pushed even further in SunOS 5.0/SVR4/ELF by not requiring the C startup code to load the run-time linker using direct system calls. OS X is similar, although with Mach-O rather than ELF. You have to dynamically link with, at minimum, libc/libSystem on those platforms; at least in OS X, you're probably forced to dynamically link with all Apple-developed libraries.)
Re:When you have a hammer
on
KDE Turns 19
·
· Score: 1
A real Linux user will not download an app.
They will just write a script!
:-)
Re:When you have a hammer
on
KDE Turns 19
·
· Score: 1
I disagree. Currently, Linux desktop share (in reality, not just looking at sales numbers which of course is idiotic since most people install Linux themselves rather than buying a PC with it pre-installed) is tiny, and has very little visibility. It's hard to say exactly how small it is, but it's not likely to be have more users than MacOSX.
If NetMarketShare is to be believed, and if measuring based on Web access is good enough, Linux has about a 1.74% share and OS X has about 7.72%.
Anyway, as a consequence the availability of applications is rather poor, which prevents more people, who would like to switch, from adopting it because they rely on certain proprietary apps (usually business-related).
It'd be nice to have better marketshare, maybe around 25%, because then there'd be much better support.
Well, just 7.72% might get you the level of support OS X has (which, from a desktop point of view, includes Microsoft Office and Quicken, for example), although Linux might need a bit more to encourage developers to add it as a platform. My pure worth-every-cent-you-paid-for-it guess would be that something in the range of 10-to-15% would be sufficient, but 25% would definitely make people take notice. (And don't count the money you paid for your computer, its OS, its browser, and its Internet connection when measuring my guess's worth.:-))
Also, mainstream adoption wouldn't kill it; why do you think that? The big strength of Linux is its open-source nature and lack of centralized control. Even if, say, Ubuntu became the new Microsoft and all Windows users suddenly installed Ubuntu (not likely, but let's suppose), most of the software is open-source: the kernel, main libraries, etc. All those other distros will still be around, and doing things differently than Ubuntu: different DEs, maybe even different init systems, etc. You'll still be able to use a distro that suits you better.
Although without some level of binary compatibility between distributions, the other distributions might not get to run the proprietary apps in question. (Some might consider the lack of proprietary apps a feature, but, well, if you have a lack of centralized control, you may end up with distributions that do run a number of proprietary apps; the "no centralized control" knife cuts both ways, it doesn't necessarily favor free software fans in all cases. Pick your distribution based on, among other things, whether you want the proprietary apps or reject proprietary apps.)
The answer given by The Fine Press Release to your question is "not only products*[2] for video image production, but also medical monitors and gaming PC monitors which require, high resolution and depth in image quality, and many more." with footnote 2 saying
According to the roadmap for 4K/8K Television & Broadcasting of Japan's Ministry of Internal Affairs and Communications, it is expected that commercial 4K broadcasting over CS, CATV and IPTV to start in 2015. Experimental 4K/8K broadcasting over BS is anticipated in 2016, with commercial 4K/8K broadcasting over BS aiming to be active no later than 2018.
(I don't know what "BS" means in this context, except that it presumably isn't intended to mean what I, at least, and many others usually assume it means. Then again, maybe that roadmap is BS....)
Typing in a 16-character link and hitting enter, clicking on a 16-character link, or even just putting your cursor over a 16-character link, will crash Google's browser.
Gee, I typed in http://sonic.com and hit Enter, and it worked Just Fine.
Perhaps they meant to say "Typing in a particular 16-character link, clicking on a particular 16-character link, or even just putting your cursor over a particular 16-character link, will crash Google's browser."
...like allowing spaces in file names. Incredibly bad idea
...shared by every UN*X out there and by Windows NT. Not at all a problem from the GUI (nice, actually), and, from the command line, shells allow quoting and many UN*X shells will escape spaces when doing auto-completion. Yeah, you have to take a little more care when writing shell scripts, and use "-print0" with find and "-0" with xargs, but I've managed to live with that.
With the right paradigm it can hyperconverged to an SOA that has wearable computing gamification omnichannel crowdsoursing deep web in the globosphere. It can take a selfie with you.
OK, "wearable" handles "mobile" (even better than mobile!), and maybe "hyperconverged" and "SOA" covers "cloud"; does "crowdsourcing" cover "social", or did you miss a buzzword?
Actually, this is ONC RPC, originally developed by Sun, not DCE RPC, originally developed by Apollo, adopted by the OSF, and then adopted by Microsoft, but I guess there are Windows boxes offering NFS or some other ONC RPC-based service (or providing clients for those services and, for some unknown reason, running the portmapper even if they're not offering any such services, but I digress).
IBM mainframes were commonly virtual machines. Unlike their predecessors, which had their instructions hard-wired into them, the System/360 and later boxes usually had some sort of "Initial MicroProgram Load" phase that kitted out the machine's NVRAM with the microcode that made them all run the common S/360 instruction set, regardless of underlying hardware, which could be quite radically different, depending on the make and model.
For System/360, only the Model 85 and Model 25 had microcode in RAM rather than ROM (the Model 75 and Model 91 didn't have any microcode, the instruction set was implemented in hardwired logic). The hardware was, as far as I know, primarily designed to implement the System/3x0 instruction set; different machines may have been friendly towards other instruction sets to different degrees (emulators existed for some 140x and 709x machines, but they only needed to run those instruction sets as well as the original machines, not as well as the S/3x0 instruction set ran). Writable control store became common in System/370.
These days, I think the commonly-used instructions are hardwired (and multi-operation instructions cracked into micro-ops, Pentium-Pro-and-successors-style, in the latest chips), and some of the more-complicated instructions may trap to "millicode", which is native machine code, perhaps with special access to machine-specific hardware. (Yes, it does sound a bit like PALcode.)
Since "C" generally really is "K" in Latin, but people anyway seem quite happy to talk about stuff like"Sentrums" and "Seramics", I don't quite see your point.
His point is presumably that accenting the "e" at the end of "niche" reveals that the person doing so learned about accents, but didn't learn that "niche" doesn't have an accent over the "e" in French, in French class.
Z has plenty of custom hardware - I think it's fair to say it's predominantly custom - the branch predictor would have to be pretty different, and of course power doesn't have a BCD arithmetic unit.
Actually, it does have IEEE decimal floating-point, as does z/Architecture. z/Architecture has decimal fixed point, but, these days, it might just trap to millicode doing tricks such as excess-6 for carry propagation. (And the PowerPC processors in at least some AS/400 machines added some instructions to assist BCD arithmetic.)
Anyway, I'll argue that they're spiritually and economically related, and there's more than a passing family resemblance. Kind of like power and modern ("advanced server") iSeries,
There is no iSeries any more, there's just the IBM Power Systems, which are the successors to both RS/6000^WpSeries^WSystem p and to AS/400^WiSeries^WSystem i; they can run both AIX and IBM i.
Meanwhile, channel controllers aren't as dumb as they look. A little wikipedia action here (I know, citing wikipedia, but it's monday and I'm still tired): https://en.wikipedia.org/wiki/... . Turns out the little dickens can do a decent amount of work on its own. I think the wikipedia entry is showing its age... seems like IBM's done a lot more work since this.
Yes, but they're still I/O boxes, not general-purpose computers (well, they might be implemented with z/Architecture or Power ISA processors, but what's exposed to the OS or application programmer is just the ability to run limited channel programs). The z/Architecture Principles of Operation says in "Execution of I/O Operations", in chapter 15 "Basic I/O Functions":
For subchannels operating in command mode, the channel subsystem can execute seven types of commands: write, read, read backward, control, sense, sense ID, and transfer in channel. Each command, except transfer in channel, initiates a corresponding I/O operation.
and
For subchannels operating in transport mode, the channel subsystem can transport six types of com- mands for execution: write, read, control, sense, sense ID, and interrogate. Each command initiates a corresponding device operation.
Except this is probably IBM locking out their own operating systems, i.e. they're not "machines that can't run anything other than Linux", they're "machines that can't run z/OS or z/VSE", which IBM has already had for a while. Given that I don't think anybody's has completed a port of any other open-source OSes to z/Architecture, that may amount to "machines that can't run anything other than Linux", but, unless there are bits of z/Architecture Linux that are binary-only and that support undocumented parts of the system (which I think there might be), that's not inherent to those systems.
(This is more like Apple releasing a Mac that doesn't have the right magic to have OS X willing to boot on it; it could still run Linux or Windows or....)
Question:"... which IBM server range can run applications written for Windows NT and 2000, Novell NetWare, Aix and OS/2 as well as..."
Answer: "Probably the most important development, however, came in 1998, when the ability to run Windows NT was added (Windows 2000 has become an option now on the latest version)"
IBM has a software layer called UNIX System Services to provide an AIX environment on most of their Z-mainframes - apparently it won't be supported on this new one though. From my limited experience, I think the Linux implementation was more seamless and better regarded than USS, which had sort of a '90s-compatibility layer feel.
Because it is a compatibility layer atop OS/VS2 Multiple Virtual Storage. a/k/a MVS, or, as it's called these days with its 64-bitification, z/OS - complete with EBCDIC being the native character set (so watch out for those UN\*X programs that assume 'a' through 'z' or 'A' through 'Z' are contiguous!). If the new machines don't support z/OS, they won't support USS, either.
Slashdot Mirror
The Hurd is definitely a better example.
Absolutely, since it actually is microkernel-based. And GNU's not Unix, and neither is The Hurd. It's a POSIX-compatible Unixlike operating system, but it ain't Unix or UNIX.
As far as I know, nobody has run GNU/Hurd through the Single UNIX Specification validation suite, and therefore it's apparently not eligible to have the "Unix" trademark used for it (i.e., it's not a "Unix(R) system"), and none of its code can trace its ancestry to any Unix code from Bell Labs.
However, it probably looks enough like actual Unix systems that one could ask whether it violates the "Unix philosophy"(TM) or not; given that its userland is GNU, Doug McIlroy might argue that it's been fed enough goodies to bring it to a disheartening state of obesity (joining Linux, for much the same reason, and, I suspect, most other Un*xes these days in McIlroy's opinion). On the other hand, the usual flavors of pipeline continue to work on it, Linux, and those other Un*xes, the obesity notwithstanding, which is good enough for me.
OSX uses a microkernel. Besides, there are/were plenty of Unix that used microkernels: OSF/1, Digital Unix/Tru64, etc.
The point is moot any way, most of you aspies don't understand the debate is moot because Linux is not unix.
The debate is moot because too many people involved in the debate are using "Unix" as a hammer to beat down anything that provokes their nerd rage.
I'd say that "the Unix philosophy" is spelled out by the various documents that the Wikipedia "Unix philosophy" page cites. Whether it covers mechanisms such as the init system, much less the kernel-mode code, is, well, subject to debate.
And something doesn't have to "be Unix" in the trademark sense or in the "you can draw some line of descent by which the code derives from Bell Labs Unix" sense to be Unix-like enough for people to debate whether it conforms to the Unix philosophy or not. As far as I'm concerned, Linux is Unix-like enough for that, and it pretty much works as well as other Unix-like systems, whether they're "Unix(R)" or "V7-derived" or not, in that regard. (And most of those systems probably support the -v flag to cat. :-))
Is XNU microkernel-based? That's one for the semanticists to debate. Arguably the Mach-based code is not performing microkernel functions.
I'm not sure that it arguably is performing them; it seems pretty clear to me that it isn't.
What is not debatable is that there are or have been Unix-"alike" OS'es baed on microkernels. Minix is one. Hurd is another.
The Hurd is definitely a better example.
Systemd does the exact opposite of that. One monolithic service doing everything
Presumably by "service" you're not referring only to what process 1 does by itself (rather than by services it runs) on a system with systemd.
Binary compatibility shouldn't be a problem on Linux, assuming you're using the same architecture as was built for (e.g., 32-bit x86, 64-bit x86, etc.). The problem is libraries: open-source stuff always links to a lot of libraries which are included with the distros, so you can't easily just take a binary from one distro and run it on another, because the libs won't match up.
Yes, by "Linux" I meant "full Linux distribution", not just "Linux kernel".
For proprietary stuff, this shouldn't be a problem: they just need to statically link everything. I'm pretty sure that's how actual proprietary software on Linux is distributed (there is some out there, you know; most of it is really high-end stuff).
Probably because all they can count on being binary-compatible between distributions is the kernel. Some might prefer not to have to statically link everything, but that's not the way it works in Linuxland.
(That is the way it works in OS X and, as far as I know, Solaris; for SunOS, all the way back to SunOS 4.0, the idea was that the ABI was expressed in terms of calls to dynamically-linked library routines, not system calls, and the system call interface was not guaranteed to remain binary compatible from OS release to OS release, and that was pushed even further in SunOS 5.0/SVR4/ELF by not requiring the C startup code to load the run-time linker using direct system calls. OS X is similar, although with Mach-O rather than ELF. You have to dynamically link with, at minimum, libc/libSystem on those platforms; at least in OS X, you're probably forced to dynamically link with all Apple-developed libraries.)
A real Linux user will not download an app.
They will just write a script!
:-)
I disagree. Currently, Linux desktop share (in reality, not just looking at sales numbers which of course is idiotic since most people install Linux themselves rather than buying a PC with it pre-installed) is tiny, and has very little visibility. It's hard to say exactly how small it is, but it's not likely to be have more users than MacOSX.
If NetMarketShare is to be believed, and if measuring based on Web access is good enough, Linux has about a 1.74% share and OS X has about 7.72%.
Anyway, as a consequence the availability of applications is rather poor, which prevents more people, who would like to switch, from adopting it because they rely on certain proprietary apps (usually business-related).
It'd be nice to have better marketshare, maybe around 25%, because then there'd be much better support.
Well, just 7.72% might get you the level of support OS X has (which, from a desktop point of view, includes Microsoft Office and Quicken, for example), although Linux might need a bit more to encourage developers to add it as a platform. My pure worth-every-cent-you-paid-for-it guess would be that something in the range of 10-to-15% would be sufficient, but 25% would definitely make people take notice. (And don't count the money you paid for your computer, its OS, its browser, and its Internet connection when measuring my guess's worth. :-))
Also, mainstream adoption wouldn't kill it; why do you think that? The big strength of Linux is its open-source nature and lack of centralized control. Even if, say, Ubuntu became the new Microsoft and all Windows users suddenly installed Ubuntu (not likely, but let's suppose), most of the software is open-source: the kernel, main libraries, etc. All those other distros will still be around, and doing things differently than Ubuntu: different DEs, maybe even different init systems, etc. You'll still be able to use a distro that suits you better.
Although without some level of binary compatibility between distributions, the other distributions might not get to run the proprietary apps in question. (Some might consider the lack of proprietary apps a feature, but, well, if you have a lack of centralized control, you may end up with distributions that do run a number of proprietary apps; the "no centralized control" knife cuts both ways, it doesn't necessarily favor free software fans in all cases. Pick your distribution based on, among other things, whether you want the proprietary apps or reject proprietary apps.)
I'd expect it to be more like the 5600 block of South Ellis Ave.
The answer given by The Fine Press Release to your question is "not only products*[2] for video image production, but also medical monitors and gaming PC monitors which require, high resolution and depth in image quality, and many more." with footnote 2 saying
(I don't know what "BS" means in this context, except that it presumably isn't intended to mean what I, at least, and many others usually assume it means. Then again, maybe that roadmap is BS....)
"In this edition of Tina's hourly newsletter, I compare our projects to various types of wood."
Typing in a 16-character link and hitting enter, clicking on a 16-character link, or even just putting your cursor over a 16-character link, will crash Google's browser.
Gee, I typed in http://sonic.com and hit Enter, and it worked Just Fine.
Perhaps they meant to say "Typing in a particular 16-character link, clicking on a particular 16-character link, or even just putting your cursor over a particular 16-character link, will crash Google's browser."
That's because educational institutions should be staffed with people who have the burning desire to teach other people.
So what kind of institution is a "research university"?
...like allowing spaces in file names. Incredibly bad idea
...shared by every UN*X out there and by Windows NT. Not at all a problem from the GUI (nice, actually), and, from the command line, shells allow quoting and many UN*X shells will escape spaces when doing auto-completion. Yeah, you have to take a little more care when writing shell scripts, and use "-print0" with find and "-0" with xargs, but I've managed to live with that.
Why a duck?
With the right paradigm it can hyperconverged to an SOA that has wearable computing gamification omnichannel crowdsoursing deep web in the globosphere. It can take a selfie with you.
OK, "wearable" handles "mobile" (even better than mobile!), and maybe "hyperconverged" and "SOA" covers "cloud"; does "crowdsourcing" cover "social", or did you miss a buzzword?
Visual punchcard
Seek and ye shall find.
Soon we will only be able to take photographs of people in the nude in a wilderness
As long as you don't get sued by their hairstylist for taking pictures that show their hairstyle.
Retarded windows admins.
Actually, this is ONC RPC, originally developed by Sun, not DCE RPC, originally developed by Apollo, adopted by the OSF, and then adopted by Microsoft, but I guess there are Windows boxes offering NFS or some other ONC RPC-based service (or providing clients for those services and, for some unknown reason, running the portmapper even if they're not offering any such services, but I digress).
IBM mainframes were commonly virtual machines. Unlike their predecessors, which had their instructions hard-wired into them, the System/360 and later boxes usually had some sort of "Initial MicroProgram Load" phase that kitted out the machine's NVRAM with the microcode that made them all run the common S/360 instruction set, regardless of underlying hardware, which could be quite radically different, depending on the make and model.
For System/360, only the Model 85 and Model 25 had microcode in RAM rather than ROM (the Model 75 and Model 91 didn't have any microcode, the instruction set was implemented in hardwired logic). The hardware was, as far as I know, primarily designed to implement the System/3x0 instruction set; different machines may have been friendly towards other instruction sets to different degrees (emulators existed for some 140x and 709x machines, but they only needed to run those instruction sets as well as the original machines, not as well as the S/3x0 instruction set ran). Writable control store became common in System/370.
These days, I think the commonly-used instructions are hardwired (and multi-operation instructions cracked into micro-ops, Pentium-Pro-and-successors-style, in the latest chips), and some of the more-complicated instructions may trap to "millicode", which is native machine code, perhaps with special access to machine-specific hardware. (Yes, it does sound a bit like PALcode.)
Since "C" generally really is "K" in Latin, but people anyway seem quite happy to talk about stuff like"Sentrums" and "Seramics", I don't quite see your point.
His point is presumably that accenting the "e" at the end of "niche" reveals that the person doing so learned about accents, but didn't learn that "niche" doesn't have an accent over the "e" in French, in French class.
Z has plenty of custom hardware - I think it's fair to say it's predominantly custom - the branch predictor would have to be pretty different, and of course power doesn't have a BCD arithmetic unit.
Actually, it does have IEEE decimal floating-point, as does z/Architecture. z/Architecture has decimal fixed point, but, these days, it might just trap to millicode doing tricks such as excess-6 for carry propagation. (And the PowerPC processors in at least some AS/400 machines added some instructions to assist BCD arithmetic.)
Anyway, I'll argue that they're spiritually and economically related, and there's more than a passing family resemblance. Kind of like power and modern ("advanced server") iSeries,
There is no iSeries any more, there's just the IBM Power Systems, which are the successors to both RS/6000^WpSeries^WSystem p and to AS/400^WiSeries^WSystem i; they can run both AIX and IBM i.
Meanwhile, channel controllers aren't as dumb as they look. A little wikipedia action here (I know, citing wikipedia, but it's monday and I'm still tired): https://en.wikipedia.org/wiki/... . Turns out the little dickens can do a decent amount of work on its own. I think the wikipedia entry is showing its age... seems like IBM's done a lot more work since this.
Yes, but they're still I/O boxes, not general-purpose computers (well, they might be implemented with z/Architecture or Power ISA processors, but what's exposed to the OS or application programmer is just the ability to run limited channel programs). The z/Architecture Principles of Operation says in "Execution of I/O Operations", in chapter 15 "Basic I/O Functions":
and
I guess if MS can do it, IBM can too.
Except this is probably IBM locking out their own operating systems, i.e. they're not "machines that can't run anything other than Linux", they're "machines that can't run z/OS or z/VSE", which IBM has already had for a while. Given that I don't think anybody's has completed a port of any other open-source OSes to z/Architecture, that may amount to "machines that can't run anything other than Linux", but, unless there are bits of z/Architecture Linux that are binary-only and that support undocumented parts of the system (which I think there might be), that's not inherent to those systems.
(This is more like Apple releasing a Mac that doesn't have the right magic to have OS X willing to boot on it; it could still run Linux or Windows or....)
I also noticed the TechCrunch article has a link to the announcement: http://www.linuxfoundation.org/news-media/announcements/2015/08/linux-foundation-brings-together-industry-heavyweights-advance which produces "Access Denied"!!
Works for me....
So I shortened it: http://www.linuxfoundation.org/news-media/announcements/2015/08/ And that page shows no such announcement.
It does now, at the top.
mainframe servers that only run on Linux.
Something about that quote seems backwards to me. Can I run that server on a raspberry pi running Linux?
Will Hercules run on an Raspberry Pi? If so, then, yes, you can run that server on a Raspberry Pi running Linux.
(But, yes, it should have said "that only run Linux".)
Question:"... which IBM server range can run applications written for Windows NT and 2000, Novell NetWare, Aix and OS/2 as well as..."
Answer: "Probably the most important development, however, came in 1998, when the ability to run Windows NT was added (Windows 2000 has become an option now on the latest version)"
* BOTH quotes are from -> http://www.computerweekly.com/...
...which is talking about add-on x86 processors running NT (and other x86 operating systems).
IBM has a software layer called UNIX System Services to provide an AIX environment on most of their Z-mainframes - apparently it won't be supported on this new one though. From my limited experience, I think the Linux implementation was more seamless and better regarded than USS, which had sort of a '90s-compatibility layer feel.
Because it is a compatibility layer atop OS/VS2 Multiple Virtual Storage. a/k/a MVS, or, as it's called these days with its 64-bitification, z/OS - complete with EBCDIC being the native character set (so watch out for those UN\*X programs that assume 'a' through 'z' or 'A' through 'Z' are contiguous!). If the new machines don't support z/OS, they won't support USS, either.