The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI
What you say is correct. However, what you say doesn't necessarily apply.
GNOME uses CORBA for IPC. Bonobo is a set of CORBA interfaces designed to enable component reuse. Bonobo is also an implementation of those interfaces for GTK.
KDE uses DCOP for IPC. DCOP is a layer on top of X11 ICE. In concept, DCOP is a lot like CORBA, but with all the things KDE doesn't need striped out to improve performance. KParts is another layer on top of DCOP designed to enable component reuse. KParts is tied to Qt, not so much in terms of the GUI (although that does come into things), but because KParts uses Qt's "signals and slots" mechanism for function callbacks.
The practical upshot of all this is that the IPC mechanisms and some of the component architecture is very GUI independent for both KDE and GNOME, but they didn't go to extremes trying to keep their GUI from being tied to their GUI. Which is reasonable.
(Note: This is an executive summary, and as such, may not be completely accurate. What do you want in three paragraphs?)
I find it rather annoying that, when the beginning of an idea was posted, with the comment that it was worth looking in to, the first thing everybody starts doing is coming up with reasons why it won't happen.
Niether my submission, CmdrTaco's comment, or Rivyn's pages say this is going to happen. It consists mainly of speculation and ideas at this point. Why the hell are we trying to kill it before it is even born?
Did it ever occur to anybody that, even if this hasn't been coded, tested, and approved by everyone from the Pope to the Bob the Lawmower Man, it might be a good idea? That maybe it is worth looking into?
Simply considering an idea doesn't mean that KDE is going to have to adopt CORBA for IPC or that GNOME is going to switch to Qt or that Bill Gates is buying Linux.
I submitted this to Slashdot in the hopes that a good discussion on the technical challenges involved might happen. I didn't expect a political cat-fight.
Geez people. This kind of attitude reminds me of the proprietary Unix vendor wars of the 1980s. Keep this up, and Microsoft won't need a monopoly to dominate.
This says nothing about how warm the computer itself...
Well, I felt the bottom of the sides of the iMac box, too, and that was pretty darn warm. Not as hot as the top, but still much warmer then I like. Now, I didn't pull the thing apart and stick a temperature probe on the CPU -- I think the salesmen might have had something to say about that -- but if the exposed sides were that warm, what were the components inside like?
Remember, folks, a computer running hot isn't necessarily going to burn up. High temperatures may cause erratic behavior, or simply shorten the life of your components.
Remember, also, that your average home user is going to have papers, dust, and other junk piled around the unit. I'd say the number one cause of failed components in home computers these days was heat stress, due to clogged or covered vents, or a failed fan in a single-fan system.
IMO, home computers need all the cooling help they can get. With a temperature monitor, the fan will only run when it needs to, so I really think Apple made a bad move here.
one main reason, so far as i can tell, that the imac can live without a fan is that its chip has far lower power consuption, and therefore generates much less heat that the x86 counterparts
Certainly the PowerPC helps. But I have to wonder: In my system, at least, the CPU isn't the biggest heat source. The hard drive spindle motors are. After that comes the NVidia TNT chip. (Not even a GeForce!) The CPU comes in third. Now, granted, I don't have the latest space heaters from Intel or AMD, but still, I have to wonder about these new fanless iMacs. I've seen the demo machines in stores, and I have to tell you, those suckers are hot to the touch. Can any computer running that warm really be in good health?
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
Header files are interface definition files, of course. But does the above restriction refer to interfaces to the GPL program, or to the libraries it depends on? The GPL doesn't say, specifically, but given the context of "modules it contains" in the previous English clause, I think, legally, this refers to the GPL program. Of course, IANAL. Only the courts can decide for sure.
Now, this may be a loophole in what RMS intended the GPL to be. He's free to correct it, of course. But the KDE people are also free to not incorporate his correction.
You're forgetting one thing DragonHawk: the hardcore GPL zealots don't care just what the GPL says.... No matter how many times you actually quote the GPL, you'll only get shouted down.
People can believe whatever they want to believe. Belief won't change what the GPL actually says. They can shout all they want; the words stay the same. RMS can change the GPL; people can still choose to use the "current" version for KDE.
Now, perhaps Debian's leadship believes KDE violates the GPL in this way. That is their choice. The rest of the world is not obligated to agree. If you disagree but still want to use Debian, that is between you and the Debian leaders.
The point is that something needs to change. Right now, KDE is shipping software under incompatible licenses.
I wasn't directing my message to those who think their may be a legitimate legal conflict between KDE and other software packaged together. That, the original issue, seems to be getting lost in the noise of general license flamewars. Seeing that the original issue was pretty well addressed, I was attempting to douse some of the other fires.
FWIW, IANAL, but I don't see any legal conflict with KDE being GPL while Qt is QPL, so long as any distributed KDE binaries are dynamically linked. Section 3 (which covers distribution) says:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
A KDE executable, dynamically linked, contains no Qt modules.
There are a lot of people claiming that: - The KDE folks should change to a different license - Troll Tech (the Qt folks) should change their license - The FSF should change the GPL to be "friendlier" to closed-source developers
Okay, people. Anyone who develops software is free to license it as they see fit. If you don't like the license they do, don't use the software.
Don't like the GPL? Don't use GPL software.
Don't like the QPL? Don't use QPL software.
Don't like Microsoft's EULAs? Don't use Microsoft's software.
Whatever... just because you can't scale it to every atom in the universe doesn't mean it's broken.
Right. But if it can't scale to every entity that wants an entry, it is broken. You think it's bad now? What happens when all six billion people on the planet have email, and all the businesses that go with them do too?
The DNS has to scale to this level, or it will collapse.
The whole point of DNS is to make it EASIER to remember site locations.
DNS was invented to automate the process of distributing information about network hosts. It used to be that everyone was listed in everyone else's/etc/hosts file (or local equivalent). That didn't scale (hey -- there's that word again!) so DNS was invented as a hierarchal way to organize the process.
It most explicitly was not created to make it easier for someone to guess a company's address by typing random words into the "Location" bar of your browser. The DNS exists to name things. It does not exist to find them. Naming and Finding are two distinctly different things.
And what about people... people want nameservice too.
People generally have physical locations, too.:)
Again, the better points of DNS is that it doesn't matter where you are or what your ip is.
This is, of course, an issue, and one I don't have an immediate solution for. Businesses, at least, have a place of incorporation, but even that can move if you want. And people move more often then businesses do.
But how do you expect a ".indiv" (or whatever) domain to scale to six billion people? Or more?
And this misuse you speak of.. how are you supposed to keep it from happening in this system as well?
People have legal residences. Businesses have a place of incorporation. These are tried and true methods which are already in place and have been proven to work.
At least you can prove that IBM has nothing to do with: food, sex, banking, personal name or art.
IBM does offer financial services (leasing of equipment and such), so they could certainly justify that. What about their cafeteria food services? And IBM makes large donations to the humanities, so you could argue art as well.
Point being: How do you administer this tangled mess of TLDs you propose we create?
Adding more TLDs would actually lower the value of each TLD, so it's not worth getting ibm.food because no one in their right mind would ever go there.
Wrong. Nobody in their right mind goes to www.yahoo.org, either, but guess who owns it? For any company serious about their Internet presence (which should, eventually, be equal to any company), the cost to register additional domains is small compared to the potential trouble not registering them costs.
The whole point of new TLD's is to relieve the pressure on the.com namespace. the whole reason we got into this mess is because it hasn't been expanded.
Again I point out that the us. domain structure was created in response to this very problem.
If everybody had to use the long a$$ physical location scheme that would be the biggest boost to alternate forms of address lookups they could possibly hope for.
Great! Then maybe people will stop using the DNS as a phone book and start using it the way it was intended!
Now, I'm not saying that hierarchal systems are flawed in general, but they're not good for this purpose.
Unfortunately, the Domain Name System protocol and structure is a hierarchy. It was designed that way on purpose for scalability, delegation, and organizational purposes. This may lead to complex systems, as TBL observed, but there isn't much you can do about it.
Indeed, computers more or less need a hierarchy to be efficient at sorting and lookup, which is exactly what DNS servers do. I'm not so sure we can get around that practical requirement.
Of course.invalid isn't there - nobody owns it, and it's not *supposed* to have a network attached to it..uucp works the way sethg described it, and it's similarly not something that the internic would have a good way to register...
I'm not saying there are no entries in the domains in question. I'm saying the domains themselves do not exist in the Internet DNS namespace.
For comparison,.IN-ADDR.ARPA. is registered in the DNS, even though nobody in particular "owns" it.. (the DNS root) is registered, too. But invalid. doesn't exist.
But the names are still part of the DNS name space.
Um, no, they're not. For a domain name to be part of the Internet Domain Name System, they must be registered with the root name servers. Simply no two ways about it. If A.ROOT-SERVERS.NET (which is the same as NS.INTERNIC.NET) doesn't know about the domain, it doesn't exist. Period.
Now, maybe someone has a convention of using invalid. as a domain for invalid domains (like many use localdomain. as domain for the localhost entry) but it isn't part of the DNS.
Wonderful. More TLDs. That's a lousy answer to a problem that isn't the real problem. Two strikes at once. Great job.
Here is why it is the wrong answer: It won't work. Right now, companies (and squatters) register foo.com, foo.net, and foo.org, "just to make sure" they have all the bases covered. All this is going to do is make Network Solutions and the other registrars more money.
The real problem is that everybody is trying to map a virtually infinite number of items (i.e., the known universe, as far as the Internet is concerned) into a limited namespace (English words and phrases less then 64 characters long). Anyone with half a brain can tell you that is a solution that is inherently unscalable.
The only way to make a system like this scalable is to switch to a hierarchical system. Just like you don't put every file (or directory) on a system under/ (the root, C:\ for Windows folks), you shouldn't try and put every entity in the universe under.COM.
There are two hierarchies I can think of: By category, and by location.
By category would mean that instead of microsoft.com, we would get microsoft.software.computers.com or something. Basically, use a Yahoo!(TM)-style structure to structure the Domain Name System.
There are three problems with this approach that make it unworkable. First, who gets to decide the categories, and what category a given site falls under? Is this slashdot.talk.org or slashdot.computers.com or slashdot.geeks.culture.rec.com or what?
Second, the administrative overhead of all this sorting would be prohibitively high. Registering a domain should not require a six-month background check.
Third, and most importantly, you can still have name collisions in a particular field, so long as they are geographically seperated. There must be an "Atlas Auto Body" in every county in New Hampshire. So who gets atlas.bodyshops.auto.com?
No, the only method that will scale with reality is to model the DNS after reality: Physical location. There are already existing mechanisms to make sure there aren't two Atlas Auto Body shops in Concord, NH. So make the domain atlasautobody.concord.nh.us, and the problem is solved.
Yes, it does mean Microsoft would be microsoft.redmond.wa.us. But such is life. People already remember names, addresses, phone numbers, and other things with much less sense then this.
Not coincidentally, the mechanism to do this is already in place. Just nobody uses it.
My solution? Don't add new TLDs. In fact, don't add new 2LD (Second Level Domains) either. No more new.COM domains. Make people use the system put in place to solve this problem over ten years ago.
Size. [XFree] 3.x eats up 16 megs of RAM If you run it on 8 MB ( I have ) you will notice a distinct crawl caused from swapping.
Keep in mind that when you start an XFree X server, it maps the video card's address space into system virtual memory. This makes it look like it is using a lot more memory then it is. You need to look at the RSS (Resident Segment Size), or how much physical memory it is using.
In most cases (on Linux, mind you -- commercial UNIXes are another story), I've found it isn't the X server that eats up memory, but the desktop manager, window manager, Netscape, terminal program with translucent inverse rotated backgrounds, and that sort of thing that really chew up memory.
Try just running "X" (not "startx", not "xinit", just "X", the server itself) and compare memory usage to a full blown X desktop. I think you'll be surprised.
I read your message very well. And I don't think you considered my points very well. You certainly ignored my main point, i.e., that this Internet thing we're all using right now was and continues to be developed using Open Source methods.
I said *dominant* marketshare. Last time I looked Linux, XFree and gcc were not the market leaders.
Well, I guess it depends on how you define your market.
Linux: As I said, Linux is the most popular OS for hosts permanently connected to the Internet (i.e., static IPs). This seems a reasonable metric to me. Not the only one, by any means, but reasonable and useful.
XFree: Easily the most popular X server software available. Sure, XFree doesn't have the market-share of Microsoft in the area of desktop OSes. But it also doesn't have the market-share of Ford in the area of automobiles. (Point being: XFree is neither a desktop OS or nor a car.)
GCC: Easily the most popular cross-platform compiler available. Why "cross-platform"? Because to me, a compiler that is tailored to a particular platform isn't the same thing. It would make sense that Sun can make the best compiler for Suns and Microsoft can make the best compiler for Windows [1]. But I don't want to write code that only works on one platform. Look at shops who have heterogenous networks, and GCC is almost always the compiler in use.
Footnote #1: Interestingly enough, I've heard arguments that neither Sun nor Microsoft makes the best compiler for their own platforms. But that is another story.
In fact, the open source, standards compliant and free *anythings* that have won dominant marketshare are pretty rare. Apache, Perl, BIND, and that's all that I can think of.
(I know, I know, don't feed the trolls.)
Apache. Perl. PHP. Python. BIND. BSD's TCP/IP stack. sendmail. Linux (most popular Internet server OS by host count). Various FTP server programs. XFree. GCC. You get the idea.
But really, those are just products. Open Source is a process. So how about:
- HTTP - HTML - E-Mail - The Web - The Internet
To this day, Open Source methods design, run, and maintain the Internet.
Without Open Source, 95% of the computer users in the world would be stuck with MS Exchange and thinking about how nice it would be if they could send email to people at other companies.
I've seen several people in this story mention they want or have bought such-and-such a pinball game. Now, I can see the lucky finder coming across one in some sort of yard sale or junk pile, but that seems to be a rather haphazard way to go about doing things.
Buying an arcade game new is out of the question for most people, with the price generally over $1000.
So, how does one buy a used arcade game for personal use? Is there some sort of catalogue or website? Or should I just keep an eye on ebay?
[ATA/100 is] worthless now, but it makes more sense to release a standard a year before you need it as opposed to a year after.
I suspect it will take more like 20 to 30 months for hard drive throughput to actually reach speeds that justify ATA/100. And ATA/100 is just supposed to be a quick fix until Serial ATA arrives. Or at least, that's what Intel would have you believe.
Me:Wide SCSI supports up to sixteen devices on the bus at a time.
You:15, the SCSI card is included as a device.
Sixteen devices. A SCSI host adapter is a device. You can have any number of SCSI host adapters on a bus, from zero to sixteen. This is vital in a fault-tolerant situation.
Me:In fact, we could use more bus bandwidth!
You:Who's we? Speak for yourself.
Touche.
In this case, "we" is the SCSI community. You can saturate Ultra160 SCSI with just four or five drives these days, even though the bus supports up to sixteen devices.
The rest of your post shows that you obviously don't know who ATA drives are intended for. IDE is a consumer level product, plain and simple.
If ATA is supposed to be such a low-end technology, then why do they keep trying to extend it? That's my whole point. Why invent new standards which are not as good as existing standards which already do a better job?
Show me one motherboard available for any current AMD/Intel CPU that doesn't have at least 1 32bit PCI slot.
Funny, you're proving my point.
If you were paying attention to the thread of conversation, you would know that you were objecting to SCSI Ultra160 because it needs 64-bit or 66 MHz PCI to actually use that kind of speed, and that "no one" has that kind of hardware.
I replied saying that, not long ago, no one had PCI at all.
You replied saying that these days, everyone does.
Do you see the progression? Or do I need to draw you a picture?
Though Firewire will probably take some of the storage market.
Firewire's nice in environments where you need very low latency (i.e., real-time data acquisition), and for systems like digital cameras where you disconnect things a lot. For disk and tape I/O, Ultra160 SCSI is still quite a bit faster, though.
Try busmastering drivers, they work wonders. I don't know what you are doing to make your system grind to a hault using a CDROM drive.
When are you going to get it through your skull that this is due to design flaw in the ATA bus, and has nothing to do with the drivers?
The problem is ATA doesn't support disconnection.
When an ATA device is busy, the other device on the bus cannot be used.
If you have a CD-RW drive, a DVD drive, a Zip drive, and a hard drive (a very reasonable scenario, even for these "home users" you keep using to apologize for ATA's bad design), then you're going to run into those sorts of problems. It doesn't matter how good your drivers are.
Not everyone has the money to buy a $700 motherboard plus $2000+ for hard drives like you do.
You just don't get it, do you? The only reason SCSI equipment costs more (and it isn't that much more, BTW) is volume. Rather then trying to push ATA still further into an area where, by your own admission, it wasn't designed for, why don't we just switch to SCSI and get it over with?
Somebody already posted the start of the cmd640.c file, but I haven't seen any quotes from srmmu.c, which had me ROTFL when I first read them.
#if 0/* I think this is bad news... -DaveM *
/* And one more, for our good neighbor, Mr. Broken Cypress. */
/* Gee george, I wonder why Sun is so hush hush about this hardware bug... really braindamage stuff going on here. However I think we can find a way to avoid all of the workaround overhead under Linux. Basically, any page fault can cause kernel pages to become user accessible (the mmu gets confused and clears some of the ACC bits in kernel ptes). Aha, sounds pretty horrible eh? But wait, after extensive testing it appears that if you use pgd_t level large kernel pte's (like the 4MB pages on the Pentium) the bug does not get tripped at all. This avoids almost all of the major overhead. Welcome to a world where your vendor tells you to, "apply this kernel patch" instead of "sorry for the broken hardware, send it back and we'll give you properly functioning parts" */
/* You see Sun allude to this hardware bug but never admit things directly, they'll say things like, "the Swift chip cache problems" or similar. */
/* Are you now convinced that the Swift is one of the biggest VLSI abortions of all time? Bravo Fujitsu! Fujitsu, the !#?!%$'d up processor people. I bet if you examined the microcode of the Swift you'd find XXX's all over the place. */
/* TurboSparc is copy-back, if we turn it on, but this does not work. */
/* Emulate VLSI abortion number three, not number one */
/* Tsunami's pretty sane, Sun and TI actually got it somewhat right this time. Fujitsu should have taken some lessons from them. */
/* Ahhh, the viking. SRMMU VLSI abortion number two... */
I suppose that depends on your definition of "really useful". Me, I was still using it for my word processor until 1997.
... was slow...
Slow? Slow?!? GeoWorks ran well on my Tandy 1000 SL with 640 KB of RAM, 40 MB HDD, and an 8 MHz Intel 8088 microprocessor! Ony my friends brand new, lightning fast 80286, screaming at 12 MHz, with a whopping 2 MB of RAM, it darn near flew!
Any computer capable of running MS Windows 3.1 well would have made GeoWorks look like FTL travel. I can only conclude you were using a different product, had broken hardware, or were running it under MS-Windows or some such thing.
... was UGLY as sin.
I didn't think so, but beauty is in the eye of the beholder.
This was back in the day when the only use for Windows 3.1 I had was for launching up the occasional Solitare game, or to connect to AOL.
That is interesting, because PC/GEOS included both a solitaire game, and the original version of America Online. AOL got started on PC/GEOS, because it was the only GUI worth a damn that could run on PCs way back then.
Slashdot Mirror
Apparently some of the managers were getting really sick of all the DoJ crap, so they smoked some joints and then posted this crap.
The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI
What you say is correct. However, what you say doesn't necessarily apply.
GNOME uses CORBA for IPC. Bonobo is a set of CORBA interfaces designed to enable component reuse. Bonobo is also an implementation of those interfaces for GTK.
KDE uses DCOP for IPC. DCOP is a layer on top of X11 ICE. In concept, DCOP is a lot like CORBA, but with all the things KDE doesn't need striped out to improve performance. KParts is another layer on top of DCOP designed to enable component reuse. KParts is tied to Qt, not so much in terms of the GUI (although that does come into things), but because KParts uses Qt's "signals and slots" mechanism for function callbacks.
The practical upshot of all this is that the IPC mechanisms and some of the component architecture is very GUI independent for both KDE and GNOME, but they didn't go to extremes trying to keep their GUI from being tied to their GUI. Which is reasonable.
(Note: This is an executive summary, and as such, may not be completely accurate. What do you want in three paragraphs?)
I find it rather annoying that, when the beginning of an idea was posted, with the comment that it was worth looking in to, the first thing everybody starts doing is coming up with reasons why it won't happen.
Niether my submission, CmdrTaco's comment, or Rivyn's pages say this is going to happen. It consists mainly of speculation and ideas at this point. Why the hell are we trying to kill it before it is even born?
Did it ever occur to anybody that, even if this hasn't been coded, tested, and approved by everyone from the Pope to the Bob the Lawmower Man, it might be a good idea? That maybe it is worth looking into?
Simply considering an idea doesn't mean that KDE is going to have to adopt CORBA for IPC or that GNOME is going to switch to Qt or that Bill Gates is buying Linux.
I submitted this to Slashdot in the hopes that a good discussion on the technical challenges involved might happen. I didn't expect a political cat-fight.
Geez people. This kind of attitude reminds me of the proprietary Unix vendor wars of the 1980s. Keep this up, and Microsoft won't need a monopoly to dominate.
... the _book_ for "the rats of NIMH" was amazing ...
:-)
The book was entitled "Mrs. Frisby and the Rats of Nimh", by Robert C. O'Brien. The movie was "The Secret of Nimh". The book was much better.
Now, quick -- what does NIMH stand for?
This says nothing about how warm the computer itself...
Well, I felt the bottom of the sides of the iMac box, too, and that was pretty darn warm. Not as hot as the top, but still much warmer then I like. Now, I didn't pull the thing apart and stick a temperature probe on the CPU -- I think the salesmen might have had something to say about that -- but if the exposed sides were that warm, what were the components inside like?
Remember, folks, a computer running hot isn't necessarily going to burn up. High temperatures may cause erratic behavior, or simply shorten the life of your components.
Remember, also, that your average home user is going to have papers, dust, and other junk piled around the unit. I'd say the number one cause of failed components in home computers these days was heat stress, due to clogged or covered vents, or a failed fan in a single-fan system.
IMO, home computers need all the cooling help they can get. With a temperature monitor, the fan will only run when it needs to, so I really think Apple made a bad move here.
one main reason, so far as i can tell, that the imac can live without a fan is that its chip has far lower power consuption, and therefore generates much less heat that the x86 counterparts
Certainly the PowerPC helps. But I have to wonder: In my system, at least, the CPU isn't the biggest heat source. The hard drive spindle motors are. After that comes the NVidia TNT chip. (Not even a GeForce!) The CPU comes in third. Now, granted, I don't have the latest space heaters from Intel or AMD, but still, I have to wonder about these new fanless iMacs. I've seen the demo machines in stores, and I have to tell you, those suckers are hot to the touch. Can any computer running that warm really be in good health?
A KDE executable, dynamically linked, and run by a user however, contains Qt modules, suitably relocated.
The GPL makes no restriction on use. Only distribution.
qt header files
This is an interesting question.
The GPL says:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
Header files are interface definition files, of course. But does the above restriction refer to interfaces to the GPL program, or to the libraries it depends on? The GPL doesn't say, specifically, but given the context of "modules it contains" in the previous English clause, I think, legally, this refers to the GPL program. Of course, IANAL. Only the courts can decide for sure.
Now, this may be a loophole in what RMS intended the GPL to be. He's free to correct it, of course. But the KDE people are also free to not incorporate his correction.
You're forgetting one thing DragonHawk: the hardcore GPL zealots don't care just what the GPL says. ... No matter how many times you actually quote the GPL, you'll only get shouted down.
People can believe whatever they want to believe. Belief won't change what the GPL actually says. They can shout all they want; the words stay the same. RMS can change the GPL; people can still choose to use the "current" version for KDE.
Now, perhaps Debian's leadship believes KDE violates the GPL in this way. That is their choice. The rest of the world is not obligated to agree. If you disagree but still want to use Debian, that is between you and the Debian leaders.
The point is that something needs to change. Right now, KDE is shipping software under incompatible licenses.
I wasn't directing my message to those who think their may be a legitimate legal conflict between KDE and other software packaged together. That, the original issue, seems to be getting lost in the noise of general license flamewars. Seeing that the original issue was pretty well addressed, I was attempting to douse some of the other fires.
FWIW, IANAL, but I don't see any legal conflict with KDE being GPL while Qt is QPL, so long as any distributed KDE binaries are dynamically linked. Section 3 (which covers distribution) says:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
A KDE executable, dynamically linked, contains no Qt modules.
There are a lot of people claiming that:
- The KDE folks should change to a different license
- Troll Tech (the Qt folks) should change their license
- The FSF should change the GPL to be "friendlier" to closed-source developers
Okay, people. Anyone who develops software is free to license it as they see fit. If you don't like the license they do, don't use the software.
Don't like the GPL? Don't use GPL software.
Don't like the QPL? Don't use QPL software.
Don't like Microsoft's EULAs? Don't use Microsoft's software.
It's that simple.
Whatever... just because you can't scale it to every atom in the universe doesn't mean it's broken.
/etc/hosts file (or local equivalent). That didn't scale (hey -- there's that word again!) so DNS was invented as a hierarchal way to organize the process.
:)
.com namespace. the whole reason we got into this mess is because it hasn't been expanded.
Right. But if it can't scale to every entity that wants an entry, it is broken. You think it's bad now? What happens when all six billion people on the planet have email, and all the businesses that go with them do too?
The DNS has to scale to this level, or it will collapse.
The whole point of DNS is to make it EASIER to remember site locations.
DNS was invented to automate the process of distributing information about network hosts. It used to be that everyone was listed in everyone else's
It most explicitly was not created to make it easier for someone to guess a company's address by typing random words into the "Location" bar of your browser. The DNS exists to name things. It does not exist to find them. Naming and Finding are two distinctly different things.
And what about people... people want nameservice too.
People generally have physical locations, too.
Again, the better points of DNS is that it doesn't matter where you are or what your ip is.
This is, of course, an issue, and one I don't have an immediate solution for. Businesses, at least, have a place of incorporation, but even that can move if you want. And people move more often then businesses do.
But how do you expect a ".indiv" (or whatever) domain to scale to six billion people? Or more?
And this misuse you speak of.. how are you supposed to keep it from happening in this system as well?
People have legal residences. Businesses have a place of incorporation. These are tried and true methods which are already in place and have been proven to work.
At least you can prove that IBM has nothing to do with: food, sex, banking, personal name or art.
IBM does offer financial services (leasing of equipment and such), so they could certainly justify that. What about their cafeteria food services? And IBM makes large donations to the humanities, so you could argue art as well.
Point being: How do you administer this tangled mess of TLDs you propose we create?
Adding more TLDs would actually lower the value of each TLD, so it's not worth getting ibm.food because no one in their right mind would ever go there.
Wrong. Nobody in their right mind goes to www.yahoo.org, either, but guess who owns it? For any company serious about their Internet presence (which should, eventually, be equal to any company), the cost to register additional domains is small compared to the potential trouble not registering them costs.
The whole point of new TLD's is to relieve the pressure on the
Again I point out that the us. domain structure was created in response to this very problem.
If everybody had to use the long a$$ physical location scheme that would be the biggest boost to alternate forms of address lookups they could possibly hope for.
Great! Then maybe people will stop using the DNS as a phone book and start using it the way it was intended!
Now, I'm not saying that hierarchal systems are flawed in general, but they're not good for this purpose.
Unfortunately, the Domain Name System protocol and structure is a hierarchy. It was designed that way on purpose for scalability, delegation, and organizational purposes. This may lead to complex systems, as TBL observed, but there isn't much you can do about it.
Indeed, computers more or less need a hierarchy to be efficient at sorting and lookup, which is exactly what DNS servers do. I'm not so sure we can get around that practical requirement.
Of course .invalid isn't there - nobody owns it, and it's not *supposed* to have a network attached to it. .uucp works the way sethg described it, and it's similarly not something that the internic would have a good way to register...
.IN-ADDR.ARPA. is registered in the DNS, even though nobody in particular "owns" it. . (the DNS root) is registered, too. But invalid. doesn't exist.
I'm not saying there are no entries in the domains in question. I'm saying the domains themselves do not exist in the Internet DNS namespace.
For comparison,
But the names are still part of the DNS name space.
Um, no, they're not. For a domain name to be part of the Internet Domain Name System, they must be registered with the root name servers. Simply no two ways about it. If A.ROOT-SERVERS.NET (which is the same as NS.INTERNIC.NET) doesn't know about the domain, it doesn't exist. Period.
Now, maybe someone has a convention of using invalid. as a domain for invalid domains (like many use localdomain. as domain for the localhost entry) but it isn't part of the DNS.
Make sense?
.invalid and .uucp ... There are two current TLDs that the ICANN web page doesn't mention.
ns.internic.net doesn't think they exist.
I have to assume it knows what it is talking about.
Why not a limit on the number of diomain names that can be registered to any individual, company or organization.
Gee, it would really suck to be a network application service provider, if you could only have a maximum of two customers.
Wonderful. More TLDs. That's a lousy answer to a problem that isn't the real problem. Two strikes at once. Great job.
/ (the root, C:\ for Windows folks), you shouldn't try and put every entity in the universe under .COM.
.COM domains. Make people use the system put in place to solve this problem over ten years ago.
Here is why it is the wrong answer: It won't work. Right now, companies (and squatters) register foo.com, foo.net, and foo.org, "just to make sure" they have all the bases covered. All this is going to do is make Network Solutions and the other registrars more money.
The real problem is that everybody is trying to map a virtually infinite number of items (i.e., the known universe, as far as the Internet is concerned) into a limited namespace (English words and phrases less then 64 characters long). Anyone with half a brain can tell you that is a solution that is inherently unscalable.
The only way to make a system like this scalable is to switch to a hierarchical system. Just like you don't put every file (or directory) on a system under
There are two hierarchies I can think of: By category, and by location.
By category would mean that instead of microsoft.com, we would get microsoft.software.computers.com or something. Basically, use a Yahoo!(TM)-style structure to structure the Domain Name System.
There are three problems with this approach that make it unworkable. First, who gets to decide the categories, and what category a given site falls under? Is this slashdot.talk.org or slashdot.computers.com or slashdot.geeks.culture.rec.com or what?
Second, the administrative overhead of all this sorting would be prohibitively high. Registering a domain should not require a six-month background check.
Third, and most importantly, you can still have name collisions in a particular field, so long as they are geographically seperated. There must be an "Atlas Auto Body" in every county in New Hampshire. So who gets atlas.bodyshops.auto.com?
No, the only method that will scale with reality is to model the DNS after reality: Physical location. There are already existing mechanisms to make sure there aren't two Atlas Auto Body shops in Concord, NH. So make the domain atlasautobody.concord.nh.us, and the problem is solved.
Yes, it does mean Microsoft would be microsoft.redmond.wa.us. But such is life. People already remember names, addresses, phone numbers, and other things with much less sense then this.
Not coincidentally, the mechanism to do this is already in place. Just nobody uses it.
My solution? Don't add new TLDs. In fact, don't add new 2LD (Second Level Domains) either. No more new
Size. [XFree] 3.x eats up 16 megs of RAM If you run it on 8 MB ( I have ) you will notice a distinct crawl caused from swapping.
Keep in mind that when you start an XFree X server, it maps the video card's address space into system virtual memory. This makes it look like it is using a lot more memory then it is. You need to look at the RSS (Resident Segment Size), or how much physical memory it is using.
In most cases (on Linux, mind you -- commercial UNIXes are another story), I've found it isn't the X server that eats up memory, but the desktop manager, window manager, Netscape, terminal program with translucent inverse rotated backgrounds, and that sort of thing that really chew up memory.
Try just running "X" (not "startx", not "xinit", just "X", the server itself) and compare memory usage to a full blown X desktop. I think you'll be surprised.
People just don't know how to read anymore!
I read your message very well. And I don't think you considered my points very well. You certainly ignored my main point, i.e., that this Internet thing we're all using right now was and continues to be developed using Open Source methods.
I said *dominant* marketshare. Last time I looked Linux, XFree and gcc were not the market leaders.
Well, I guess it depends on how you define your market.
Linux: As I said, Linux is the most popular OS for hosts permanently connected to the Internet (i.e., static IPs). This seems a reasonable metric to me. Not the only one, by any means, but reasonable and useful.
XFree: Easily the most popular X server software available. Sure, XFree doesn't have the market-share of Microsoft in the area of desktop OSes. But it also doesn't have the market-share of Ford in the area of automobiles. (Point being: XFree is neither a desktop OS or nor a car.)
GCC: Easily the most popular cross-platform compiler available. Why "cross-platform"? Because to me, a compiler that is tailored to a particular platform isn't the same thing. It would make sense that Sun can make the best compiler for Suns and Microsoft can make the best compiler for Windows [1]. But I don't want to write code that only works on one platform. Look at shops who have heterogenous networks, and GCC is almost always the compiler in use.
Footnote #1: Interestingly enough, I've heard arguments that neither Sun nor Microsoft makes the best compiler for their own platforms. But that is another story.
... I could really enjoy the scenery at the beach. ;-)
In fact, the open source, standards compliant and free *anythings* that have won dominant marketshare are pretty rare. Apache, Perl, BIND, and that's all that I can think of.
(I know, I know, don't feed the trolls.)
Apache. Perl. PHP. Python. BIND. BSD's TCP/IP stack. sendmail. Linux (most popular Internet server OS by host count). Various FTP server programs. XFree. GCC. You get the idea.
But really, those are just products. Open Source is a process. So how about:
- HTTP
- HTML
- E-Mail
- The Web
- The Internet
To this day, Open Source methods design, run, and maintain the Internet.
Without Open Source, 95% of the computer users in the world would be stuck with MS Exchange and thinking about how nice it would be if they could send email to people at other companies.
Get with it.
I've seen several people in this story mention they want or have bought such-and-such a pinball game. Now, I can see the lucky finder coming across one in some sort of yard sale or junk pile, but that seems to be a rather haphazard way to go about doing things.
Buying an arcade game new is out of the question for most people, with the price generally over $1000.
So, how does one buy a used arcade game for personal use? Is there some sort of catalogue or website? Or should I just keep an eye on ebay?
[ATA/100 is] worthless now, but it makes more sense to release a standard a year before you need it as opposed to a year after.
I suspect it will take more like 20 to 30 months for hard drive throughput to actually reach speeds that justify ATA/100. And ATA/100 is just supposed to be a quick fix until Serial ATA arrives. Or at least, that's what Intel would have you believe.
Me: Wide SCSI supports up to sixteen devices on the bus at a time.
You: 15, the SCSI card is included as a device.
Sixteen devices. A SCSI host adapter is a device. You can have any number of SCSI host adapters on a bus, from zero to sixteen. This is vital in a fault-tolerant situation.
Me: In fact, we could use more bus bandwidth!
You: Who's we? Speak for yourself.
Touche.
In this case, "we" is the SCSI community. You can saturate Ultra160 SCSI with just four or five drives these days, even though the bus supports up to sixteen devices.
The rest of your post shows that you obviously don't know who ATA drives are intended for. IDE is a consumer level product, plain and simple.
If ATA is supposed to be such a low-end technology, then why do they keep trying to extend it? That's my whole point. Why invent new standards which are not as good as existing standards which already do a better job?
Show me one motherboard available for any current AMD/Intel CPU that doesn't have at least 1 32bit PCI slot.
Funny, you're proving my point.
If you were paying attention to the thread of conversation, you would know that you were objecting to SCSI Ultra160 because it needs 64-bit or 66 MHz PCI to actually use that kind of speed, and that "no one" has that kind of hardware.
I replied saying that, not long ago, no one had PCI at all.
You replied saying that these days, everyone does.
Do you see the progression? Or do I need to draw you a picture?
Though Firewire will probably take some of the storage market.
Firewire's nice in environments where you need very low latency (i.e., real-time data acquisition), and for systems like digital cameras where you disconnect things a lot. For disk and tape I/O, Ultra160 SCSI is still quite a bit faster, though.
Try busmastering drivers, they work wonders. I don't know what you are doing to make your system grind to a hault using a CDROM drive.
When are you going to get it through your skull that this is due to design flaw in the ATA bus, and has nothing to do with the drivers?
The problem is ATA doesn't support disconnection.
When an ATA device is busy, the other device on the bus cannot be used.
If you have a CD-RW drive, a DVD drive, a Zip drive, and a hard drive (a very reasonable scenario, even for these "home users" you keep using to apologize for ATA's bad design), then you're going to run into those sorts of problems. It doesn't matter how good your drivers are.
Not everyone has the money to buy a $700 motherboard plus $2000+ for hard drives like you do.
You just don't get it, do you? The only reason SCSI equipment costs more (and it isn't that much more, BTW) is volume. Rather then trying to push ATA still further into an area where, by your own admission, it wasn't designed for, why don't we just switch to SCSI and get it over with?
Somebody already posted the start of the cmd640.c file, but I haven't seen any quotes from srmmu.c, which had me ROTFL when I first read them.
/* I think this is bad news... -DaveM *
#if 0
/* And one more, for our good neighbor, Mr. Broken Cypress. */
/* Gee george, I wonder why Sun is so hush hush about this hardware bug... really braindamage stuff going on here. However I think we can find a way to avoid all of the workaround overhead under Linux. Basically, any page fault can cause kernel pages to become user accessible (the mmu gets confused and clears some of the ACC bits in kernel ptes). Aha, sounds pretty horrible eh? But wait, after extensive testing it appears that if you use pgd_t level large kernel pte's (like the 4MB pages on the Pentium) the bug does not get tripped at all. This avoids almost all of the major overhead. Welcome to a world where your vendor tells you to, "apply this kernel patch" instead of "sorry for the broken hardware, send it back and we'll give you properly functioning parts" */
/* You see Sun allude to this hardware bug but never admit things directly, they'll say things like, "the Swift chip cache problems" or similar. */
/* Are you now convinced that the Swift is one of the biggest VLSI abortions of all time? Bravo Fujitsu! Fujitsu, the !#?!%$'d up processor people. I bet if you examined the microcode of the Swift you'd find XXX's all over the place. */
/* TurboSparc is copy-back, if we turn it on, but this does not work. */
/* Emulate VLSI abortion number three, not number one */
/* Tsunami's pretty sane, Sun and TI actually got it somewhat right this time. Fujitsu should have taken some lessons from them. */
/* Ahhh, the viking. SRMMU VLSI abortion number two... */
/* Oh well */
srmmu_is_bad();
/* El switcheroo... */
I _hated_ Geoworks.
... was slow ...
... was UGLY as sin.
Well, you're entitled to your opinion.
The thing didn't have anything really useful...
I suppose that depends on your definition of "really useful". Me, I was still using it for my word processor until 1997.
Slow? Slow?!? GeoWorks ran well on my Tandy 1000 SL with 640 KB of RAM, 40 MB HDD, and an 8 MHz Intel 8088 microprocessor! Ony my friends brand new, lightning fast 80286, screaming at 12 MHz, with a whopping 2 MB of RAM, it darn near flew!
Any computer capable of running MS Windows 3.1 well would have made GeoWorks look like FTL travel. I can only conclude you were using a different product, had broken hardware, or were running it under MS-Windows or some such thing.
I didn't think so, but beauty is in the eye of the beholder.
This was back in the day when the only use for Windows 3.1 I had was for launching up the occasional Solitare game, or to connect to AOL.
That is interesting, because PC/GEOS included both a solitaire game, and the original version of America Online. AOL got started on PC/GEOS, because it was the only GUI worth a damn that could run on PCs way back then.