North Coast Public Access *ix opened in July 1991, running Xenix/68000 on a TRS-80 Model 16. It was bare-bones at the time (no BBS features at all, just a shell prompt or a slightly buggy menu-system shell script). (it appears they *still* don't have a web page...)
*Raw* telnet is in the kernel as a STREAMS module in STREAMS-based Unixes, to reduce the number of context switches. Telnet option negotiation remains in user-space.
> For that reason, you can expect to read all kinds of dire things in the Red Hat IPO documents. They must spell > out in big letters that investment in Red Hat is risky, even if they are convinced that Red Hat will conquer all > obstacles and make piles of money.
They already did... the SEC filing was on/. some time back. One of the "risks" was that the GPL hasn't yet been tested in court....
Your font problem is due to scaling: bitmap fonts don't scale at all well, and Type 1 fonts don't really have enough scaling hints to work well at screen resolutions. TrueType fonts are better for this --- ideally, one would use TrueType on screen and Type 1 for printing, but then you have to find fonts with matching metrics....
Antialiasing has a bigger problem: X fonts are depth-1 bitmaps. Changing this would involve major, incompatible changes to the X protocol and Xlib, breaking every application. Or a whole new API added on top of the existing one, making the new server even more complex (= bloated and buggy, trying to make the two font systems work together properly) and making life hell for the X toolkit and application folks. This might be an idea for X Version 12, but I expect it won't happen in any X11 release.
Re:XFree86 could be a little more open
on
XFree86 News
·
· Score: 3
> XFree could start by opening up its codebase a little.
Once upon a time, it was open. Then certain Linux distribution maintainers (no longer around) decided it'd be neat to include outdated, buggy pre-alpha X releases in their distributions --- and redirected all the bug reports to the XFree folks. They Were Not Happy, and I don't blame them.
The upshot here is that *we* screwed up, and the XFree folks got burned badly as a result. If we want to see more open XFree86 development, we're going to have to prove to them that we're not going to pull stunts like that any more.
(Unfortunately, with Red Hat's fondness for including prerelease stuff in their distributions --- "prepatch" kernels and Perl "m" releases, to name some from the 5.x era --- I'm not sure I'd trust them to keep their mitts off prerelease XFree86 code.)
Sequent's big thing is NUMA architectures --- an alternative to SMP which avoids some of SMP's problems (ensuring cache consistency across many processors sharing the same memory is a nightmare, for instance, and carries a significant performance penalty for large numbers of processors). Buying Sequent doesn't mean anything for the low end, because SMP works well there; it's high-end multiprocessing they're after.
Unfortunately, small bugs in KDE and XFree86 require rerelease of the whole package, not just the tiny part with the bugs --- that's most of the size right there.
The real problem with voter turnout isn't accessibility; it's apathy. People who feel their vote won't make a difference --- either because they're convinced that someone's already "bought" the election, or because they don't see anything worth voting for --- won't bother to vote.
...and canned goods, bottled water, and ammo will be worth a lot more if that happens. Barter is far more fundamental than gold/silver/etc. standards, and almost guaranteed to survive any conceivable disaster that leaves anyone around to care about the aftermath.
> I really wish Amiga would start putting its plans into motion. Its always a bad sign when a > company says they'll do blah A, then decide Blah B,and then doing absolutly nothing.
How do you know they're not doing anything? There is a *lot* of stuff involved in what they're doing, and most of it is visible only to the people working on the infrastructure (which is invisible and meaningless to most people). Part of the reason Linux got going so quickly is that there were convenient GNU and BSD user-space programs sitting around that already fit on top of it because Linux was designed to be interface-compatible with them from the start; Amiga Inc. has to start almost from scratch with the user space. It's a *big* job, and one that's virtually unnoticeable until it's almost ready for release relative to the entire development cycle.
An example: how much of Berlin development is actually visible to most people? Not much, except to the people developing it. Does that mean it's nothing but vapor, or just that it's not yet ready for people to start *using* it yet? (Well, Berlin is somewhat more visible because its development is a' la bazaar, but that's another issue entirely.)
Eh? For a start, they can provide a completely different user-space --- and I don't mean just a "user interface".
Just because the kernel is Linux doesn't mean the system riding on top of it has to look anything like a typical Linux distribution. Most of what ordinary people (as opposed to kernel developers) think of as "Linux" is defined not by the kernel, but by/sbin/init and the programs run by it; the kernel itself only defines (a) the *raw* --- not libc-"cooked" --- kernel interface and (b)/sbin/init as the program run to "launch" user space.
Pathnames? They're part of the raw kernel interface. If the standard library doesn't export routines which use kernel-style pathnames, they're effectively invisible to userspace unless a program makes raw system calls using assembly language: can *you* tell whether libc.so/DOSCALL1.DLL/whatever's open() is a simple wrapper around the kernel's "open" syscall or a complex one which maps DOS or Mac or VMS, etc. conventions to the kernel? In a properly designed system, the kernel interface would be entirely irrelevant to everyone except OS and kernel programmers; in particular, neither application developers nor users need to care. Apple's "Carbon" (aka Yellow Box, etc.) is based on the same idea.
What was the alternative? A rescue mission? The technology wasn't up to it. But dwelling on it would have led to pressure to mount such a mission --- which wouldn't have been possible. It would have been a disaster, and not just a PR disaster.
Yes, it sounds cold and callous. But read "The Cold Equations" to find out why it had to be that way. (Quick summary: the universe doesn't give a flying fart about human sensibilities, and cares even less about breast-beating over the unfairness of it all.)
NB: that doesn't mean we should give up on human sensibilities. It *does* mean that sometimes we lose, and there isn't anything to be done about it.
The difference between paper UCE and e-mail UCE is that the former is paid for by the sender, but the latter is paid for in part by the recipient: the USPS claims that they are funded entirely by service fees levied on the sender (including postage fees), and not by e.g. taxes, but I have to pay for my own Internet connection (indirectly in my case --- I'm using a "free" dialup provided to CMU staff, but I get that in return for *work*). I should not have to contribute to the cost of unsolicited mail: if J. Random Company, Inc. wants to send unsolicited mail to me, let *it* foot the bill.
That's part of quantum electrodynamics IIRC (I'm not a physicist, nor do I play one on TV). In a sense it's not all that "deep": any QED interaction is indistinguishable from an interaction where all particles are replaced by their antiparticles, viewed in reverse. So antiparticles are essentially the same as normal particles moving backward in time from the standpoint of QED.
> And that they aren't written by the genius who picked the name Athlon...
??? I thought it was a pretty good choice, myself, if perhaps relying a bit too much on a geek-oriented pun.
Re:AMD going under would be the end of Intel
on
Intel Undercuts AMD
·
· Score: 1
> Something everyone seems to forget is Intel makes > the Compaq/DEC Alpha chips. Intel bought the old DEC Chip Fab and now makes the Alphas > as well as making the ARM chip.
Samsung was a second source for Alpha chips, and still is (if they aren't in fact the primary source for them now...).
"Bread and circuses" is the second most dangerous problem with democracy. (The first is corruption, which is the most dangerous problem with every system of government.)
The masses have *never* been interested in being informed participants in any system. They care only that their lives are reasonably stable, and that they can get food and entertainment. In a pure democracy, the putative ruling class is "the people" but the de-facto ruling class is "the people who care enough to participate" --- always a tiny subset of the former, and thus easily marginalized by special interests (including big business, etc.).
Part of this is that it's widely believed that MCSE certification is sufficient to be an NT admin.
I'm not knocking MCSE's here; OS certification tends not to be worth much regardless of the OS. The same problem applies to CNEs, Solaris 2000-level certification, etc. But with PHBs dragging in NT by the boatload, they expect that any random MCSE can make and keep it running.
Having a fancy certificate can never replace solid hands-on experience, whether with NT, NetWare, Unix, etc. (An experienced NT admin can make NT work adequately, or even "well", for relatively low-usage (compared to enterprise installations with tens or hundreds of thousands of users.)
In fact, to be honest, NT is *not* the absolute horror some paint it as. It *can* be, if installed and administered by someone who doesn't really know what they're doing; perhaps NT's single biggest problem is the "anyone can manage it" mentality that Microsoft fosters. NT, like any other OS, lets you shoot yourself in the foot --- this, combined with the "any warm body" mentality, virtually ensures disaster. (That said, its second biggest problem is that it doesn't really scale because Microsoft thinks a "big" installation is 200 users --- so even a good NT admin will have problems with a large installation.)
Actually, early announcement is common. It has to be: that's part of how things get peer-reviewed. As soon as it's preannounced, labs all over the world set out to duplicate the results, in order to prove/disprove its existence and if possible find out more about what's really happening and why.
The problems occur when it's over-publicized (as with "cold fusion").
Unix was not based on MULTICS. It was based on some of the *ideas* in MULTICS --- but MULTICS itself was tightly bound to the hardware it ran on, a very nonstandard machine whose like no longer exists.
SPARC Linux is 64-bit in the kernel, but there are issues relating to a microcode bug in the UltraSPARC I CPU preventing the userspace from going 64-bit. (The same issues caused Sun to prevent Solaris 7 from running 64-bit userspace on UltraSPARC Is. Suffice it to say that Sun has its own "F00F bug"....) Sun is refusing to release details about the microcode bug, so it's not possible to try to devise a workaround a' la the Pentium F00F bug; and the SPARCLinux team seems to have decided not to go the Solaris 7 route and block 64-bit userspace on UltraSPARC Is while permitting it on UltraSPARC IIs.
IIRC Intel is already working on a Linux port for IA64.
Slashdot Mirror
North Coast Public Access *ix opened in July 1991, running Xenix/68000 on a TRS-80 Model 16. It was bare-bones at the time (no BBS features at all, just a shell prompt or a slightly buggy menu-system shell script). (it appears they *still* don't have a web page...)
*Raw* telnet is in the kernel as a STREAMS module in STREAMS-based Unixes, to reduce the number of context switches. Telnet option negotiation remains in user-space.
> For that reason, you can expect to read all kinds of dire things in the Red Hat IPO documents. They must spell
/. some time back. One of the "risks" was that the GPL hasn't yet been tested in court....
> out in big letters that investment in Red Hat is risky, even if they are convinced that Red Hat will conquer all
> obstacles and make piles of money.
They already did... the SEC filing was on
Uh, I'm not a Debian developer. (Nor am I a Red Hat developer.)
I *am* in RH's bugzilla, though. And active on gnome-devel... but as a Solaris developer.
Your font problem is due to scaling: bitmap fonts don't scale at all well, and Type 1 fonts don't really have enough scaling hints to work well at screen resolutions. TrueType fonts are better for this --- ideally, one would use TrueType on screen and Type 1 for printing, but then you have to find fonts with matching metrics....
Antialiasing has a bigger problem: X fonts are depth-1 bitmaps. Changing this would involve major, incompatible changes to the X protocol and Xlib, breaking every application. Or a whole new API added on top of the existing one, making the new server even more complex (= bloated and buggy, trying to make the two font systems work together properly) and making life hell for the X toolkit and application folks. This might be an idea for X Version 12, but I expect it won't happen in any X11 release.
> XFree could start by opening up its codebase a little.
Once upon a time, it was open. Then certain Linux distribution maintainers (no longer around) decided it'd be neat to include outdated, buggy pre-alpha X releases in their distributions --- and redirected all the bug reports to the XFree folks. They Were Not Happy, and I don't blame them.
The upshot here is that *we* screwed up, and the XFree folks got burned badly as a result. If we want to see more open XFree86 development, we're going to have to prove to them that we're not going to pull stunts like that any more.
(Unfortunately, with Red Hat's fondness for including prerelease stuff in their distributions --- "prepatch" kernels and Perl "m" releases, to name some from the 5.x era --- I'm not sure I'd trust them to keep their mitts off prerelease XFree86 code.)
Janus... the two-faced god. How appropriate.
Nope.
Sequent's big thing is NUMA architectures --- an alternative to SMP which avoids some of SMP's problems (ensuring cache consistency across many processors sharing the same memory is a nightmare, for instance, and carries a significant performance penalty for large numbers of processors). Buying Sequent doesn't mean anything for the low end, because SMP works well there; it's high-end multiprocessing they're after.
"Support the PowerPC processor"? They *do* support it: IIRC they are the biggest user of PowerPC. In AS/400s and big iron.
Unfortunately, small bugs in KDE and XFree86 require rerelease of the whole package, not just the tiny part with the bugs --- that's most of the size right there.
It's also not out of line compared to RH5.0....
The real problem with voter turnout isn't accessibility; it's apathy. People who feel their vote won't make a difference --- either because they're convinced that someone's already "bought" the election, or because they don't see anything worth voting for --- won't bother to vote.
...and canned goods, bottled water, and ammo will be worth a lot more if that happens. Barter is far more fundamental than gold/silver/etc. standards, and almost guaranteed to survive any conceivable disaster that leaves anyone around to care about the aftermath.
> I really wish Amiga would start putting its plans into motion. Its always a bad sign when a
> company says they'll do blah A, then decide Blah B,and then doing absolutly nothing.
How do you know they're not doing anything? There is a *lot* of stuff involved in what they're doing, and most of it is visible only to the people working on the infrastructure (which is invisible and meaningless to most people). Part of the reason Linux got going so quickly is that there were convenient GNU and BSD user-space programs sitting around that already fit on top of it because Linux was designed to be interface-compatible with them from the start; Amiga Inc. has to start almost from scratch with the user space. It's a *big* job, and one that's virtually unnoticeable until it's almost ready for release relative to the entire development cycle.
An example: how much of Berlin development is actually visible to most people? Not much, except to the people developing it. Does that mean it's nothing but vapor, or just that it's not yet ready for people to start *using* it yet? (Well, Berlin is somewhat more visible because its development is a' la bazaar, but that's another issue entirely.)
Eh? For a start, they can provide a completely different user-space --- and I don't mean just a "user interface".
/sbin/init and the programs run by it; the kernel itself only defines (a) the *raw* --- not libc-"cooked" --- kernel interface and (b) /sbin/init as the program run to "launch" user space.
Just because the kernel is Linux doesn't mean the system riding on top of it has to look anything like a typical Linux distribution. Most of what ordinary people (as opposed to kernel developers) think of as "Linux" is defined not by the kernel, but by
Pathnames? They're part of the raw kernel interface. If the standard library doesn't export routines which use kernel-style pathnames, they're effectively invisible to userspace unless a program makes raw system calls using assembly language: can *you* tell whether libc.so/DOSCALL1.DLL/whatever's open() is a simple wrapper around the kernel's "open" syscall or a complex one which maps DOS or Mac or VMS, etc. conventions to the kernel? In a properly designed system, the kernel interface would be entirely irrelevant to everyone except OS and kernel programmers; in particular, neither application developers nor users need to care. Apple's "Carbon" (aka Yellow Box, etc.) is based on the same idea.
Like that doesn't happen in the Windows, Mac, OS/2, Solaris, Linux, etc., etc., ad nauseam communities as well?
What was the alternative? A rescue mission? The technology wasn't up to it. But dwelling on it would have led to pressure to mount such a mission --- which wouldn't have been possible. It would have been a disaster, and not just a PR disaster.
Yes, it sounds cold and callous. But read "The Cold Equations" to find out why it had to be that way. (Quick summary: the universe doesn't give a flying fart about human sensibilities, and cares even less about breast-beating over the unfairness of it all.)
NB: that doesn't mean we should give up on human sensibilities. It *does* mean that sometimes we lose, and there isn't anything to be done about it.
Well, not entirely, at least in the U.S.
The difference between paper UCE and e-mail UCE is that the former is paid for by the sender, but the latter is paid for in part by the recipient: the USPS claims that they are funded entirely by service fees levied on the sender (including postage fees), and not by e.g. taxes, but I have to pay for my own Internet connection (indirectly in my case --- I'm using a "free" dialup provided to CMU staff, but I get that in return for *work*). I should not have to contribute to the cost of unsolicited mail: if J. Random Company, Inc. wants to send unsolicited mail to me, let *it* foot the bill.
That's part of quantum electrodynamics IIRC (I'm not a physicist, nor do I play one on TV). In a sense it's not all that "deep": any QED interaction is indistinguishable from an interaction where all particles are replaced by their antiparticles, viewed in reverse. So antiparticles are essentially the same as normal particles moving backward in time from the standpoint of QED.
> And that they aren't written by the genius who picked the name Athlon...
??? I thought it was a pretty good choice, myself, if perhaps relying a bit too much on a geek-oriented pun.
> Something everyone seems to forget is Intel makes
> the Compaq/DEC Alpha chips. Intel bought the old DEC Chip Fab and now makes the Alphas
> as well as making the ARM chip.
Samsung was a second source for Alpha chips, and still is (if they aren't in fact the primary source for them now...).
"Bread and circuses" is the second most dangerous problem with democracy. (The first is corruption, which is the most dangerous problem with every system of government.)
The masses have *never* been interested in being informed participants in any system. They care only that their lives are reasonably stable, and that they can get food and entertainment. In a pure democracy, the putative ruling class is "the people" but the de-facto ruling class is "the people who care enough to participate" --- always a tiny subset of the former, and thus easily marginalized by special interests (including big business, etc.).
Part of this is that it's widely believed that MCSE certification is sufficient to be an NT admin.
I'm not knocking MCSE's here; OS certification tends not to be worth much regardless of the OS. The same problem applies to CNEs, Solaris 2000-level certification, etc. But with PHBs dragging in NT by the boatload, they expect that any random MCSE can make and keep it running.
Having a fancy certificate can never replace solid hands-on experience, whether with NT, NetWare, Unix, etc. (An experienced NT admin can make NT work adequately, or even "well", for relatively low-usage (compared to enterprise installations with tens or hundreds of thousands of users.)
In fact, to be honest, NT is *not* the absolute horror some paint it as. It *can* be, if installed and administered by someone who doesn't really know what they're doing; perhaps NT's single biggest problem is the "anyone can manage it" mentality that Microsoft fosters. NT, like any other OS, lets you shoot yourself in the foot --- this, combined with the "any warm body" mentality, virtually ensures disaster. (That said, its second biggest problem is that it doesn't really scale because Microsoft thinks a "big" installation is 200 users --- so even a good NT admin will have problems with a large installation.)
Actually, early announcement is common. It has to be: that's part of how things get peer-reviewed. As soon as it's preannounced, labs all over the world set out to duplicate the results, in order to prove/disprove its existence and if possible find out more about what's really happening and why.
The problems occur when it's over-publicized (as with "cold fusion").
Unix was not based on MULTICS. It was based on some of the *ideas* in MULTICS --- but MULTICS itself was tightly bound to the hardware it ran on, a very nonstandard machine whose like no longer exists.
Alpha Linux is 64-bit.
SPARC Linux is 64-bit in the kernel, but there are issues relating to a microcode bug in the UltraSPARC I CPU preventing the userspace from going 64-bit. (The same issues caused Sun to prevent Solaris 7 from running 64-bit userspace on UltraSPARC Is. Suffice it to say that Sun has its own "F00F bug"....) Sun is refusing to release details about the microcode bug, so it's not possible to try to devise a workaround a' la the Pentium F00F bug; and the SPARCLinux team seems to have decided not to go the Solaris 7 route and block 64-bit userspace on UltraSPARC Is while permitting it on UltraSPARC IIs.
IIRC Intel is already working on a Linux port for IA64.