"My knowledge of Linux is sketchy so perhaps there are equivalents to this in Linux-land?"
The basic Linux equivilent would be a statically-compiled executable. Such binaries don't use shared libraries at all; they contain everything in a single file. Of course, that file is often huge compared to the same program dynamically linked.
This doesn't so much solve the binary compatability problem as bypass it. When you bring everything with you, you don't have to worry about what others provide.
The downside, aside from the size issue, is that when a library is upgraded (either for bug fixes or nominally backwards-compatible enhancements), the application doesn't notice. You have to rebuild the app and redistribute to gain the benefits of the updated library.
"You said binary compatibility is hard, but isn't that really more true on Linux than elsewhere (because of its origins and the emphasis on compiling from source and installing libraries in different locations)?"
Not exactly. Binary compatability presents the same problems, regardless of platform. But it is certainly true that the effects of binary compatability being hard are seen more on Linux.
The biggest reason binary compatability looms large in the land of Linux is that Linux doesn't come from a single person or organization. Each distro has their own ideas and their own set of options. Contrast that to the world of Macintosh, where Apple has always excercised tight control over all aspects of the platform. That helps keep everything working together. You may have less choice and less variety, but what you have feels more closely knit together.
Like most things in life, there's a trade-off involved.
"Hopefully that's not also Linux flamebait..."
That was directed at the OP's remarks about how there's no point about talking about Linux desktops.
"I'm not trolling, because everything I've said is true..."
Well, one can say nothing but the "truth" and still be looking to incite an argument, but that's another discussion.
Let's look at a few things here.
In terms of actually running a program, I can take a very old Linux binary, statically linked, and run it on my modern Linux distro (assuming it doesn't care about kernel functionality). Same with Windows. The executable format itself is still well supported. It's the shared libraries that are the issue.
On either OS, if I try to run a program linked against some library, and I don't have that library, I will get some kind of dynamic linker/loader error. Linux or Windows. Windows isn't magic here.
Now, on Linux, this is often caught at install time by a package manager. Failing that, the error will be from the shared object loader. In both cases, the computer is doing what it is supposed to: Tell you that you don't have all the pieces.
On Windows, it is usually up to an "install program" to make sure all required shared libraries (DLLs) are present, and install them if not. From what I've seen, most install programs simply dump the DLLs *they* want in the Windows System directory. It is assumed backwards compatability is always perfect, if the question arises at all.
That's great when it works, I suppose. The problem is also causes all sorts of weird failures and conflicts, of the type I described previously. It makes configuration management an absolute nightmare. Hence the whole "clean install" practice in Windows-land, where blowing away the OS and installing from scratch is considered normal. Blech.
I've certainly encountered no end of software that cares about this or that dependency on Windows. Some random examples:
- Adobe Reader 7 won't install on Win98 - The latest Symantec Anti-Virus requires a root certificate update from Microsoft - Countless things that require Internet Explorer 6 - Office 2003 requires Windows 2000 or later - Exchange 2000 won't work on Windows 2003 - QuickBooks hates Windows XP Service Pack 2
And so on. I don't find Windows nearly the compatability dream you find it to be. I suspect you're content just because your granny only wants one "special" program, so you don't have to worry about how said program clobbers all the shared libraries that other programs care about.
Now, there are some differences in the "community" of Linux vs Windows. As already mentioned, Windows programs tend to include many of their dependencies with the install package. Not so much on Linux. I suspect this is largely due to the fact that so much "freely available" software is used on Linux; you can just download everything and don't have to worry about license fees.
Linux does tend to change more rapidlly then Windows. This has obvious benefits, but it does mean the "churn" in package pools can be an issue. Indeed, that's what kicked this Slashdot article off. Of course, when Microsoft decrees the version of Windows you have to be "dead", then you're equally stuck. Getting support for 98 these days isn't a picnic, either.
I'm am most assuredly not saying Linux is immune to the problems I describe; quite the opposite. But I am saying that Windows is not immune.
"First, let's get out in the open what you think I'm asking for and then what I'm actually asking for. "
Well, that's fair. I ass-umed you were yet another person whining about how your consumer Internet feed is just oh-so-much-money, when compared to the alternatives, it's one-tenth the price or better. I get a lot of those, and as somebody who has worked in network operations in the past, most end-users don't appreciate just how expensive some of this stuff is. I jumped to a false conclusion there. My apologies.
"I want the always-on-ness of cable or DSL internet instead of dialup, but don't care about the huge bandwidth increase. "
Well, that's a far more reasonable desire, and one I can understand (even if I don't fall into the category myself). Unfortunately, Internet connection bandwidth is not a truely was a fungible commodity. The big cost (as I ranted about) is in all the physical infrastructure. Once you've got all *that* in place, the difference between a 500 kilobit circuit and a 1000 kilobit circuit tends to be one of software configuration. In other words, both cost almost exactly the same to provide. Unfortunate for people such as yourself.
Based on the replies I'm seeing, it appears I failed to make my point clearly.
As I said, PDF is great when you need visual consistency. When you actually something to look the same everywhere. Obviously, if you're distributing electronic versions of dead-tree forms, you need that. (I might argue that it would be better to just implement an electronic form submission system, but that's not always a realistic solution.) PDF is useful here. That's not what I was getting at.
However (and this was the point I was trying to make), people and organizations get far too attached to the appearance of a document, when they should be focused on the content. It's the substance, and not the form, that counts. That's my major point. Distributing, say, a bank statement in PDF to make it "look the same" as a "real" bank statement is inherently silly. What makes the PDF more "real" then an HTML presentation? What does having the same format of another document make something I print myself "more real"?
Look at stlhawkeye's reply, where he says the HTML version of his bank statement wasn't accepted. Now, that justifies a demand for his bank to make "look alike" data available as a PDF, but let's look beyond that. Why the hell does anyone care the source of the print out was HTML? It's not like there's a universal standard for bank statements. And simply having a bank statement is not the point. The finance company (or whoever) doesn't want proof that stlhawkeye has a bank statement -- they want evidence of financial credibility. That's independent of format and presentation. How it looks doesn't matter. Yet they make an issue of it. That's bad.
As for those who complain that HTML does not look the same everywhere: That's the point. HTML is supposed to look different everywhere. It's a feature, not a bug. An HTML document can be presented one way on screen, another way printed on a laser printer, another way on a character-only line printer, another on a cell phone display, another way as audible voice from a speech synth, and so on. Done right, you could have the computer in your car read you your bank statement on the way to work.
This concept, which HTML embraces, opens up huge potential in information systems. Yet things like "Best viewed with so-and-so", or "Download SecretSoft's plug-in", are killing this off. That's bad.
(And, yes, obviously it was George Orwell, not Orson Wells, who wrote Animal Farm. Total brain fart there. I have placed a virtual brown paper bag on my head. Etc, etc.)
"Adobe certainly will be inserting their SVG magic into the Macromedia environment. "
What, exactly, makes you so sure? You got a portal to the future you're not telling us about?
Adobe *loves* the idea of lock-in. Remember, this is the company that had someone *arrested* for reverse-engineering Adobe's eBook format just so people could view and make backups of their files. (See http://www.freesklyarov.org/ for details.)
So given the choice between something like SVG, which Adobe doesn't totally control, and Flash, which (assuming this goes through) Adobe will own, lock, stock, and barrel, I strongly suspect they will go for the latter.
"I like PDFs, it allows me to download my tax statement, bank statements, government forms, and all kinds of other stuff that I used to have to fork over $3 to some government agency to get ahold of."
Yah, it isn't like you can do that with open standards like PNG, JPEG, HTML, or even plain text. They obviously needed a semi-closed, really bloated, high-resolution, stuck-on-the-idea-of-dead-trees system to give you your bank statement.
/SARCASM
It really irritates me when I go to obtain some basic information (like my bank account details or some product info) and the web server insists on shoving a PDF down my throat. HTML would be so much better: Smaller, quicker, open, no special software, device and software independent. Why PDF?
PDF (and things like it) are great when you actually need the rendered output to be the same everywhere. For example, if one is sending proofs of a marketing brochure around, one wants consistancy. But somehow Adobe has duped a bunch of people into thinking it is vital at all times. (Hence the Orson Wells reference in my subject.)
So many other things use PDF (or at least the PDF mindset of "It has to look the same everywhere") when there is no need. The web was *designed and intended* to look different depending on what the user wanted. That's a good thing. It means you, as the content producer, *don't have to worry about* how it might look. Computer, cell phone, printed page, direct mind-link to my brain -- it was all supposed to be automatic.
But too many PHB's and similar types come up with things like "I want this five pixels to the left", not understanding that not everybody has their (the PHB's) computer.
Content producers really need to stop worrying so much about how somebody, somewhere, might possibly have some influence over the presentation of their work.
"Uh, so when are they going to start offering this reasonable price you speak of?"
Dude, do you have any idea what it costs for the sort of connection you think you deserve? You're talking about a dedicated circuit. Your typical cost for a megabit of PVC is gonna be at least $400 or $500 a month, even in a nice urban area with lots of coverage. In rural areas, try $1000 or $1500 a month. For a true dedicated leased line, they charge you per foot from the CO.
Now, granted, the telcos price structure is hugely unfair, but even so, providing dedicated, carrier-class service is freaking expensive. Outside plant, CO infrastructure, power, backup power, cooling, network equipment, monitoring, field service staff and equipment, all the pieces needed to provide an SLA -- they cost real money.
Getting a megabit of "consumer grade" Internet feed for $50 a month or whatever is a freaking bargin. I for one am glad to have it.
Yes, that must be the reason MS Windows is (for most application) binary compatible FOR ONLY PAST TEN-TO-FIFTEEN YEARS!!
I'm guessing you're trolling, but you do touch on some points in my original post worth expanding upon. As I said, Windows has these issues, too.
Have you ever noticed that the more software gets installed on Windows, the more likely it is to have trouble? There are a number of reasons for that, but the biggest is known colloquially as "DLL Hell". As I said, Windows only allows you to have one version of a shared library installed at a time. So you get all these crazy dependencies where program A requires library version X, but program B requires library version Y, so you can't have them both on the same system at the same time.
My personal favorite example of this is how if you install Microsoft Outlook 2000 (the Exchange client) on your Exchange 2000 server, you will cause the Information Store to stop working until you replace a certain set of DLLs (and thus break Outlook). Fifteen years of binary compatibility? Hell, Microsoft can't get it to work in the same year!
The ability to have the system load and run-time link an executable image does not mean that binary compatability issues don't exist. Linux has had that all along, too. But in Windows, you don't even get the warnings that RPM (or whatever) gives you. You just get screwball behavior.
This is why in Microsoft's ".NET Framework". Microsoft has implemented to so-called "managed code assemblies", which reference the specific libraries they were built against, and call those versions in. Of course, this is a radical departure to how Windows manages shared library and run-time linking. Everything has to be restructured to make use of it. I'm not sure how that qualifies as "compatible", either.
Microsoft isn't exempt from this reality anymore then Linux or BSD is.
I'm not going to bother responding to the Linux flame-bait.
The problem is simply that binary compatibility is hard.
Easy enough; it's the implications that are subtle. Like that building a key system library with different options makes it a different package. That changing a key system library thus changes the entire configuration management scenario. That a package that has different subcomponents, each with their own dependencies, is a package that depends on all of them. That auto-built dependencies tend to be even pickier then the real ones. That packages are only as good as their (builder supplied) metadata. And so on and so forth.
There must be something about this that is either hard to comprehend, or hard to accept. It gives a lot of RPM users trouble, it gives Debian users a sense of superiority, it's what makes BSD ports work so well, and it's largely responsible for making Microsoft Windows the unholy mess that it is. Clearly, there's a disconnect here.
Take a look at some common misconceptions in the software world.
It appears a disproportionate number of Debian users carry a false sense of superiority about their package tools, when what really makes Debian win is the size of the distribution package pool. Specifically, that having such a large pool of configured, compiled, and tested packages readily available via "apt-get install foo" leads a lot of Debian people into think APT is somehow magic.
Likewise, RPM properly saying "I don't think you have the pieces you need for this to work" leads so many people into thinking that RPM *causes* "dependency hell". RPM simply reports it. YUM (and things like it) can help you with it. But the nature of binary software itself is what *causes* dependency hell.
And the fact that BSD ports downloads, configures, builds, and installs all specified components *from source* leads BSD bigots into thinking that the BSD ports packagers must be doing a much better job then Red Hat or Debian packagers. Rather, they just bypass the problem of binary compatability.
And, again, this is also largely responsible for why Windoze sucks so much. When everything is a binary which you have no source for, and no two packages share information on what is being installed, and you can only install one version of any given library at once time -- then, yah, it's a minor kind of miracle the thing ever works at all.
Larry Niven, one of my favorite authors, has spoken eloquently on why we should have a space program. For a nice (but subtle) treatment of the pragmatic concepts, read his short story "At the Bottom of a Hole". But he has a better, and shorter, statement on the situation:
"The dinosaurs became extinct because they didn't have a space program."
This is technically off-topic, I suppose, but I can't think of any other place to post this, and it's kinda related. Moderators can make the final decision, I suppose.
Anyway: I stumbled across a weird Google behavior the other day. If you do a regular Google for "read news" you get some weird results at the top of the results page:
Read on News: 4 According to http://www.esp-software.com/index.php?option=conte nt&task=view&id=3&Itemid=1 - More sources »
Anyone have any idea what that is? New feature still in development? Old feature never finished? Documented feature I'm being stupid about? Ordinary bug?
Inquiring minds want to know. Well, not really, but Slashdot readers might. Well, me, anyway.
The fundamental difference between stack and heap is how they grow.
The program stack is just that: A stack of data. For each new subroutine call, storage needed by that subroutine is allocated ("pushed") on the top of the stack. When the subroutine returns, the the storage is released ("popped"). In every system I know of, stack is allocated automatically (typically using local variable declarations).
Heap allocation can be random. Programs allocate heap when they need it and release it when they are done, in any order they wish. In classic systems like C and Pascal, heap management needs to be done by the programmer. You have to malloc() and free() manually, for example. In systems like Java or Python, you just create new objects, and the system garbage-collects them away for you.
Typically, the stack is allocated starting from low memory (address 0 or some other base) and grows up, while the heap is allocated starting at high memory (top of memory or top of virtual segment) and grows down. If the two meet (stack/heap collision), you've run out of memory (or address space) and are very hosed.
You generally have a stack and a heap even on single-task, non-memory-managed microsystems, such as MS-DOS. There's no sharing of the heap between processes, but you still have a stack and a heap.
On many (most?) Unix systems: As stack and heap grow, the process requests memory from the kernel when needed to grow either stack or heap, and the kernel allocates memory from the free pool to satisfy that request. However, there is no mechanism for the process to return storage to the kernel free pool.
On Windoze, I believe the heap is dynamic amoung all processes, as you describe.
"this sort of malware would not be able to do anaweful lot except perhaps create some files and run some processes as a user"
That's all a lot of the worst worms to hit the 'net have done. Many of these mass-mailing worms that have overloaded networks and crashed servers did nothing more then read the user's address book and then mail copies of themselves to everyone. You don't need root for that. You barely need a filesystem.
There's also the fact that, ultimately, people want to protect their data. Protecting the system privilage level is just a means to that end. If the trojan program can read and write all the user's data, then the game is largely over anyway, for your typical single-user home system. The fact that the operating system is still protected is almost irrelivant.
"In contrast, dialog boxes are much rarer on Macs, and they are written much more clearly, and are more useful. They encourage the user to pay attention to them."
I might be willing to buy that, if it wasn't for the fact that the vast majority of software isn't written by Microsoft or Apple. (Both companies provide only general purpose software. If it was just the Microsoft or Apple apps we had to worry about, switching platforms would be a lot easier.) Bad software exists on every platform I've ever used. I've seen buggy, insecure, poorly-documented, hard-to-use software on the Mac. And on Linux. And, of course, on 'doze. I've seen stupid users on all of the above.
More importantly, I've seen stupid users nowhere near a computer. I see them every time I get on the highway. I see them in the food store buying "Lite" versions of food that are just as laden with fat, sugar, and other crap as the regular versions. I see them on the news every night. I read about them in history books. Nothing in my experience has given me any reason to believe that stupid people should be any less common for computer users than the rest of humanity.
FWIW, while I use Macs fairly infrequently, I've seen plenty of stupid dialogs on the Mac. I question your assertion that such are less common on the Mac. Do I have a statistical analysis? No. But I suspect you don't either. If you do, I'd love to see it. (Seriously.)
"I'm sure you'll give them helpful advice without being snotty and condescending."
I generally ignore anonymous trolls, but I did want to respond to this bit, for clarity: I was being condescending, yes. However, it was more at the situation and at the general stupidity of the human race, myself included. Some of it was also directed at the OP and their incorrect belief that technology can solve behavioral problems. I'm not condescending to my paying customers; they pay me. Slashdot gets my drivel for free. Additionally, I always take care to educate and inform my users. It's the ones that persist in doing the wrong thing despite repeated attempts at behavior-modification that annoy me.
Strictly speaking, "virtual memory" means the addresses seen by the running code are translated to physical addresses (by the MMU). Thus, the code sees virtual addresses.
"Memory protection" describes the feature where the running code is prevented from accessing certain parts of memory, for security/stability reasons. This is called "memory segmentation" on some architectures, which is where the Unix phrase "segmentation violation" (SIGSEGV, or "Segmentation fault) comes from.
I know there are systems which implemented protection without virtualization, and I suppose it's possible (if silly) for the reverse to be true, too. So, while the two are closely related, and both are implemented by the hardware MMU (Memory Management Unit), they are not the same.
Note that the above kind of "segment" has nothing to do with the 8086's 64 KB segments. The 8086 supported a 1 MB address space, but a 16-bit address word was used for most things. I assume that was due to price/performance limitations imposed by the technology of the day, but I don't know.
The 80286 did support memory protection, but not a flat memory model. You still had to worry about segments, although the segments could be larger. (I want to say 16 MB, but that might have been the total address space -- it's been awhile.) I don't remember if the 80286 supported virtualization.
"Swapping" means taking an entire process's memory space and writing it out to disk. This came first, because it can be implemented without an MMU.
"Paging" means taking chunks of memory not recently used and writing them to disk. So-called because virtual memory manages memory in chunks called "pages". This needs an MMU, because the process keeps running even with big chunks missing. When a process tries to access a page that is out-of-core, it causes the MMU to issue a page fault, which the OS traps. The OS then brings the page in from disk and resumes the process.
I went into the article looking for that kind of thing, and like you, I thought I had found it. But you'll note that, technically speaking, the author does not say that Microsoft invented paging -- just that Windows was designed to use it. Likewise, he says that Microsoft's term is "Virtual Memory". He doesn't say that is the originally correct term.
Whether that means the author knows what he is talking about, or if he was just lucky, I don't know.
"Somebody would have to be incredibly naive to ignore all the warnings and still proceed."
Yes, and if ignorance really was bliss, the world would be one hell of a lot happier then it actually is.
I'm an IT consultant.
I've watched countless users sit there and click though endless dialogs warning them about how they're about to unleash bubonic plague upon the world or whatever. These people regard warnings as a hassle, something to be dismissed as quickly as possible. They do not regard them as an actual warning. Warnings are something that apply to other people.
If you change the default button to be the "safe" option, they click-and-close, try again and click-and-close, try again and click the other button and continue. They don't do this by reading the dialogs, they do this because if it didn't work the first two times they tried the first button, then it must be the other one.
If you require users to enter in "please destroy all my data" on the keyboard before running something, they will happily do that, to. While asking me why it asks them that.
If you require them to type a password, they'll type that in upon request, too. Look at how successful phishing scams are.
If all this fails to get some badware on the computer, users will seek out things like "Hotbar", "Gator", "Comet Cursor", "Bonzai Buddy", and so on, and try to install them.
People just don't want to have to think. That's the ultimate problem.
There's no doubt that the average MS-Windows system, as deployed, is hideously insecure. However, experience has shown me that even if you lock the system down well, users will still try and destroy it.
I've found the only way to keep users from compromising the security of their system is to remove their ability to do so. Then they just complain to me constantly that they cannot install all their badware. But then I can just tell them "Tough!".
omicronish: "For years I thought all UNIX systems had cool graphical UIs like [in Jurrasic Park], and then I tried a real one and was disappointed by these crazy things called "characters"."
Queer Boy: "In the late 90s IRIX did have a graphical menu that was similar to that."
That would be the "3D File System Navigator", or FSN. It's still around, as is SGI, at least for now. This page tells about it and has some screenshots:
"Granted, this demo is designed to display the insulation on the 'Monster' surge protectors only, but they use the same insulating technology on their A/V Cables as well."
Um, the noise filtering that is done by a quality power conditioner is a totally different kind of thing then the insulation on a signal cable. The power conditioner has active circutry that try to force the power feed to something as close as possible to a pure 60 Hz AC sine wave, 120 volts RMS, 0 to 170 volt range. The signal cable just has some other wire wrapped around it to try and grab stray noise before it hits the signal wire.
I have no doubt that a "Monster" brand power conditioner does a good job regulating the power flow. Likewise, I'm sure the Radio Shack surge protector doesn't, because it isn't designed to. Surge protectors are intended to keep an overvoltage from frying components; they're not intended to eliminate noise. Power conditioners are much more complicated (and thus, more expensive).
Myself, I'm happy with the APC Smart-UPS 1250 that I got used for $100 at a hamfest. Not only does it provide very clean, conditioned power, it will keep my Tivo running if city power dies.:-)
If one doesn't need batteries, you can get a 12 amp line condioner new for like $50 these days. Sure, it will be a plain beige box instead of the fancy "Monster" brand unit, but it does the same thing.
Of course, I suppose, to be *really* good, one should add an isolation transformer. Maybe Monster sells those, too.
"The real question is why aren't the governments in places where these are sold stomping these people to bits?"
Ya know, while I'm not one to worship at the altar of free market and deregulation and all that crap, I really have to wonder at this statement. If people are stupid enough to pay money for something like this, maybe they deserve to loose their money. It isn't like there's a big potential for collateral damage here. Stupid people get punished, smarter people make some money, and maybe with time people will start learning to think for themselves for a change.
...let's keep in mind that the NSA exists for a reason, and that reason is important.
The NSA is responsible for crypto and communications. "NSA" might better be expanded to the "National Signals Agency". They eavesdrop on communications, while trying to make "our" communications proof against the same. Note that I don't say whose communications they are eavesdropping on; it seems a fair bet that their net is cast widely. Likewise, the NSA's definition of "our" is rather... non-obvious. A lot of what they do is intended to make sure that the US's secure communications can be monitored by the "appropriate authorities".
"Sneakers", for all the jokes, isn't too far off. The NSA doesn't get it's hands dirty with "wet" operations, like the CIA and the FBI are interested in. And the NSA is much too good at what they do to let you hear them listening in on your phone calls...
As far as the "we need the big government TLAs" argument goes, I generally agree, but I must ask: Who watches the watchmen? The traditional military, and your local PD, operate out in the open. They might be heavy-handed, dumb, or even outright evil, but at least you can see it. You can spot the abuses and, hopefully, keep things going in the right direction.
How do we know the NSA is telling the truth? The NSA says so! Well, can't they show us? Nope. Why not? The NSA says so! Sure, it might be true, but it also opens up a huge potential for abuse. Lord Acton's observation on absolute power remains apt and true.
"No other OS today will run a program designed for an Operating System 10 years old while still having the features one would expect from a modern operating system."
Lessee... everybody's been pointing out MacOS X. Let's list a few more:
Ancestral Unix appeared in 1970. It's still pretty much source-compatible with modern Unixes like *BSD. Sure, you need to recompile, but that's as much because there ain't too many working PDP-11's around anymore.
VMS debuted in 1978, and is supposedly retains binary compatability even on completely different hardware, thanks to a VAX emulator for the Alpha platform.
IBM's MVS (which is now called OS/390, I guess) appeared in the early 1970's as well. I've read in many places that there were lots of MVS programs running in the late 1990's for which the source had been long lost. This is an issue when you're trying to fix Y2K limits.
Slashdot Mirror
"My knowledge of Linux is sketchy so perhaps there are equivalents to this in Linux-land?"
The basic Linux equivilent would be a statically-compiled executable. Such binaries don't use shared libraries at all; they contain everything in a single file. Of course, that file is often huge compared to the same program dynamically linked.
This doesn't so much solve the binary compatability problem as bypass it. When you bring everything with you, you don't have to worry about what others provide.
The downside, aside from the size issue, is that when a library is upgraded (either for bug fixes or nominally backwards-compatible enhancements), the application doesn't notice. You have to rebuild the app and redistribute to gain the benefits of the updated library.
"You said binary compatibility is hard, but isn't that really more true on Linux than elsewhere (because of its origins and the emphasis on compiling from source and installing libraries in different locations)?"
Not exactly. Binary compatability presents the same problems, regardless of platform. But it is certainly true that the effects of binary compatability being hard are seen more on Linux.
The biggest reason binary compatability looms large in the land of Linux is that Linux doesn't come from a single person or organization. Each distro has their own ideas and their own set of options. Contrast that to the world of Macintosh, where Apple has always excercised tight control over all aspects of the platform. That helps keep everything working together. You may have less choice and less variety, but what you have feels more closely knit together.
Like most things in life, there's a trade-off involved.
"Hopefully that's not also Linux flamebait..."
That was directed at the OP's remarks about how there's no point about talking about Linux desktops.
"I'm not trolling, because everything I've said is true..."
Well, one can say nothing but the "truth" and still be looking to incite an argument, but that's another discussion.
Let's look at a few things here.
In terms of actually running a program, I can take a very old Linux binary, statically linked, and run it on my modern Linux distro (assuming it doesn't care about kernel functionality). Same with Windows. The executable format itself is still well supported. It's the shared libraries that are the issue.
On either OS, if I try to run a program linked against some library, and I don't have that library, I will get some kind of dynamic linker/loader error. Linux or Windows. Windows isn't magic here.
Now, on Linux, this is often caught at install time by a package manager. Failing that, the error will be from the shared object loader. In both cases, the computer is doing what it is supposed to: Tell you that you don't have all the pieces.
On Windows, it is usually up to an "install program" to make sure all required shared libraries (DLLs) are present, and install them if not. From what I've seen, most install programs simply dump the DLLs *they* want in the Windows System directory. It is assumed backwards compatability is always perfect, if the question arises at all.
That's great when it works, I suppose. The problem is also causes all sorts of weird failures and conflicts, of the type I described previously. It makes configuration management an absolute nightmare. Hence the whole "clean install" practice in Windows-land, where blowing away the OS and installing from scratch is considered normal. Blech.
I've certainly encountered no end of software that cares about this or that dependency on Windows. Some random examples:
- Adobe Reader 7 won't install on Win98
- The latest Symantec Anti-Virus requires a root certificate update from Microsoft
- Countless things that require Internet Explorer 6
- Office 2003 requires Windows 2000 or later
- Exchange 2000 won't work on Windows 2003
- QuickBooks hates Windows XP Service Pack 2
And so on. I don't find Windows nearly the compatability dream you find it to be. I suspect you're content just because your granny only wants one "special" program, so you don't have to worry about how said program clobbers all the shared libraries that other programs care about.
Now, there are some differences in the "community" of Linux vs Windows. As already mentioned, Windows programs tend to include many of their dependencies with the install package. Not so much on Linux. I suspect this is largely due to the fact that so much "freely available" software is used on Linux; you can just download everything and don't have to worry about license fees.
Linux does tend to change more rapidlly then Windows. This has obvious benefits, but it does mean the "churn" in package pools can be an issue. Indeed, that's what kicked this Slashdot article off. Of course, when Microsoft decrees the version of Windows you have to be "dead", then you're equally stuck. Getting support for 98 these days isn't a picnic, either.
I'm am most assuredly not saying Linux is immune to the problems I describe; quite the opposite. But I am saying that Windows is not immune.
"First, let's get out in the open what you think I'm asking for and then what I'm actually asking for. "
Well, that's fair. I ass-umed you were yet another person whining about how your consumer Internet feed is just oh-so-much-money, when compared to the alternatives, it's one-tenth the price or better. I get a lot of those, and as somebody who has worked in network operations in the past, most end-users don't appreciate just how expensive some of this stuff is. I jumped to a false conclusion there. My apologies.
"I want the always-on-ness of cable or DSL internet instead of dialup, but don't care about the huge bandwidth increase. "
Well, that's a far more reasonable desire, and one I can understand (even if I don't fall into the category myself). Unfortunately, Internet connection bandwidth is not a truely was a fungible commodity. The big cost (as I ranted about) is in all the physical infrastructure. Once you've got all *that* in place, the difference between a 500 kilobit circuit and a 1000 kilobit circuit tends to be one of software configuration. In other words, both cost almost exactly the same to provide. Unfortunate for people such as yourself.
Based on the replies I'm seeing, it appears I failed to make my point clearly.
As I said, PDF is great when you need visual consistency. When you actually something to look the same everywhere. Obviously, if you're distributing electronic versions of dead-tree forms, you need that. (I might argue that it would be better to just implement an electronic form submission system, but that's not always a realistic solution.) PDF is useful here. That's not what I was getting at.
However (and this was the point I was trying to make), people and organizations get far too attached to the appearance of a document, when they should be focused on the content. It's the substance, and not the form, that counts. That's my major point. Distributing, say, a bank statement in PDF to make it "look the same" as a "real" bank statement is inherently silly. What makes the PDF more "real" then an HTML presentation? What does having the same format of another document make something I print myself "more real"?
Look at stlhawkeye's reply, where he says the HTML version of his bank statement wasn't accepted. Now, that justifies a demand for his bank to make "look alike" data available as a PDF, but let's look beyond that. Why the hell does anyone care the source of the print out was HTML? It's not like there's a universal standard for bank statements. And simply having a bank statement is not the point. The finance company (or whoever) doesn't want proof that stlhawkeye has a bank statement -- they want evidence of financial credibility. That's independent of format and presentation. How it looks doesn't matter. Yet they make an issue of it. That's bad.
As for those who complain that HTML does not look the same everywhere: That's the point. HTML is supposed to look different everywhere. It's a feature, not a bug. An HTML document can be presented one way on screen, another way printed on a laser printer, another way on a character-only line printer, another on a cell phone display, another way as audible voice from a speech synth, and so on. Done right, you could have the computer in your car read you your bank statement on the way to work.
This concept, which HTML embraces, opens up huge potential in information systems. Yet things like "Best viewed with so-and-so", or "Download SecretSoft's plug-in", are killing this off. That's bad.
(And, yes, obviously it was George Orwell, not Orson Wells, who wrote Animal Farm. Total brain fart there. I have placed a virtual brown paper bag on my head. Etc, etc.)
DragonHawk: "Hence the Orson Wells reference in my subject."
tverbeek: "Oh, did Wells produce a movie version of George Orwell's Animal Farm?"
*sound of head against desk, hard*
I. Can't. Believe. I. Did. That.
Can I moderate my own post with -1, Blatantly Stupid Error?
"Adobe certainly will be inserting their SVG magic into the Macromedia environment. "
What, exactly, makes you so sure? You got a portal to the future you're not telling us about?
Adobe *loves* the idea of lock-in. Remember, this is the company that had someone *arrested* for reverse-engineering Adobe's eBook format just so people could view and make backups of their files. (See http://www.freesklyarov.org/ for details.)
So given the choice between something like SVG, which Adobe doesn't totally control, and Flash, which (assuming this goes through) Adobe will own, lock, stock, and barrel, I strongly suspect they will go for the latter.
Money follows the path of least resistance.
"I like PDFs, it allows me to download my tax statement, bank statements, government forms, and all kinds of other stuff that I used to have to fork over $3 to some government agency to get ahold of."
Yah, it isn't like you can do that with open standards like PNG, JPEG, HTML, or even plain text. They obviously needed a semi-closed, really bloated, high-resolution, stuck-on-the-idea-of-dead-trees system to give you your bank statement.
/SARCASM
It really irritates me when I go to obtain some basic information (like my bank account details or some product info) and the web server insists on shoving a PDF down my throat. HTML would be so much better: Smaller, quicker, open, no special software, device and software independent. Why PDF?
PDF (and things like it) are great when you actually need the rendered output to be the same everywhere. For example, if one is sending proofs of a marketing brochure around, one wants consistancy. But somehow Adobe has duped a bunch of people into thinking it is vital at all times. (Hence the Orson Wells reference in my subject.)
So many other things use PDF (or at least the PDF mindset of "It has to look the same everywhere") when there is no need. The web was *designed and intended* to look different depending on what the user wanted. That's a good thing. It means you, as the content producer, *don't have to worry about* how it might look. Computer, cell phone, printed page, direct mind-link to my brain -- it was all supposed to be automatic.
But too many PHB's and similar types come up with things like "I want this five pixels to the left", not understanding that not everybody has their (the PHB's) computer.
Content producers really need to stop worrying so much about how somebody, somewhere, might possibly have some influence over the presentation of their work.
/PET_PEAVE
"Uh, so when are they going to start offering this reasonable price you speak of?"
Dude, do you have any idea what it costs for the sort of connection you think you deserve? You're talking about a dedicated circuit. Your typical cost for a megabit of PVC is gonna be at least $400 or $500 a month, even in a nice urban area with lots of coverage. In rural areas, try $1000 or $1500 a month. For a true dedicated leased line, they charge you per foot from the CO.
Now, granted, the telcos price structure is hugely unfair, but even so, providing dedicated, carrier-class service is freaking expensive. Outside plant, CO infrastructure, power, backup power, cooling, network equipment, monitoring, field service staff and equipment, all the pieces needed to provide an SLA -- they cost real money.
Getting a megabit of "consumer grade" Internet feed for $50 a month or whatever is a freaking bargin. I for one am glad to have it.
Yes, that must be the reason MS Windows is (for most application) binary compatible FOR ONLY PAST TEN-TO-FIFTEEN YEARS!!
I'm guessing you're trolling, but you do touch on some points in my original post worth expanding upon. As I said, Windows has these issues, too.
Have you ever noticed that the more software gets installed on Windows, the more likely it is to have trouble? There are a number of reasons for that, but the biggest is known colloquially as "DLL Hell". As I said, Windows only allows you to have one version of a shared library installed at a time. So you get all these crazy dependencies where program A requires library version X, but program B requires library version Y, so you can't have them both on the same system at the same time.
My personal favorite example of this is how if you install Microsoft Outlook 2000 (the Exchange client) on your Exchange 2000 server, you will cause the Information Store to stop working until you replace a certain set of DLLs (and thus break Outlook). Fifteen years of binary compatibility? Hell, Microsoft can't get it to work in the same year!
The ability to have the system load and run-time link an executable image does not mean that binary compatability issues don't exist. Linux has had that all along, too. But in Windows, you don't even get the warnings that RPM (or whatever) gives you. You just get screwball behavior.
This is why in Microsoft's ".NET Framework". Microsoft has implemented to so-called "managed code assemblies", which reference the specific libraries they were built against, and call those versions in. Of course, this is a radical departure to how Windows manages shared library and run-time linking. Everything has to be restructured to make use of it. I'm not sure how that qualifies as "compatible", either.
Microsoft isn't exempt from this reality anymore then Linux or BSD is.
I'm not going to bother responding to the Linux flame-bait.
The problem is simply that binary compatibility is hard.
Easy enough; it's the implications that are subtle. Like that building a key system library with different options makes it a different package. That changing a key system library thus changes the entire configuration management scenario. That a package that has different subcomponents, each with their own dependencies, is a package that depends on all of them. That auto-built dependencies tend to be even pickier then the real ones. That packages are only as good as their (builder supplied) metadata. And so on and so forth.
There must be something about this that is either hard to comprehend, or hard to accept. It gives a lot of RPM users trouble, it gives Debian users a sense of superiority, it's what makes BSD ports work so well, and it's largely responsible for making Microsoft Windows the unholy mess that it is. Clearly, there's a disconnect here.
Take a look at some common misconceptions in the software world.
It appears a disproportionate number of Debian users carry a false sense of superiority about their package tools, when what really makes Debian win is the size of the distribution package pool. Specifically, that having such a large pool of configured, compiled, and tested packages readily available via "apt-get install foo" leads a lot of Debian people into think APT is somehow magic.
Likewise, RPM properly saying "I don't think you have the pieces you need for this to work" leads so many people into thinking that RPM *causes* "dependency hell". RPM simply reports it. YUM (and things like it) can help you with it. But the nature of binary software itself is what *causes* dependency hell.
And the fact that BSD ports downloads, configures, builds, and installs all specified components *from source* leads BSD bigots into thinking that the BSD ports packagers must be doing a much better job then Red Hat or Debian packagers. Rather, they just bypass the problem of binary compatability.
And, again, this is also largely responsible for why Windoze sucks so much. When everything is a binary which you have no source for, and no two packages share information on what is being installed, and you can only install one version of any given library at once time -- then, yah, it's a minor kind of miracle the thing ever works at all.
Binary compatability is hard.
Larry Niven, one of my favorite authors, has spoken eloquently on why we should have a space program. For a nice (but subtle) treatment of the pragmatic concepts, read his short story "At the Bottom of a Hole". But he has a better, and shorter, statement on the situation:
"The dinosaurs became extinct because they didn't have a space program."
Says it all, really.
Anyway: I stumbled across a weird Google behavior the other day. If you do a regular Google for "read news" you get some weird results at the top of the results page:Try it: http://www.google.com/search?q=read+news
Anyone have any idea what that is? New feature still in development? Old feature never finished? Documented feature I'm being stupid about? Ordinary bug?
Inquiring minds want to know. Well, not really, but Slashdot readers might. Well, me, anyway.
The fundamental difference between stack and heap is how they grow.
The program stack is just that: A stack of data. For each new subroutine call, storage needed by that subroutine is allocated ("pushed") on the top of the stack. When the subroutine returns, the the storage is released ("popped"). In every system I know of, stack is allocated automatically (typically using local variable declarations).
Heap allocation can be random. Programs allocate heap when they need it and release it when they are done, in any order they wish. In classic systems like C and Pascal, heap management needs to be done by the programmer. You have to malloc() and free() manually, for example. In systems like Java or Python, you just create new objects, and the system garbage-collects them away for you.
Typically, the stack is allocated starting from low memory (address 0 or some other base) and grows up, while the heap is allocated starting at high memory (top of memory or top of virtual segment) and grows down. If the two meet (stack/heap collision), you've run out of memory (or address space) and are very hosed.
You generally have a stack and a heap even on single-task, non-memory-managed microsystems, such as MS-DOS. There's no sharing of the heap between processes, but you still have a stack and a heap.
On many (most?) Unix systems: As stack and heap grow, the process requests memory from the kernel when needed to grow either stack or heap, and the kernel allocates memory from the free pool to satisfy that request. However, there is no mechanism for the process to return storage to the kernel free pool.
On Windoze, I believe the heap is dynamic amoung all processes, as you describe.
"this sort of malware would not be able to do anaweful lot except perhaps create some files and run some processes as a user"
That's all a lot of the worst worms to hit the 'net have done. Many of these mass-mailing worms that have overloaded networks and crashed servers did nothing more then read the user's address book and then mail copies of themselves to everyone. You don't need root for that. You barely need a filesystem.
There's also the fact that, ultimately, people want to protect their data. Protecting the system privilage level is just a means to that end. If the trojan program can read and write all the user's data, then the game is largely over anyway, for your typical single-user home system. The fact that the operating system is still protected is almost irrelivant.
"In contrast, dialog boxes are much rarer on Macs, and they are written much more clearly, and are more useful. They encourage the user to pay attention to them."
I might be willing to buy that, if it wasn't for the fact that the vast majority of software isn't written by Microsoft or Apple. (Both companies provide only general purpose software. If it was just the Microsoft or Apple apps we had to worry about, switching platforms would be a lot easier.) Bad software exists on every platform I've ever used. I've seen buggy, insecure, poorly-documented, hard-to-use software on the Mac. And on Linux. And, of course, on 'doze. I've seen stupid users on all of the above.
More importantly, I've seen stupid users nowhere near a computer. I see them every time I get on the highway. I see them in the food store buying "Lite" versions of food that are just as laden with fat, sugar, and other crap as the regular versions. I see them on the news every night. I read about them in history books. Nothing in my experience has given me any reason to believe that stupid people should be any less common for computer users than the rest of humanity.
FWIW, while I use Macs fairly infrequently, I've seen plenty of stupid dialogs on the Mac. I question your assertion that such are less common on the Mac. Do I have a statistical analysis? No. But I suspect you don't either. If you do, I'd love to see it. (Seriously.)
"I'm sure you'll give them helpful advice without being snotty and condescending."
I generally ignore anonymous trolls, but I did want to respond to this bit, for clarity: I was being condescending, yes. However, it was more at the situation and at the general stupidity of the human race, myself included. Some of it was also directed at the OP and their incorrect belief that technology can solve behavioral problems. I'm not condescending to my paying customers; they pay me. Slashdot gets my drivel for free. Additionally, I always take care to educate and inform my users. It's the ones that persist in doing the wrong thing despite repeated attempts at behavior-modification that annoy me.
My understanding:
Strictly speaking, "virtual memory" means the addresses seen by the running code are translated to physical addresses (by the MMU). Thus, the code sees virtual addresses.
"Memory protection" describes the feature where the running code is prevented from accessing certain parts of memory, for security/stability reasons. This is called "memory segmentation" on some architectures, which is where the Unix phrase "segmentation violation" (SIGSEGV, or "Segmentation fault) comes from.
I know there are systems which implemented protection without virtualization, and I suppose it's possible (if silly) for the reverse to be true, too. So, while the two are closely related, and both are implemented by the hardware MMU (Memory Management Unit), they are not the same.
Note that the above kind of "segment" has nothing to do with the 8086's 64 KB segments. The 8086 supported a 1 MB address space, but a 16-bit address word was used for most things. I assume that was due to price/performance limitations imposed by the technology of the day, but I don't know.
The 80286 did support memory protection, but not a flat memory model. You still had to worry about segments, although the segments could be larger. (I want to say 16 MB, but that might have been the total address space -- it's been awhile.) I don't remember if the 80286 supported virtualization.
"Swapping" means taking an entire process's memory space and writing it out to disk. This came first, because it can be implemented without an MMU.
"Paging" means taking chunks of memory not recently used and writing them to disk. So-called because virtual memory manages memory in chunks called "pages". This needs an MMU, because the process keeps running even with big chunks missing. When a process tries to access a page that is out-of-core, it causes the MMU to issue a page fault, which the OS traps. The OS then brings the page in from disk and resumes the process.
"Windows 3.0 had virtual memory support in 1990 ... so did every server OS at the time."
:)
NetWare didn't.
I know, nobody cares. But hey, it's Slashdot.
I went into the article looking for that kind of thing, and like you, I thought I had found it. But you'll note that, technically speaking, the author does not say that Microsoft invented paging -- just that Windows was designed to use it. Likewise, he says that Microsoft's term is "Virtual Memory". He doesn't say that is the originally correct term.
Whether that means the author knows what he is talking about, or if he was just lucky, I don't know.
"Somebody would have to be incredibly naive to ignore all the warnings and still proceed."
Yes, and if ignorance really was bliss, the world would be one hell of a lot happier then it actually is.
I'm an IT consultant.
I've watched countless users sit there and click though endless dialogs warning them about how they're about to unleash bubonic plague upon the world or whatever. These people regard warnings as a hassle, something to be dismissed as quickly as possible. They do not regard them as an actual warning. Warnings are something that apply to other people.
If you change the default button to be the "safe" option, they click-and-close, try again and click-and-close, try again and click the other button and continue. They don't do this by reading the dialogs, they do this because if it didn't work the first two times they tried the first button, then it must be the other one.
If you require users to enter in "please destroy all my data" on the keyboard before running something, they will happily do that, to. While asking me why it asks them that.
If you require them to type a password, they'll type that in upon request, too. Look at how successful phishing scams are.
If all this fails to get some badware on the computer, users will seek out things like "Hotbar", "Gator", "Comet Cursor", "Bonzai Buddy", and so on, and try to install them.
People just don't want to have to think. That's the ultimate problem.
There's no doubt that the average MS-Windows system, as deployed, is hideously insecure. However, experience has shown me that even if you lock the system down well, users will still try and destroy it.
I've found the only way to keep users from compromising the security of their system is to remove their ability to do so. Then they just complain to me constantly that they cannot install all their badware. But then I can just tell them "Tough!".
omicronish: "For years I thought all UNIX systems had cool graphical UIs like [in Jurrasic Park], and then I tried a real one and was disappointed by these crazy things called "characters"."
Queer Boy: "In the late 90s IRIX did have a graphical menu that was similar to that."
That would be the "3D File System Navigator", or FSN. It's still around, as is SGI, at least for now. This page tells about it and has some screenshots:
http://www.sgi.com/fun/freeware/3d_navigator.html
I played with it on the Ingdio 2 we had in the lab at Unnamed Univerity. Pretty useless, but fun for a few minutes.
"Granted, this demo is designed to display the insulation on the 'Monster' surge protectors only, but they use the same insulating technology on their A/V Cables as well."
:-)
Um, the noise filtering that is done by a quality power conditioner is a totally different kind of thing then the insulation on a signal cable. The power conditioner has active circutry that try to force the power feed to something as close as possible to a pure 60 Hz AC sine wave, 120 volts RMS, 0 to 170 volt range. The signal cable just has some other wire wrapped around it to try and grab stray noise before it hits the signal wire.
I have no doubt that a "Monster" brand power conditioner does a good job regulating the power flow. Likewise, I'm sure the Radio Shack surge protector doesn't, because it isn't designed to. Surge protectors are intended to keep an overvoltage from frying components; they're not intended to eliminate noise. Power conditioners are much more complicated (and thus, more expensive).
Myself, I'm happy with the APC Smart-UPS 1250 that I got used for $100 at a hamfest. Not only does it provide very clean, conditioned power, it will keep my Tivo running if city power dies.
If one doesn't need batteries, you can get a 12 amp line condioner new for like $50 these days. Sure, it will be a plain beige box instead of the fancy "Monster" brand unit, but it does the same thing.
Of course, I suppose, to be *really* good, one should add an isolation transformer. Maybe Monster sells those, too.
"The real question is why aren't the governments in places where these are sold stomping these people to bits?"
Ya know, while I'm not one to worship at the altar of free market and deregulation and all that crap, I really have to wonder at this statement. If people are stupid enough to pay money for something like this, maybe they deserve to loose their money. It isn't like there's a big potential for collateral damage here. Stupid people get punished, smarter people make some money, and maybe with time people will start learning to think for themselves for a change.
...let's keep in mind that the NSA exists for a reason, and that reason is important.
... non-obvious. A lot of what they do is intended to make sure that the US's secure communications can be monitored by the "appropriate authorities".
The NSA is responsible for crypto and communications. "NSA" might better be expanded to the "National Signals Agency". They eavesdrop on communications, while trying to make "our" communications proof against the same. Note that I don't say whose communications they are eavesdropping on; it seems a fair bet that their net is cast widely. Likewise, the NSA's definition of "our" is rather
"Sneakers", for all the jokes, isn't too far off. The NSA doesn't get it's hands dirty with "wet" operations, like the CIA and the FBI are interested in. And the NSA is much too good at what they do to let you hear them listening in on your phone calls...
As far as the "we need the big government TLAs" argument goes, I generally agree, but I must ask: Who watches the watchmen? The traditional military, and your local PD, operate out in the open. They might be heavy-handed, dumb, or even outright evil, but at least you can see it. You can spot the abuses and, hopefully, keep things going in the right direction.
How do we know the NSA is telling the truth? The NSA says so! Well, can't they show us? Nope. Why not? The NSA says so! Sure, it might be true, but it also opens up a huge potential for abuse. Lord Acton's observation on absolute power remains apt and true.
"No other OS today will run a program designed for an Operating System 10 years old while still having the features one would expect from a modern operating system."
;-)
Lessee... everybody's been pointing out MacOS X. Let's list a few more:
Ancestral Unix appeared in 1970. It's still pretty much source-compatible with modern Unixes like *BSD. Sure, you need to recompile, but that's as much because there ain't too many working PDP-11's around anymore.
VMS debuted in 1978, and is supposedly retains binary compatability even on completely different hardware, thanks to a VAX emulator for the Alpha platform.
IBM's MVS (which is now called OS/390, I guess) appeared in the early 1970's as well. I've read in many places that there were lots of MVS programs running in the late 1990's for which the source had been long lost. This is an issue when you're trying to fix Y2K limits.
So, bzzzt, wrong, thanks for playing.