The beauty would be you could connect generic firewire drives to the bus, and wouldn't need an expensive cabinet or dedicated
drives.
Well, instead of one expensive cabinet you get N expensive cabinets. Each drive will have an IDE disk, an IDE controller talking to the firewire bus, and a case + power supply. (Well, I guess the power supply is optional, if your firewire cable provides power.)
It's anyone's guess whether this would in fact come out cheaper than a RAID enclosure with hot-swap IDE bays. The RAID controller, in the latter case, could still have a firewire interface, though 80 MHz LVD seems to be the popular thing nowadays.
As for "plug n play" - you don't want a RAID array to be easy to disassemble. Someone will unplug a drive by accident, and then the array degrades, and has to resync when you plug the drive back in. Hot-swap IDE enclosures are more than convenient enough for replacing actual failed drives - as one hopes this wouldn't be necessary more than once every few months... right?
No, you read it right. Here's the thing. samba.org has a much larger and (well, at least back in the boom days) better-funded team than we do, so we can only concentrate on so much at a time. Printing just isn't a priority. It might work in samba-tng, in some cases (it is after all derived from samba.org code, which includes printing) but we don't pay much attention to it.
If you need your PDC to also be a print server, you should either (a) run samba-tng and samba.org on the same machine, on two separate IP addresses and netbios names (yes, this is a common and supported configuration), or (b) just use samba.org for your PDC, which in the past wasn't such a great idea but nowadays it is reported to be quite usable.
my understanding is that some of the Samba developers wanted to replace Microsoft entirely, whereas the
Samaba project was designed to coexist with an MS environment.
Well, it's vague at best. Mainly it's just a fork, with occasional code merging in both directions (though we (-tng) take quite a bit more from them (samba.org) than they do from us). Many things samba.org does better, a few things we probably do better, but then again some of the differences are just... differences.
Sorry it's hard to give a more concrete reply - I don't know the exact capabilities of samba 3.0 alpha. I suppose abartlet (from samba.org) will give you a more complete answer, as is his habit. (:
he was like "they didn't actually name it that, did they?"
(:
The name is historical. It was originally just another cvs branch in the main samba.org tree - and it had to be called something. The branch tag was SAMBA_TNG.
Suggestions welcome, I guess, but we probably won't take them. (:
Let me rephrase the question: what are people's experiences with this?
The status page notes that NT trusting Samba-TNG works. What it doesn't mention is that the converse also works, but requires a certain amount of manual setup and fiddling. This is one thing we'd like to polish up for the next release. (:
(People's experiences? Sorry, not my department, I don't use trusts..)
obKarmaBonus: because I'm a samba-tng developer (:
this is right on time ! because people will start to find NT is no longer supported by MS and move what they move to might just not
be Microsoft based because its too expensive hence samba TNG
Right. The other thing is, with LDAP support, samba-tng (and samba.org for that matter) has many of the internal advantages of Active Directory. Network-side, it still looks like NT4, but internally, you can manage it via LDAP rather than the crusty old tools.
For this reason, I personally don't see a lot of point in emulating a true Active Directory server. It just doesn't seem to buy all that much on Unix. On Win2k you have the whole world integrated into Active Directory - the DHCP server, the DNS server, dynamic DNS tying the two together, you name it. I think that's most of the value proposition of Active Directory, and on Unix the whole integration thing wouldn't be there anyway.
Years ago, when samba-tng was young and fresh, someone (can't remember who, I think Luke Howard was involved) tried to write an NT5-compatible LDAP backend. It was never finished, but the regular LDAP backend matured to the point where we don't feel we need the AD-compatible one. The difference was mainly in the LDAP schema, as I recall.
Mod parent up, cliche as that sounds. Andrew is on the Samba team and follows samba-tng as well.
There are no plans for samba.org to release Samba TNG
I think the confusion came about because samba-tng used to be just another cvs branch at samba.org, and the plan was to merge the useful bits over to the head branch. I guess to some people that sounds like "releasing another version of samba-tng".
(I swore I was getting off this bus... oh well, one quick question, one quick answer.)
Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not.
Do you have a demonstrable, objective reason for this dissatisfaction, or are we simply in the realm of "I like pink?"
I thought I'd mentioned it once or thrice already. In fact, I'm sure I did. I find my high-res text mode more readable and easier on the eyes than any graphics mode I've seen so far. I guess you must think that's a "pink" thing. Well, I think your antialiased fonts are a "pink" thing too - they aren't more readable to me. Actually I generally can't tell much difference. (I'm told sub-pixel antialiasing makes a much bigger difference, but I don't have an LCD.) So between you and me, we still can't agree on what constitutes an objective, measurable and repeatable improvement in user experience. Your explanation is that I just don't get it. Mine is that such improvements are very few and far between, and have basically all been done by everyone years ago - what's left is eye candy and "pink" preferences that one hopes will work for more people than not.
I think the way you and I use computers is so far apart that you're having trouble imagining why I find so many of your gee-whiz innovations useless, boring or even negative. To you it is self-evident ("QED!") that having these features is unilaterally better than not having them. To me it's not. Again, I don't think we're ever going to agree on this. And again, I think I'll shut up now. (Oh - if you're planning to respond - can you please let at least one post go by without the patronising "ok if you don't want to discuss this, that's fine, your prerogative, feel free to keep your closed, illogical mind" line? It's not that I'm shying away from what I feel is an indefensible position; it's that AFAICS you and I have such a high phase mismatch that I very much doubt this is anything but a waste of both our time.)
Sorry, don't buy it. You say, "My computer does X." I reply, "OS X or XP would do Y, which is superior to X." Repeat. The
conclusion? Either OS X or XP is objectively better than Linux. It's easy.
You are failing to define "superior". You are letting the term "objectively better" rule by fiat: "xxx feature is useful because yyy, therefore it is objectively better than not having xxx." That doesn't take into account people like me for whom quite a few features in the "xxx" category are either unimportant or just plain undesirable.
Worse, you have a double standard. When I say "I like the way Linux works", I am calling up an aggregate image of features which provide benefits to me - lots of features, most of them too trivial even to mention, but adding up to an experience I want from a computer. Then you say, "Sorry, I'm not talking about user preferences." So therefore for the purpose of your definitions, my user comfort level is irrelevant. Yet, when you start talking about antialiased fonts, scalable UI elements, one-button mouse design that allegedly helps prevent RSI, etc., then suddenly user comfort is considered an objective measure of utility.
You can't have it both ways. You can either concede that many computing environments (Linux included) can provide the same basic feature set for people to get their work done, differing only in matters of "style" and "ease of use" and "comfort" and "efficiency of interfaces"... or you can claim that personal preference does play a role in whether one environment can be considered "better" or "worse" than another... thus making the whole thing at least reasonably subjective.
But so long as you continue to say "This is obviously always better than that, QED", then I have nothing left to say to you. Go ahead and get in a last word (and yes, I'll read it), but I think I'm done here.
First of all, if you've gone out of your way to assemble a computer that isn't functioning properly, that's your own fault. You
just got through telling me that your computer has a Pentium 4 in it, so unless you've done something squirrely, you won't have any
problems with your graphics card.
There's nothing wrong with my computer. Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not. And I haven't yet seen a computer whose graphics output can match my high-res text mode for readability and general comfort. Maybe an LCD would eliminate the difference, but nothing I've seen on a CRT does.
Look, dude. I'm trying to be objective here. I've thrown down the gauntlet. I'm saying that either Mac OS X or Windows XP would do
a better job of running
your personal computer than Linux does.
And I'm saying that for a question like that, there is no objective answer, so you're chasing after the wind and (intentionally or otherwise) manufacturing dogma which you expect to be received as from on high.
A long time ago I read an article in, oh, must have been BYTE magazine, and the author made the point that everything he uses a computer for, he used to do without a computer - write letters, play games, crunch numbers, draw pictures, etc. The computer just made his tasks better, faster, more fun, but didn't actually change the list of things he did in life.
As far as I'm concerned, a similar argument applies to the computing platforms of today. They can all do the basic things people need out of a computer, but any given OS might accomplish certain tasks with more ease and style than its competitors.
Unfortunately for your argument, measuring ease and style is horribly subjective, not at all suited to your vocabulary of "obviously" and "QED".
Back to me and my personal computer, if you insist on calling it that. Most of the things Linux does, I could technically get done on other OSes such as OS X or even Windows XP - thus the reason I can't make a very convincing list of bullet points. But to say those are "better" for the task than Linux is to ignore the whole factor of user preference. The fact is (and now we're getting objective: this is a fact), I like how my Linux box works, a lot better than I like how Windows XP works. (OS X is somewhere in between, thanks largely to its Unix underpinnings.) I don't see why I should care if The International Twirlip of the Mists Standards Body declares that my expectations for how a computer should behave are obsolete and stupid and that I need to be forcefully re-educated in the Scripture According to Steve Jobs for the good of humanity and the gene pool.
If you think about it, most of the distinguishing features between different computing platforms nowadays are matters of style, not substance. Anti-aliased fonts? Pure style - nobody actually needs them, but to some people they look nicer. Vector-based icons? (The point of this story, in case we've forgotten.) Pure style, nobody needs to scale icons on the fly, it just looks nifty and arguably improves your UI reaction times. The "you've got mail" wave file when you start AOL? Pure style. (Negative, if anything, but hey, whatever.) Pretty, "cluelessness-resistant" OS install process? Pure style - any OS that ever needs to be reinstalled, short of total hard drive failure / replacement, is hopelessly buggy and shouldn't be considered as a contender for best-of-breed anyway. A HIG that does its level best to pretend the second mouse button never happened? Pure style - some people swear by it, others (including of course me) find it horribly constricting.
No, drawing a text window in graphics mode does not count.
Why not? I'm not arguing that either OS X or XP do exactly the same things in exactly the same way that Linux does them.
Why not? Because I have tried both ways and I prefer the one, dangit. (Same reason some people use anti-aliased or LCD sub-pixel font rendering.) Because, for almost every graphics card I've ever used[*], the text modes look nicer and are easier on my eyes - and a lot faster to render, switch to/from, and update. And, since the majority of my screen time is spent doing things that don't need a GUI, I really prefer to switch to graphics mode only when necessary.
[*] Yes, there are a couple of unfortunate exceptions. On certain modern graphics chips, VGA text modes are a mere afterthought and don't do the card justice. I try to avoid those cards (ATI, mainly).
What's that you say? I should try a higher-spec monitor? A nicer graphics card? A faster CPU? Nope, remember, we're talking about the computer I've got now. Spending more money to run a Red Queen's Race back to the status quo isn't part of the deal. (Except spending money to buy Windows XP, I guess you would say.)
Because Windows XP and Mac OS X both do the job of running a personal computer better than Linux does. QED.
What makes you think I'm running a "personal computer"? It happens that the hardware I own is marketed as such, but I consider it a development workstation, file server, etc. I think the question of whether Windows XP or Mac OS X are "better" for certain functions depends on how you define these functions. You seem to lump every computer user into a single "personal computer" profile. If you allow this profile to be broad enough, sure it fits. But then, with a broad enough profile, you can't credibly claim that XP and OS X are the best of breed. You're treading a rather thin line of semantics here.
which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM?
XP. Mac OS X doesn't run on Pentiums.
And neither does XP, with 64 MB of RAM. I'm sure it will boot up, but I expect the combination of slow CPU and (relatively) low memory will cause it to run slowly enough not to be considered "usable" by most people.
To put it in terms you would understand: I'm talking about hardware roughly on par with an early PowerPC 604: a first- or second-generation Powermac. Would OS X run on those, and if so, would it be fast enough to be usable? I have heard that a G3 is considered the minimum "sane" configuration - is that true?
(I don't mean to imply the computer I'm using right now is the Pentium 166. It's actually an early Pentium 4. My P-166 is in the next room, headless, acting as a file and web server. That was my previous desktop machine, though.)
What about a config option for not loading images, or disabling Java?
By "config option," you mean "preference control," right? Remember, Safari is real software, not something you have to compile yourself in order to make work. Safari has a control for enabling Java, but no control for loading images.
Yes, by "config option" I meant "preference control". I didn't mean a cryptic compile flag, or hand-editing a config file. I meant a check box somewhere in a Preferences dialog.
Careful. Your ignorance is showing.
Right, so it is. I haven't used Safari. I didn't know it actually lacked the ability to suppress load images. I also didn't know they had replaced the "spinner" (which my browser also does not have). But you have still admitted that it has many features not invented on the spot, like the ability to follow links by clicking on them, or scroll bars to let you display a document larger than your screen. (You didn't admit to having scroll bars, actually - I'm making another assumption here. I rest assured that you will call me on it if necessary.) It did not burst fully formed from the head of Zeus. Nor did most (dare I say all?) other software.
Oh, wait - Safari is open-source too.
There it goes again. Safari is not open-source.
You called me on it. I hadn't actually checked - I just remember reading somewhere (slashdot?) that Apple was planning to release it as open source. Now I see that while its key components are open-source, the browser shell itself possibly isn't. (The exact difference between Safari and WebCore is not clear to me.)
Let's get into it. Name one thing your computer does better than mine. Let's see who wins.
That's silly. You can't go by feature count. Things that are important to me aren't to you, and vice versa. Some features are available of many platforms but are significantly harder / uglier / more cumbersome on one than on another. (Yes, that street runs two ways, too.) What features are worth counting and what ones aren't would be subject to debate. So, I'll just concede from the outset that your OS has more bullet points of things important to the Average Computer User, by which we mean a standard deviation or two from the average end-user desktop peon.
Also it is not obvious what constitutes a unique feature. A lot of Unix software can be built for Darwin, but many Mac users wouldn't consider this software as "available" unless it comes in prepackaged form. (Of course, a lot of this software wouldn't be considered necessary or relevant for the standard deviation of computer users.)
Finally there is the difficulty that I don't know for sure that certain features plain can't be had on OS X. The one I'm thinking of right now is having about ten 144x72-cell text mode "virtual consoles" to switch between at the touch of a hotkey. I don't know if OS X does text consoles at all, but I suppose it might. (No, drawing a text window in graphics mode does not count.)
But that's kind of the point. You're making really crappy wheels, and then bragging about how revolutionary they are. The fact that
your new triangular wheel improves on the old square wheel because it has one less bump is not something to be proud of when the
rest of us are all rolling around on steel-belted whitewalls.
You must be confusing me with someone else. I've never tried to maintain that what I write is better than anything else out there. At most I strive to build something that is better for specific purposes than any other free software out there. If it's also better than proprietary alternatives, great.
That's not really true, is it? Either Windows XP or OS X would fit your needs better than Linux. This is blindingly obvious.
Really? How can this be? As far as I know, we have never met, so I find it hard to believe you have any idea what my needs are. How can it be blindingly obvious that either Windows XP or Mac OS X would fit my needs better than the system I'm typing on now?
I guess you're making the assumption that every computer user wants basically the same thing out of a computer. Apple and Microsoft both proceed on this assumption, and for one or two standard deviations of people, it works.
For a simple yet real-world example of where you are wrong: tell me, which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM? (Well, I did eventually upgrade to 128 MB, but still.)
You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992?
Nope. Features like the bookmark manager and the SnapBack function are entirely new. No imitation going on there.
How about features like a <Back> button, or an address bar, or pull-down menus, or hyperlinks that you activate by clicking on them? What about an animated graphic ("spinner") whose animation shows that a page has not completed loading? What about a config option for not loading images, or disabling Java? I have never used Safari, but I'm willing to bet that it has all of these thoroughly non-innovative features.
My point isn't that $BROWSER_OF_THE_MONTH has no new features. Most software has at least one unique feature. Even open-source software, which you seem to dismiss sight-unseen as completely reactive. (Oh, wait - Safari is open-source too. I guess you only think open-source software for Linux is non-innovative, then.) My point, and you snipped it, was that you really can't build software ex nihilo. If you write something that doesn't in the least resemble anything that has come before, it may be innovative, but it will most likely be useless as well.
The bottom line is that my computer works better than yours.
No, the bottom line is that my computer works better than yours.
Oops, unprovable statement. And not only subjective, but even more elitist than I have come to expect from Mac users, if you'll excuse the ad hominem.
Perhaps if someone gets a decent setup, you could have people producing dummy terminals that would login to an X11 applicaiton
server. It wouldn't be able to run games or anything, but it would definitely be something to consider.
You're describing 10 years ago: X terminals were quite popular in the early 90s. These are typically diskless, and run via a combination of firmware and an OS downloaded via TFTP or MOS at boot. They are small and have very quiet, if any, fans. Several of the big iron Unix vendors sold X terminals, but NCD carved out probably the biggest market share. (And yes, you can play games over them - Netrek has a full-screen play area yet seems to run fine over 10 Mbit or worse. Today's expectations of full-motion video quality graphics is another matter, though.) NCD invented the first network-based audio server (that I heard of, at least), NAS, which you'll see mentioned in quite a few comments here.
This was way before the term "thin client" was cool.
I know several schools that
use the m$ solution to that, maybe we could get X11 to do that also?
Microsoft is very much a johnnie-come-lately here. And they still haven't caught up. I believe they are still using the archaic notion of selling per-client access licenses.
I'm no x11 genius, but do the current audio servers run over x11, or is it something that needs to be compiled into kde apps, or
gnome apps?
They run alongside X11. Audio is generally supported at a library level. One such is libao, whose whole point is to abstract away various OS-specific audio output methods, including the various audio servers out there. Some applications seem to prefer to maintain their own audio plugins, effectively doing libao internally.
When a new audio server comes along, some applications will need a new plugin written, while others will continue to use libao and someone will write a libao plugin. It is even possible that existing sound servers like aRts will grow a means to chain to the new audio server, so that applications can continue to use aRts, albeit with higher latency and lower functionality than using the new server natively.
and can the x11 protocol be compressed?
Yes. There was the Low-Bandwidth X extension in the early 90s, but someone (Keith Packard?) investigated it recently and found that it doesn't work that well, so he implemented a new compression scheme a year or two ago. I can't be bothered to go chase down a link.
OK. I haven't looked at the code, but I've certainly heard that more than once. That doesn't rule out rplay, NAS, aRts, or other miscellanea like the HP-UX sound server, which (being based on DCE) is truly perverse for other reasons entirely.
2. network transparent sound (ala X)
Uh, that would be all of the above. Actually I'm not sure about ESD, but at least the others are all network-transparent.
3. tightly coupled video and audio (check out their page for the latency requirements)
Yes, that's the one reason I buy, aside from the obvious NIH.
4. cooperates with the X server:
can send audio data over a number of different transports, including CORE X
Yes, but how is this an advantage? The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care? The only reason they should is to get past / tunnel through a firewall, which can certainly be done other ways. NAS in particular makes this fairly straightforward.
To top it all off, I'm pretty sure it doesn't require X, and can be used for console apps as well.
So can any of these others. In practice, console apps often just open the local audio device because they assume you are sitting in front of the local console. But if a case could be made that any given user is likely to be at a remote terminal that happens to support NAS or one of the others but doesn't support X, console apps could adapt. (Indeed, libao-based apps, like ogg123, already have.)
See, it seems to me that you Linux guys are just trying to reinvent the wheel, here.
Of course we are. I don't see why this seems to surprise you, or what there is to ridicule about it. We reinvent the wheel because the existing wheel vendors maintain a hands-off policy and don't let us improve existing wheels. Some people don't enjoy the wheelwright business, but we do, so we hack on those wheels we're allowed to hack on, which is generally the ones we've invented ourselves.
The problems that you all complain about--
fast graphics, a good desktop environment, media tools, and so on-- have already been solved.
Not sufficiently. Fast graphics on OS X? Only if I have a certain type of computer from a certain vendor, purchased within a certain recent past. Good desktop environment? Very subjective - I prefer the minimalist approach myself and do most of my work in text mode anyway. Media tools? I don't see a deficiency in the Unix offerings, except in support for certain proprietary media formats like Sorensen Quicktime, which we have been told we aren't allowed to build.
The near-universal insistence on
using tools that are poor imitations at best can only be described as perverse.
Who is insisting on using tools that are poor imitations at best? And imitations of what? I picked a computing environment for a lot of criteria - not least of which is that I'm not boxed in to buying either hardware or software from any specific vendor, by the way - and I use whatever tools seem to fit my needs best, whether they be bought, downloaded or home-built.
Imitation is also not a bad thing. You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992? For that matter, is not all GUI-based software imitating the GUI-based software of the eighties that explored the bounds of the GUI paradigm and figured out how a raster-based system could be made as functional as the text-cell-based systems of its day? Innovation alongside imitation is powerful indeed. Innovation divorced from imitation, while sometimes interesting, is very rarely practical.
And back to vendor dependence: you seem to be content to sit at your computer and trust that Microsoft, Apple, Adobe and Macromedia will spoon-feed you what you need when you need it. I guess that's fine for you (and for that matter, for most computer users) but it's not enough for me.
Using SVG fonts
would remove the issue of patents surrounding TTF (which is basically the standard font format).
Maybe, maybe not. Certain useful techniques for encoding and rendering fonts are covered by patents - but it would take a more knowledgeable head than mine to say whether or not those would affect font encoding and rendering in SVG.
Anyway, if you want scalable, hinted fonts and are afraid of TrueType, you should be[*] using Type 1, a spec borrowed from Adobe Postscript. Type 1 fonts may or may not be under the shadow of the TrueType patents, but they fit your requirements every bit as well as SVG fonts.
[*] By "should be", of course, I mean "probably already are". Your X server has been rendering Type 1 fonts since about 1993.
Not everyone can read though. And you may argue that perhaps people who cannot read should not be using a computer.
Yes.
but
what about the visually impaired? Icons are a lot more visible than smaller text.
Ah, but what else is a lot more visible than smaller text?... wait for it... larger text!
And one couldn't miss a spinning icon or the like.
That's the whole point. We don't want to be bombarded with information we don't care about. It's distracting. So unless you think the UI designers will have an exact phase match with me with regards to my priorities of what I want to think about at any given moment, what is important enough to interrupt my train of thought and what isn't, then keep your animated ads^Wicons off my desktop.
Sheesh, next you're gonna give my icons access to my sound card. *shudders*
I find myself wishing for both more informational icons, and a keyboard-activated
zoom focus. The Mail icon shows you how much mail you've got, that's nice... but I want more info. It would be great to mouse over
the icon and have the connections/progress listed. Or, roll over the clock and have a calendar zoom out at you like a springloaded
folder... putting itself away when you roll away. This gives you a really high amount of information density in a small amount of
screen space.
You're describing a 1995 technique commonly known as "tooltips". Most modern graphics toolkits support them - maybe yours doesn't. Basically a small text box pops up under or beside an icon when you hover over it, and disappears when you move away.
The problem with using tooltips to convey extensive information is that the box obscures everything underneath it, so if you mouse over something without needing the extra information it just gets in the way and you find yourself probing around for a non-hot-spot. This is particularly heinous when the app designer starts "activating" the UI elements within your work area. For example, a CAD program I used to use pops up a many-line tooltip whenever you hover over a point, line, circle, etc., giving its whole curriculum vitae. Thankfully you can turn this horrible behavior off.
I suppose tooltips as a way of giving extended information (as opposed to giving a "hint" about what the icon does) could be useful if the pop-up box had a semi-transparent background or something. This ought to be possible in NT5, whose GDI supports background alpha, but I don't use Windows enough to know if it is implemented.
FYI, my day job involves running MRI scans on a VMS/VAX Gyroscan Intera workstation... This 64 bit architecture is the hottest
stuff around, for somebody who works with a VMS/VAX workstation...
Is this for real? Hey, it's your day job, not mine, but I thought the VAX was strictly 32-bit. Are you sure you're not confusing the VAX with the Alpha? They both run VMS, you know.
The difficulty is, because MRI looks at differential
angular momentum of hydrogen atoms to obtain it's pictures, it's got to calculate a Fourier wave analysis on each atom it vibrates.
Being able to run an algorithm with 64 bits means less data manipulation, higher resolution, faster scan times, and increased
diagnostic imaging power to the medical doctors.
Yeah, but isn't this stuff done in floating point? Floating point is 64-bit or better on most of platforms, including the much-maligned 387. Which is not to say Alpha isn't a great platform for floating point math - that's its strongest point, actually - but that has little to do with its overall 64-bitness.
(Apologies if MRI processing is done in integer math. In that case, a 64-bit CPU is indeed better suited to the task than a 32-bit CPU.)
If your operating system happens to use a flat memory model, like Linux does, this limits each process to 4GB total.
I thought it was Linux 2.2 that had the 4Gb memory limit? - I think it was 2Gb plus 2Gb actually, or 3 + 1. anyway, I'm pretty sure
I've seen 64Gb as a compile option for 2.4 kernels, back when I used to use it
OK, here's the story:
The 386 processor lets you refer to memory with a 32-bit address. This is good and useful and lets you specify any byte in a 4 GB range. This is continued up through the latest Xeon. This is known as a flat memory model in that you only have one address for each memory byte. The alternative, used in the 8086 / 186 / 286 "real mode" and many other (mostly older) CPU designs, is segmented addresses, where each memory location is addressed by a segment and an offset within the segment. In some cases you can optimise out the segment address by assuming it is the same as your "current" segment, however that may be defined. Segmented memory addressing is seen nowadays as needlessly complex for general computing.
So as to flat addressing: when you refer to a (in our case 32-bit) memory address, this address is usually not the physical address but a virtual address, which is looked up by the CPU automatically via page tables. These page tables and other associated machinery are set up and managed by the OS.
Now, note that when Intel added 64 GB support to the Pentium III, they didn't use classic "segmented addressing", because that would be really inconvenient for application programmers (and compiler writers) who are accustomed to the assumption that you can hold a memory pointer in a single CPU register - and general-purpose registers on x86 are all 32-bit. Instead, they instituted a 36-bit address space through page tables - the OS basically sets up a new type of page table scheme, so 32-bit virtual addresses in an application can refer to anything in a 64-GB range of physical memory.
So from the application standpoint, it still has a maximum of 4 GB of address space, less a certain amount of overhead for the OS. More than 4 GB at a time would require larger than 32-bit addresses, which would be a major compatibility hurdle.
So how is it useful to have 64 GB of memory if an application still only gets 4 GB at a time? Because if you have multiple processes, they can each have their own page tables which don't necessarily overlap. Indeed, the OS always keeps page tables separate between processes - that's how memory protection works, and why you can't access another process's memory without explicit arrangement.
If your application needs more than 4 GB of memory, but you don't want to invest in a real 64-bit CPU, you basically have to break up your app into multiple processes each of which can allocate its own pool of non-overlapping memory, and have the processes communicate as necessary via shared memory, message passing, the filesystem, or similar.
The other way to do it is to have the application do its own overlay management. The idea here is that the app knows it needs to access memory not in the current page table setup, so it issues a call to the OS to "swap out" the page tables regarding a particular region of its virtual address space in favor of another swath of physical memory. I believe this alternative is not currently implemented in Linux, but it may be soon. I say this on the basis of Jeff Dike's proposed extensions to support multiple address spaces per process - he wants this for User-Mode Linux, but I think it could potentially be useful for overlays as well.
Or you could run an operating system which doesn't allow code execution from the stack or data segments and has read-only
executable segments. That prevents buffer-overflow exploits, which is why OpenBSD will enforce it in the next release.
Now, I know I don't know what I'm talking about - I haven't even read Aleph One's "Fun and Profit" essay - but from what I've heard, this isn't really a solution, at least in Linux. Sure, it sounds attractive to prevent execution from the stack, but a couple years ago someone (Ted Ts'o, was it?) demonstrated that at least the most common class of stack-smashing vulnerability is possible to exploit without executing the stack directly. In other words, if we all applied Solar Designer's non-exec stack patch for Linux, the crackers of the world would take, say, a two-week vacation to learn the new technique and stop using the old, and then we'd be back to square one, with the same exploits as before. Only now we can't thunk to the stack for legitimate purposes.
Note that if you run Linux with Solar's patch, you are probably more secure, as the crackers of the world will target the rest of us. But this protection (similar to what you get by running Linux on non-i386 hardware) will disappear if and when the non-exec stack becomes the common case.
Of course, this may all be an architectural thing, or it may depend on something specific to Linux. Possibly a non-exec stack on OpenBSD really does solve potential problems. I'm just pointing out why the Linux kernel people aren't bothering with it.
Slashdot Mirror
Well, instead of one expensive cabinet you get N expensive cabinets. Each drive will have an IDE disk, an IDE controller talking to the firewire bus, and a case + power supply. (Well, I guess the power supply is optional, if your firewire cable provides power.)
It's anyone's guess whether this would in fact come out cheaper than a RAID enclosure with hot-swap IDE bays. The RAID controller, in the latter case, could still have a firewire interface, though 80 MHz LVD seems to be the popular thing nowadays.
As for "plug n play" - you don't want a RAID array to be easy to disassemble. Someone will unplug a drive by accident, and then the array degrades, and has to resync when you plug the drive back in. Hot-swap IDE enclosures are more than convenient enough for replacing actual failed drives - as one hopes this wouldn't be necessary more than once every few months ... right?
No, you read it right. Here's the thing. samba.org has a much larger and (well, at least back in the boom days) better-funded team than we do, so we can only concentrate on so much at a time. Printing just isn't a priority. It might work in samba-tng, in some cases (it is after all derived from samba.org code, which includes printing) but we don't pay much attention to it.
If you need your PDC to also be a print server, you should either (a) run samba-tng and samba.org on the same machine, on two separate IP addresses and netbios names (yes, this is a common and supported configuration), or (b) just use samba.org for your PDC, which in the past wasn't such a great idea but nowadays it is reported to be quite usable.
Heh. Good one. I might have to add that to the faq. Do you have a real name I can credit, or will Mr Coward have to do?
Oh, was that Jerry's idea? I've always wondered who came up with that one.
And no, we don't intend to start calling it Tango. (:
Well, it's vague at best. Mainly it's just a fork, with occasional code merging in both directions (though we (-tng) take quite a bit more from them (samba.org) than they do from us). Many things samba.org does better, a few things we probably do better, but then again some of the differences are just ... differences.
Sorry it's hard to give a more concrete reply - I don't know the exact capabilities of samba 3.0 alpha. I suppose abartlet (from samba.org) will give you a more complete answer, as is his habit. (:
(:
The name is historical. It was originally just another cvs branch in the main samba.org tree - and it had to be called something. The branch tag was SAMBA_TNG.
Suggestions welcome, I guess, but we probably won't take them. (:
The status page notes that NT trusting Samba-TNG works. What it doesn't mention is that the converse also works, but requires a certain amount of manual setup and fiddling. This is one thing we'd like to polish up for the next release. (:
(People's experiences? Sorry, not my department, I don't use trusts..)
obKarmaBonus: because I'm a samba-tng developer (:
Right. The other thing is, with LDAP support, samba-tng (and samba.org for that matter) has many of the internal advantages of Active Directory. Network-side, it still looks like NT4, but internally, you can manage it via LDAP rather than the crusty old tools.
For this reason, I personally don't see a lot of point in emulating a true Active Directory server. It just doesn't seem to buy all that much on Unix. On Win2k you have the whole world integrated into Active Directory - the DHCP server, the DNS server, dynamic DNS tying the two together, you name it. I think that's most of the value proposition of Active Directory, and on Unix the whole integration thing wouldn't be there anyway.
Years ago, when samba-tng was young and fresh, someone (can't remember who, I think Luke Howard was involved) tried to write an NT5-compatible LDAP backend. It was never finished, but the regular LDAP backend matured to the point where we don't feel we need the AD-compatible one. The difference was mainly in the LDAP schema, as I recall.
Mod parent up, cliche as that sounds. Andrew is on the Samba team and follows samba-tng as well.
I think the confusion came about because samba-tng used to be just another cvs branch at samba.org, and the plan was to merge the useful bits over to the head branch. I guess to some people that sounds like "releasing another version of samba-tng".
Hmmm - computer built into back of monitor...
keyboard folds up to cover the screen...
Ladies and Gentlemen, I give you -- the Osbourne 1!
(I swore I was getting off this bus ... oh well, one quick question, one quick answer.)
I thought I'd mentioned it once or thrice already. In fact, I'm sure I did. I find my high-res text mode more readable and easier on the eyes than any graphics mode I've seen so far. I guess you must think that's a "pink" thing. Well, I think your antialiased fonts are a "pink" thing too - they aren't more readable to me. Actually I generally can't tell much difference. (I'm told sub-pixel antialiasing makes a much bigger difference, but I don't have an LCD.) So between you and me, we still can't agree on what constitutes an objective, measurable and repeatable improvement in user experience. Your explanation is that I just don't get it. Mine is that such improvements are very few and far between, and have basically all been done by everyone years ago - what's left is eye candy and "pink" preferences that one hopes will work for more people than not.
I think the way you and I use computers is so far apart that you're having trouble imagining why I find so many of your gee-whiz innovations useless, boring or even negative. To you it is self-evident ("QED!") that having these features is unilaterally better than not having them. To me it's not. Again, I don't think we're ever going to agree on this. And again, I think I'll shut up now. (Oh - if you're planning to respond - can you please let at least one post go by without the patronising "ok if you don't want to discuss this, that's fine, your prerogative, feel free to keep your closed, illogical mind" line? It's not that I'm shying away from what I feel is an indefensible position; it's that AFAICS you and I have such a high phase mismatch that I very much doubt this is anything but a waste of both our time.)
You are failing to define "superior". You are letting the term "objectively better" rule by fiat: "xxx feature is useful because yyy, therefore it is objectively better than not having xxx." That doesn't take into account people like me for whom quite a few features in the "xxx" category are either unimportant or just plain undesirable.
Worse, you have a double standard. When I say "I like the way Linux works", I am calling up an aggregate image of features which provide benefits to me - lots of features, most of them too trivial even to mention, but adding up to an experience I want from a computer. Then you say, "Sorry, I'm not talking about user preferences." So therefore for the purpose of your definitions, my user comfort level is irrelevant. Yet, when you start talking about antialiased fonts, scalable UI elements, one-button mouse design that allegedly helps prevent RSI, etc., then suddenly user comfort is considered an objective measure of utility.
You can't have it both ways. You can either concede that many computing environments (Linux included) can provide the same basic feature set for people to get their work done, differing only in matters of "style" and "ease of use" and "comfort" and "efficiency of interfaces" ... or you can claim that personal preference does play a role in whether one environment can be considered "better" or "worse" than another ... thus making the whole thing at least reasonably subjective.
But so long as you continue to say "This is obviously always better than that, QED", then I have nothing left to say to you. Go ahead and get in a last word (and yes, I'll read it), but I think I'm done here.
There's nothing wrong with my computer. Many people would probably be quite happy with the 1600x1200 graphics window I bring up here on occasion. I am not. And I haven't yet seen a computer whose graphics output can match my high-res text mode for readability and general comfort. Maybe an LCD would eliminate the difference, but nothing I've seen on a CRT does.
And I'm saying that for a question like that, there is no objective answer, so you're chasing after the wind and (intentionally or otherwise) manufacturing dogma which you expect to be received as from on high.
A long time ago I read an article in, oh, must have been BYTE magazine, and the author made the point that everything he uses a computer for, he used to do without a computer - write letters, play games, crunch numbers, draw pictures, etc. The computer just made his tasks better, faster, more fun, but didn't actually change the list of things he did in life.
As far as I'm concerned, a similar argument applies to the computing platforms of today. They can all do the basic things people need out of a computer, but any given OS might accomplish certain tasks with more ease and style than its competitors.
Unfortunately for your argument, measuring ease and style is horribly subjective, not at all suited to your vocabulary of "obviously" and "QED".
Back to me and my personal computer, if you insist on calling it that. Most of the things Linux does, I could technically get done on other OSes such as OS X or even Windows XP - thus the reason I can't make a very convincing list of bullet points. But to say those are "better" for the task than Linux is to ignore the whole factor of user preference. The fact is (and now we're getting objective: this is a fact), I like how my Linux box works, a lot better than I like how Windows XP works. (OS X is somewhere in between, thanks largely to its Unix underpinnings.) I don't see why I should care if The International Twirlip of the Mists Standards Body declares that my expectations for how a computer should behave are obsolete and stupid and that I need to be forcefully re-educated in the Scripture According to Steve Jobs for the good of humanity and the gene pool.
If you think about it, most of the distinguishing features between different computing platforms nowadays are matters of style, not substance. Anti-aliased fonts? Pure style - nobody actually needs them, but to some people they look nicer. Vector-based icons? (The point of this story, in case we've forgotten.) Pure style, nobody needs to scale icons on the fly, it just looks nifty and arguably improves your UI reaction times. The "you've got mail" wave file when you start AOL? Pure style. (Negative, if anything, but hey, whatever.) Pretty, "cluelessness-resistant" OS install process? Pure style - any OS that ever needs to be reinstalled, short of total hard drive failure / replacement, is hopelessly buggy and shouldn't be considered as a contender for best-of-breed anyway. A HIG that does its level best to pretend the second mouse button never happened? Pure style - some people swear by it, others (including of course me) find it horribly constricting.
Why not? Because I have tried both ways and I prefer the one, dangit. (Same reason some people use anti-aliased or LCD sub-pixel font rendering.) Because, for almost every graphics card I've ever used[*], the text modes look nicer and are easier on my eyes - and a lot faster to render, switch to/from, and update. And, since the majority of my screen time is spent doing things that don't need a GUI, I really prefer to switch to graphics mode only when necessary.
[*] Yes, there are a couple of unfortunate exceptions. On certain modern graphics chips, VGA text modes are a mere afterthought and don't do the card justice. I try to avoid those cards (ATI, mainly).
What's that you say? I should try a higher-spec monitor? A nicer graphics card? A faster CPU? Nope, remember, we're talking about the computer I've got now. Spending more money to run a Red Queen's Race back to the status quo isn't part of the deal. (Except spending money to buy Windows XP, I guess you would say.)
What makes you think I'm running a "personal computer"? It happens that the hardware I own is marketed as such, but I consider it a development workstation, file server, etc. I think the question of whether Windows XP or Mac OS X are "better" for certain functions depends on how you define these functions. You seem to lump every computer user into a single "personal computer" profile. If you allow this profile to be broad enough, sure it fits. But then, with a broad enough profile, you can't credibly claim that XP and OS X are the best of breed. You're treading a rather thin line of semantics here.
And neither does XP, with 64 MB of RAM. I'm sure it will boot up, but I expect the combination of slow CPU and (relatively) low memory will cause it to run slowly enough not to be considered "usable" by most people.
To put it in terms you would understand: I'm talking about hardware roughly on par with an early PowerPC 604: a first- or second-generation Powermac. Would OS X run on those, and if so, would it be fast enough to be usable? I have heard that a G3 is considered the minimum "sane" configuration - is that true?
(I don't mean to imply the computer I'm using right now is the Pentium 166. It's actually an early Pentium 4. My P-166 is in the next room, headless, acting as a file and web server. That was my previous desktop machine, though.)
Yes, by "config option" I meant "preference control". I didn't mean a cryptic compile flag, or hand-editing a config file. I meant a check box somewhere in a Preferences dialog.
Right, so it is. I haven't used Safari. I didn't know it actually lacked the ability to suppress load images. I also didn't know they had replaced the "spinner" (which my browser also does not have). But you have still admitted that it has many features not invented on the spot, like the ability to follow links by clicking on them, or scroll bars to let you display a document larger than your screen. (You didn't admit to having scroll bars, actually - I'm making another assumption here. I rest assured that you will call me on it if necessary.) It did not burst fully formed from the head of Zeus. Nor did most (dare I say all?) other software.
You called me on it. I hadn't actually checked - I just remember reading somewhere (slashdot?) that Apple was planning to release it as open source. Now I see that while its key components are open-source, the browser shell itself possibly isn't. (The exact difference between Safari and WebCore is not clear to me.)
That's silly. You can't go by feature count. Things that are important to me aren't to you, and vice versa. Some features are available of many platforms but are significantly harder / uglier / more cumbersome on one than on another. (Yes, that street runs two ways, too.) What features are worth counting and what ones aren't would be subject to debate. So, I'll just concede from the outset that your OS has more bullet points of things important to the Average Computer User, by which we mean a standard deviation or two from the average end-user desktop peon.
Also it is not obvious what constitutes a unique feature. A lot of Unix software can be built for Darwin, but many Mac users wouldn't consider this software as "available" unless it comes in prepackaged form. (Of course, a lot of this software wouldn't be considered necessary or relevant for the standard deviation of computer users.)
Finally there is the difficulty that I don't know for sure that certain features plain can't be had on OS X. The one I'm thinking of right now is having about ten 144x72-cell text mode "virtual consoles" to switch between at the touch of a hotkey. I don't know if OS X does text consoles at all, but I suppose it might. (No, drawing a text window in graphics mode does not count.)
You must be confusing me with someone else. I've never tried to maintain that what I write is better than anything else out there. At most I strive to build something that is better for specific purposes than any other free software out there. If it's also better than proprietary alternatives, great.
Really? How can this be? As far as I know, we have never met, so I find it hard to believe you have any idea what my needs are. How can it be blindingly obvious that either Windows XP or Mac OS X would fit my needs better than the system I'm typing on now?
I guess you're making the assumption that every computer user wants basically the same thing out of a computer. Apple and Microsoft both proceed on this assumption, and for one or two standard deviations of people, it works.
For a simple yet real-world example of where you are wrong: tell me, which of Windows XP or Mac OS X should I run on my Pentium 166 with its 64 MB of RAM? (Well, I did eventually upgrade to 128 MB, but still.)
How about features like a <Back> button, or an address bar, or pull-down menus, or hyperlinks that you activate by clicking on them? What about an animated graphic ("spinner") whose animation shows that a page has not completed loading? What about a config option for not loading images, or disabling Java? I have never used Safari, but I'm willing to bet that it has all of these thoroughly non-innovative features.
My point isn't that $BROWSER_OF_THE_MONTH has no new features. Most software has at least one unique feature. Even open-source software, which you seem to dismiss sight-unseen as completely reactive. (Oh, wait - Safari is open-source too. I guess you only think open-source software for Linux is non-innovative, then.) My point, and you snipped it, was that you really can't build software ex nihilo. If you write something that doesn't in the least resemble anything that has come before, it may be innovative, but it will most likely be useless as well.
No, the bottom line is that my computer works better than yours.
Oops, unprovable statement. And not only subjective, but even more elitist than I have come to expect from Mac users, if you'll excuse the ad hominem.
Uh, why? What problems would that solve?
I'm not being flippant. X has served very well in a wide variety of contexts, due to and despite its client/server architecture.
You're describing 10 years ago: X terminals were quite popular in the early 90s. These are typically diskless, and run via a combination of firmware and an OS downloaded via TFTP or MOS at boot. They are small and have very quiet, if any, fans. Several of the big iron Unix vendors sold X terminals, but NCD carved out probably the biggest market share. (And yes, you can play games over them - Netrek has a full-screen play area yet seems to run fine over 10 Mbit or worse. Today's expectations of full-motion video quality graphics is another matter, though.) NCD invented the first network-based audio server (that I heard of, at least), NAS, which you'll see mentioned in quite a few comments here.
This was way before the term "thin client" was cool.
Microsoft is very much a johnnie-come-lately here. And they still haven't caught up. I believe they are still using the archaic notion of selling per-client access licenses.
They run alongside X11. Audio is generally supported at a library level. One such is libao, whose whole point is to abstract away various OS-specific audio output methods, including the various audio servers out there. Some applications seem to prefer to maintain their own audio plugins, effectively doing libao internally.
When a new audio server comes along, some applications will need a new plugin written, while others will continue to use libao and someone will write a libao plugin. It is even possible that existing sound servers like aRts will grow a means to chain to the new audio server, so that applications can continue to use aRts, albeit with higher latency and lower functionality than using the new server natively.
Yes. There was the Low-Bandwidth X extension in the early 90s, but someone (Keith Packard?) investigated it recently and found that it doesn't work that well, so he implemented a new compression scheme a year or two ago. I can't be bothered to go chase down a link.
OK. I haven't looked at the code, but I've certainly heard that more than once. That doesn't rule out rplay, NAS, aRts, or other miscellanea like the HP-UX sound server, which (being based on DCE) is truly perverse for other reasons entirely.
Uh, that would be all of the above. Actually I'm not sure about ESD, but at least the others are all network-transparent.
Yes, that's the one reason I buy, aside from the obvious NIH.
Yes, but how is this an advantage? The exact transport mechanism is a library implementation detail - why should the end user or even the application developer care? The only reason they should is to get past / tunnel through a firewall, which can certainly be done other ways. NAS in particular makes this fairly straightforward.
So can any of these others. In practice, console apps often just open the local audio device because they assume you are sitting in front of the local console. But if a case could be made that any given user is likely to be at a remote terminal that happens to support NAS or one of the others but doesn't support X, console apps could adapt. (Indeed, libao-based apps, like ogg123, already have.)
Of course we are. I don't see why this seems to surprise you, or what there is to ridicule about it. We reinvent the wheel because the existing wheel vendors maintain a hands-off policy and don't let us improve existing wheels. Some people don't enjoy the wheelwright business, but we do, so we hack on those wheels we're allowed to hack on, which is generally the ones we've invented ourselves.
Not sufficiently. Fast graphics on OS X? Only if I have a certain type of computer from a certain vendor, purchased within a certain recent past. Good desktop environment? Very subjective - I prefer the minimalist approach myself and do most of my work in text mode anyway. Media tools? I don't see a deficiency in the Unix offerings, except in support for certain proprietary media formats like Sorensen Quicktime, which we have been told we aren't allowed to build.
Who is insisting on using tools that are poor imitations at best? And imitations of what? I picked a computing environment for a lot of criteria - not least of which is that I'm not boxed in to buying either hardware or software from any specific vendor, by the way - and I use whatever tools seem to fit my needs best, whether they be bought, downloaded or home-built.
Imitation is also not a bad thing. You mention Safari - is it not an imitation of the many web browsers that have come and gone since 1992? For that matter, is not all GUI-based software imitating the GUI-based software of the eighties that explored the bounds of the GUI paradigm and figured out how a raster-based system could be made as functional as the text-cell-based systems of its day? Innovation alongside imitation is powerful indeed. Innovation divorced from imitation, while sometimes interesting, is very rarely practical.
And back to vendor dependence: you seem to be content to sit at your computer and trust that Microsoft, Apple, Adobe and Macromedia will spoon-feed you what you need when you need it. I guess that's fine for you (and for that matter, for most computer users) but it's not enough for me.
Maybe, maybe not. Certain useful techniques for encoding and rendering fonts are covered by patents - but it would take a more knowledgeable head than mine to say whether or not those would affect font encoding and rendering in SVG.
Anyway, if you want scalable, hinted fonts and are afraid of TrueType, you should be[*] using Type 1, a spec borrowed from Adobe Postscript. Type 1 fonts may or may not be under the shadow of the TrueType patents, but they fit your requirements every bit as well as SVG fonts.
[*] By "should be", of course, I mean "probably already are". Your X server has been rendering Type 1 fonts since about 1993.
Yes.
Ah, but what else is a lot more visible than smaller text? ... wait for it ... larger text!
That's the whole point. We don't want to be bombarded with information we don't care about. It's distracting. So unless you think the UI designers will have an exact phase match with me with regards to my priorities of what I want to think about at any given moment, what is important enough to interrupt my train of thought and what isn't, then keep your animated ads^Wicons off my desktop.
Sheesh, next you're gonna give my icons access to my sound card. *shudders*
You're describing a 1995 technique commonly known as "tooltips". Most modern graphics toolkits support them - maybe yours doesn't. Basically a small text box pops up under or beside an icon when you hover over it, and disappears when you move away.
The problem with using tooltips to convey extensive information is that the box obscures everything underneath it, so if you mouse over something without needing the extra information it just gets in the way and you find yourself probing around for a non-hot-spot. This is particularly heinous when the app designer starts "activating" the UI elements within your work area. For example, a CAD program I used to use pops up a many-line tooltip whenever you hover over a point, line, circle, etc., giving its whole curriculum vitae. Thankfully you can turn this horrible behavior off.
I suppose tooltips as a way of giving extended information (as opposed to giving a "hint" about what the icon does) could be useful if the pop-up box had a semi-transparent background or something. This ought to be possible in NT5, whose GDI supports background alpha, but I don't use Windows enough to know if it is implemented.
Is this for real? Hey, it's your day job, not mine, but I thought the VAX was strictly 32-bit. Are you sure you're not confusing the VAX with the Alpha? They both run VMS, you know.
Yeah, but isn't this stuff done in floating point? Floating point is 64-bit or better on most of platforms, including the much-maligned 387. Which is not to say Alpha isn't a great platform for floating point math - that's its strongest point, actually - but that has little to do with its overall 64-bitness.
(Apologies if MRI processing is done in integer math. In that case, a 64-bit CPU is indeed better suited to the task than a 32-bit CPU.)
OK, here's the story:
The 386 processor lets you refer to memory with a 32-bit address. This is good and useful and lets you specify any byte in a 4 GB range. This is continued up through the latest Xeon. This is known as a flat memory model in that you only have one address for each memory byte. The alternative, used in the 8086 / 186 / 286 "real mode" and many other (mostly older) CPU designs, is segmented addresses, where each memory location is addressed by a segment and an offset within the segment. In some cases you can optimise out the segment address by assuming it is the same as your "current" segment, however that may be defined. Segmented memory addressing is seen nowadays as needlessly complex for general computing.
So as to flat addressing: when you refer to a (in our case 32-bit) memory address, this address is usually not the physical address but a virtual address, which is looked up by the CPU automatically via page tables. These page tables and other associated machinery are set up and managed by the OS.
Now, note that when Intel added 64 GB support to the Pentium III, they didn't use classic "segmented addressing", because that would be really inconvenient for application programmers (and compiler writers) who are accustomed to the assumption that you can hold a memory pointer in a single CPU register - and general-purpose registers on x86 are all 32-bit. Instead, they instituted a 36-bit address space through page tables - the OS basically sets up a new type of page table scheme, so 32-bit virtual addresses in an application can refer to anything in a 64-GB range of physical memory.
So from the application standpoint, it still has a maximum of 4 GB of address space, less a certain amount of overhead for the OS. More than 4 GB at a time would require larger than 32-bit addresses, which would be a major compatibility hurdle.
So how is it useful to have 64 GB of memory if an application still only gets 4 GB at a time? Because if you have multiple processes, they can each have their own page tables which don't necessarily overlap. Indeed, the OS always keeps page tables separate between processes - that's how memory protection works, and why you can't access another process's memory without explicit arrangement.
If your application needs more than 4 GB of memory, but you don't want to invest in a real 64-bit CPU, you basically have to break up your app into multiple processes each of which can allocate its own pool of non-overlapping memory, and have the processes communicate as necessary via shared memory, message passing, the filesystem, or similar.
The other way to do it is to have the application do its own overlay management. The idea here is that the app knows it needs to access memory not in the current page table setup, so it issues a call to the OS to "swap out" the page tables regarding a particular region of its virtual address space in favor of another swath of physical memory. I believe this alternative is not currently implemented in Linux, but it may be soon. I say this on the basis of Jeff Dike's proposed extensions to support multiple address spaces per process - he wants this for User-Mode Linux, but I think it could potentially be useful for overlays as well.
Now, I know I don't know what I'm talking about - I haven't even read Aleph One's "Fun and Profit" essay - but from what I've heard, this isn't really a solution, at least in Linux. Sure, it sounds attractive to prevent execution from the stack, but a couple years ago someone (Ted Ts'o, was it?) demonstrated that at least the most common class of stack-smashing vulnerability is possible to exploit without executing the stack directly. In other words, if we all applied Solar Designer's non-exec stack patch for Linux, the crackers of the world would take, say, a two-week vacation to learn the new technique and stop using the old, and then we'd be back to square one, with the same exploits as before. Only now we can't thunk to the stack for legitimate purposes.
Note that if you run Linux with Solar's patch, you are probably more secure, as the crackers of the world will target the rest of us. But this protection (similar to what you get by running Linux on non-i386 hardware) will disappear if and when the non-exec stack becomes the common case.
Of course, this may all be an architectural thing, or it may depend on something specific to Linux. Possibly a non-exec stack on OpenBSD really does solve potential problems. I'm just pointing out why the Linux kernel people aren't bothering with it.