> While it might seem from the Linux side of the fence that there isn't anything > else but Linux and Windows, the *BSD family is big and growing. BSDI is just > one part. FreeBSD is probably the biggest completely open source BSD, with the > very prolific NetBSD and rock solidly secure OpenBSD being contenders. And not > to forget that Apple's MacOS X core, Darwin is mixed Mach and FreeBSD.
Actually, I specifically said "commercial", which doesn't include FreeBSD/NetBSD/OpenBSD (since FreeBSD is no longer affiliated with a commercial company, AFAIK). I *did* forget to mention MacOS X which implements a BSD compatibility layer on top of the Mach kernel, which would qualify.
>Posix.. DEC's version of Unix, whatever it was called, I don't remember. Anyone >remember Ultrix, by Sun Microsystems? There are scores of others.. This whole >lawsuit is just stupid.. as is SCO. Although, I did enjoy using Xenix for a >while.
You seem to be a bit confused. POSIX is the portable operating system standard. ULTRIX was the Digital version of Unix for its MIPS based line of workstations. They also sold DEC OSF/1, which was later rebranded as Digital UNIX, and then rebranded againt to Tru64 when Compaq aquired DEC.
Sun originally started selling its UNIX as SunOS, which was later rebranded as Solaris when they moved from a BSD core to a SYSV core. They also sold Interactive Unix after aquiring Interactive System's Intel UNIX business.
The "trump card" that SCO thinks it holds is that they own SVR5, which is the decendent of the original AT&T UNIX. Most commercial implementations of UNIX, aside from the BSD descendents (pretty much just BSDI at this point) contain licensed System V code (e.g. Solaris is based on SVR4, HP/UX is based on SVR3, etc). Given that the lawsuit if focusing on Linux, and Linux contains none of this copyrighted code, this is pretty much irrelevent. The entire basis of their case is alleged trade secret and contract violations, along with the unfair competition claim.
They do *not* hold the trademark as the parent claimed. The trademark was originally held by AT&T, who deeded it to USL when that was formed. Novell aquired USL and the UNIX trademark along with it, and then turned around and granted exclusive licence rights to X/Open. The trademark was later granted entirely to X/Open, and finally X/Open became part of The Open Group, who is the current trademark holder.
>If you buy anything but the cheapest tower Mac, it will BY DEFAULT have dual >processors, an OS that works with those processors, and software that works >with those processors.
One of the big reasons why this is the case is because Apple NEEDS dual processor to keep even somewhat competitive with the intel world.
If you buy a dual processor PC, it will by default have dual processors and an OS that works with those processors, and software that works with those processors. The only catch is most people don't need anything more than the $800 single CPU machine they bought instead of shelling out a few grand.
>As you rightly point out, although the wintel camp have dabbled with >half-hearted attempts at SMP (not even bothering to make a chipset for the >K5!), they are not shipping SMP systems to a large portion of their customers.
What, precisely, is half-hearted about Intel's SMP support?
Yes, AMD never got chipset manufacturers onboard for OpenPIC. It's hardly suprising, given they had a tiny marketshare at the time and weren't seen as a "high performance" chip manufacturer. When they did manage to get a high performance chip on the market, with a signifigant marketshare, that changed, and now there are a myriad of options for the MP chips, including quad processor systems.
Given the difference in marketshare between MacOS and Windows, I'd be willing to bet there are MORE dual processor Intel/AMD workstations being shipped than dual processor Apple machines.
If you include the server market, there's no question about it.
>Don't forget that Apple are a long way ahead of the wintel crowd in >multi-processor department, all their medium and top spec tower machines have >been dual processor for years, and OSX is designed to take advantage of that.
Intel has done SMP since 1989, with the 486. AMD had an SMP capable chip in 1995, with the K5 (though no chipset available for it), and their latest MP spec has been available sine 2000.
Linux has done SMP for years. Windows has done SMP for years.
>That 4Ghz AMD machine will be up against a dual, or quite possibly quad 2.5 Ghz >Mac.
And that Mac in turn will up against the dual Athlon64, or quad Opteron. And with the Opteron, three seperate 6.4GB/sec buses instead of a single one.
I'm sorry, did you have a point you were trying to make?
>Serial ATA is BS. Why create a new standard? We currently have:
You know, it's hard to take someone's opinion seriously when they screw up all the figures.
>IDE (133mbit, a hack; but works well)
Not bit, byte.
>SCSI (160mbit)
Again - not bit, byte. And moreover, Ultra320 is already on the market.
>USB 2.0 (480mbit, again, a functional hack) >firewire (400mbit).
Wow, you got two right.
>Both USB 2.0 AND firewire exceed the IO of _most_ motherboards. A 32bit 33mhz >pci slot can only do about 132mbit.
Again - not bit, byte. Neither USB 2.0 nor Firewire exceed even bog standard PCI speeds. This is irrelevent in most cases anyways, as USB and firewire are hung off directly off the south bridge rather than the PCI bus.
Even if that wasn't the case, you're ignoring 64bit (266MB/sec), 66Mhz (266MB/sec), 64bit 66MHz (532MB/sec), and PCI-X (1066MB/sec).
>We don't need anything faster, or different. If anything, companies should be >getting firewire directly on drives. We don't need to be forced into a >'upgrade'.
Firewire is slower than just about every current drive interconnect, including USB 2.0, ATA/66 and above, Ultra2 and above, fiber channel, and SATA. Why on god's green earth would companies implement a slower bus?
>We have existing tech that is better. SerialATA=overpriced gear, forcing all of >your old drives, etc, into obsolesce.
How is it forcing your current drives into obsolescence? It is signal compatible with parallel ATA, so even if manufacturers drop the old interface from their motherboards, you will be able to use your old drives with a simple, cheap adapter.
>Wrappers with -resource parameters? Immediate kludge I can think of, but it'd >work. Again I question the necessity for doing this, but it's certainly an >option for the BOFHs assuming they're not interested in a simple change to the >source code or patching XLib.
Yeah, requiring non-standard X libraries is a grand solution. You've convinced me.
Locking down configuration options has a lot of uses, particular in lab or kiosk configurations.
>X's resources allow you to define any default, be it for an application, a >widget, an application's widget, a widget in a widget, or anything else. Like >this:
And its still a matter of policy, not the underlying implementation.
>Personally I can only think of the type of thing you'd find in themes, sounds, >images, that kind of thing. XML cannot do those either.
Why on god's green earth would you store the contents of an image or a soundfile inside your configuration system?
>What exactly were you trying to represent in a configuration file for an >application that required XML, couldn't be done easily with simple >keyword/value pairs, and was within the scope of XML?
I gave two examples. You commented on them later. (Just to avoid having to deal with it again, tree structures could be used for something like bookmarks as well. No other examples come to mind right now, but to say there aren't uses is short-sighted.)
>The onus here is on you: You're saying that ASCII keyword/value files must be >replaced by XML, and must be by a complicated system that maintains its own >databases, runs over network connections using additional protocols, and must >be incompatable with all that came before. What's your justification?
Actually, I said nothing of the sort. What format the backend uses is mostly inconsequential. The reasoning for the XML backend, to my recollection is primarly because people distrust binary formats, and because the parsers are already part of the platform and are used extensively through the rest of the desktop.
If you really wanted to you could write a GConf implementation that uses the XResource files for storing the settings.
As for the rest of it - yes, I think the benefits of GConf outweigh the "drawback" of being able to run on a network (using standard protocols, nonetheless) and migrating to the system (already done).
>I refer you to the comments I made earlier. GConf is unnecessarily complex,
It's honestly not that complex. Have you actually LOOKED at it?
>a switch over to an unnecessarily resource intensive method of storing >configuration files,
I tend to consider sacrificing robustness to optimize a corner case as irretrivably stupid. What applications, precisely, do you know of that spend anything but a trivial amount of time reading their configuration, even using GConf? (Keep in mind that one of the functions of gconfd is to cache settings so each application doesn't have to reread them.)
>solving non-issues through redundant technologies and whose justifications are >limited, in large part, to the desire to solve problems that cannot be solved >technologically.
Actually it solves the problems it needs to quite nicely; i.e. providing a consistent mechanism for configuration data to be stored in a process transparent manner.
>It adds nothing to GNOME, and adds further administrative hell to those who >have to maintain GNOME desktops.
Funny, but I think it's easier to administer than the older INI style files.
>No, but not every programming practice from the 1980's is bad either, and what >you appear to be saying is that you feel fully justified in ditching a >technology simply because it dates back that far.
No, I was saying that "people have been doing it that way since XXXX" isn't a justification. Nothing more, nothing less.
>I believe the onus is on the GConf people to demonstrate that the practice of >using simple, easily edited, easily understood, easily parsed, text files to >store configuration information is a bad one.
The core of GConf has nothing to do with how the data is actually stored. You keep ignoring this.
>Ok. Not exactly a reason for junking what we had already and building some >daemon-laden kludge, but it may constitute an advantage.
The main reason for a daemon is to provide caching and notification. You've yet to explain how you would do this using only XResources.
>...which under Xresources you can do both via the command line (editres) and >via library calls (XtSetValues, XtVaSetValues, etc)
That might be pertinent if GTK+ were based on XT, which it isn't. Even if it were, neither of these happens instantly and automatically when settings are changed.
>Needless to say, there is an API for getting keys. Setting keys is somewhat >less in need of an API as such, as appending a line to a plain text file has >never required anything dramatic.
And of course the only manipulation of settings that ever happens is adding a new one. Right.
>Which is a policy issue not a technological issue. Take a look in your >{XLIB}/app-defaults/ directory, and if you can find a machine with Netscape 4.7 >on it, take a look at the Netscape.ad file in its */lib/netscape/ directory, >and there's nothing really to stop someone going in more detail on any of >these.
Comments in a file listing defaults does not equate to usable documentation in a desktop environment. Perhaps a standardized format could be adopted to allow for easy retrieval of the information, and perhaps that format could have provisions for internationalization. But don't pretend that it is currently the same thing.
>None of the above shows good reason for reinventing the wheel. At best, in some >cases, there was some justification for extending XLib.
And I'm sure the X Consortium would be delighted to standardize those changes right away, and every OS vendor will immediately package up a new binary for their systems (including ones for releases done in the past five years, since we wouldn't want to count them out). Yep.
>GConf cannot be fixed. It's an ugly multimegabyte hack which owes more to >buzzword compliance than it does to solving problems.
Um, multi-megabyte? Are you going solely by the size of the unpacked archive or something? You do realize that the majority of that space is translated strings, example code, and documentation, right? If you look at the actual source code, the latest release has about 14k LOC shared, 7.1k for the backends (currently xml and bdb), 1.7k for the daemon, and 2.2k for the front end tool.
The compiled binaries take all of 338k on my system, including the libraries, daemon, and command line tools. When you come up with your proposal to get the same functionality from XResources with less code, maybe I'll take you seriously.
>XML shouldn't be used for configuration files except in a very rare set of >circumstances, because it's an unnecessarily complex format for storing very >simple data that usually comprises of little more than a set of discrete >values.
I don't necessarily disagree. I've stated the reasons for the choice of XML to the best of my recollection already.
>Programs shouldn't have to communicate with daemons to find out what colour to >paint a widget.
As I already said, the daemon allows for caching and propogation. How do you propose this be implemented otherwise?
>Programs shouldn't fail because a third party configuration system hasn't set >itself up correctly.
Yeah, just like programs shouldn't fail because a third party windowing system hasn't set itself up correctly. Or a third party networking system hasn't set itself up correctly. Et cetera, et cetera, et cetera.
>Files that are shared across a network should be accessed on conventional file >sharing systems unless there's a very good reason not to.
These aren't "files", they're settings. They may be in files, they may be in a database, they may be written on paper and typed in by a trained monkey when you request them.
>If you have the source code to a system, it makes sense to extend it if you can >to support additional features you want, rather than throw the entire thing out >and start afresh.
Well, just as soon as you get the source code to every platform that runs Gnome for the project, that might be compelling argument.
>There was never any reason to junk Xresources. A configuration system shouldn't >be as complex and bloated as GConf. It's just applications trying to get their >settings for crying out loud. It's not rocket science.
I've yet to see any compelling argument from you to convince me that just over 300k of binaries and libraries constitutes "bloat" or that an API that consists of a bunch of get and set functions is complex. Sorry. But I will send you home with a years supply of Spam and a copy of the home game.
>Locking configuration options so users can't change them? Hardly a great >advantage though a moderately competent sysdamin can indeed do that.
Since Xresource files are stuck in one big file instead of seperated out, and the entries in the users directory override system default, how do you remove the ability to edit SPECIFIC settings instead of all of them?
>As for network wide configurations: you allegation is nonsense. Configuration >files are stored in the app-defaults directory, which could easily be a network >share or just something updated through existing mechanisms such as NIS.
This doesn't work so well when dealing with, e.g. remote users on an untrusted network. Yes, there are ways of kludging around this, but I'd much rather use something like LDAP or ACAP.
>Not that I've seen, or rather, applications have to go out of their way to >support such things, looking for several different settings and deciding which >to use.
Um, settings are stored in a very easy to follow tree-structured namespace. I don't call:
going out of their way. If there is a failure here its in policy, not in the technology.
>It's obvious from the above comments that the decision was made to replicate >the registry but attempt to address its, perceived, flaws, and it's obvious >that at no point did the authors consider that Unix already had an existing >configuration system.
If you insist on ignoring the benefits, sure its obvious.
>Do you believe, incidentally, that GConf actually fixes the documentation >issues with registry keys, or that it simply hopes that by starting afresh with >a new set of applications, the far sighted intelligent programmers who write >them will make sure those damned keys are documented?
Whether the documentation is done is again a policy issue, not a design issue. My point is that it provides a mechanism for storing and retrieving documentation on keys, with proper internationalization support nonetheless.
>That's true of XML too. Have you ever written an XML parser, or tried to use a >library that provides XML parsing?
No on writing one (why would I when there are more than a few available) and yes on two.
>And, to be honest, the shortcoming I was thinking of with keyword/value files >concerned non-ascii datatypes, a problem XML has too.
What kind of non-ascii data do you expect desktop applications to need for configuration again?
>In all honesty though, you're claiming something as a solution to a problem >that isn't. GConf still imposes its own percieved ideas about how the >data should be structured. And it does it badly.
What, in particular, does it do badly?
>Oh come on! We're not comparing it to obscure binary files with indexes and >other cruft. We're comparing it to keyword/value files, like Xdefaults, like >.INI files, like what just about every programmer has been using since 1985.
Not every programming practice from the 80s is necessarily a good choice.
>Are you seriously suggesting that suddenly these have become unreadable, that >there's no base of easy to use parsing code for these any more? Half the time >it isn't even worth finding a generic routine to parse these things.
The value comes when you want to store something more complex than an atomic datatype (e.g. a list or a tree structure).
>Are you a programmer or a Buzzword Engineer? Do you have the slightest clue how >parsable these different types of file are? Do you know what a pain in the arse >XML parsing is, even given a library that supposedly does some of the work for >you?
I've only done some simple parsing, but its not all that difficult in my experience, so long as your needs are simple. Which is the case with GConf.
>Ok, WHAT'S the serious functionality that GConf gives that Xresource files >under Unix haven't got? So far, you've come up with sysadmins being able to >easily override user preferences, something most of us would suggest is an >extreme reason to completely rewrite a configuration system, replacing it with >a bloated alternative that eschews standardisation and code reuse for buzzword >compliance and bloat - I'm not even convinced it's not already in the Xresource >system.
Just to sum them up again
- an arbitrary number of configuration sources
- pluggable backends to allow different types of sources
- administrator control of what options are changable
- live notification of changes to running applications
- heirarchical namespace
- api for getting and SETTING keys
- support for documenting keys
>I'd say the problem with GConf is that it's a poor reimplementation of a system >that already existed. > >X11 always has had a consistant, centralised, configuration system, the >Xresources mechanism. This had a number of very useful features:
>* It was simple... and limited.... and lacking in a consistent method for documenting what options are available or what valid values exist.
>* Sysadmins could easily set central defaults which could be easily overridden >by users wanting to customise their own systems... with no method for locking configuration options so the users COULDN'T override.... without extensibility such that a network server could be used for storing configuration, either on a network wide or user basis.
>* You could fine tune settings so that some would apply to all apps that >recognised the same keyword, some to specific combinations of controls and >apps, and some to specific apps, as you, the user, prefered.... which is also true of gconf.
>* It was a genuinely simple configuration file format, little more than >keyword/value pairs.... and simplicity sometimes means inflexible.
There is no allowance for more complex datatypes. There is no allowance for grouping application specific resources into their own files. Et cetera, ad nauseum.
>Pretty much impossible to foul up in such a way that a minor configuration >issue would prevent all applications that use it from starting up.... which is also true of gconf, as by default it stores each applications settings in seperate files.
>* The system is implemented as part of the basic X11 libraries, meaning no >daemons running.... which doesn't allow for notification of configuration changes to running applications.
>GConf is nothing like the above. It's a bizarre reimplementation of the Windows >Registry that assumes that the only fault with the registry is that it's one >"proprietry" file.
Aside from being a unified configuration system, how is it a reimplementation of the Windows registry?
And have you bothered to read ANY of the documentation on it? Even the earliest proposals for GConf listed more drawbacks than that; e.g. lack of provision for sitewide administration and lack of documentation for registry keys.
>It fouls up easily - it took several successive installations of Galeon before >that app started to work on my machine, for instance, because GConf had some >problem with permissions on some centralised configuration file, and there was >no obvious fix to this.
A problem with one specific application, with no indication of what was really wrong, does not prove that it fouls up easily.
>The files it uses are XML,
Correction: the files for the current default backend are XML.
>which is an unnecessarily complex format for storing app settings for most >applications
Keyword here is *most*. The benefit of a unified configuration backend are lost when applications have to work around its shortcomings.
>and really offers little or no advantage over keyword/value pairs, and it's >redundant!
It's also self-documenting, and can take advantage of prexisting parsers.
>Someone one day will explain a sane reason for GConf, but right now it looks >like another symptom of the major complaint I have against Gnome - the >pointless removal of a perfectly reasonable Unix-way of doing things in favour >of a sub-optimal reimplementation of a >not-terribly-good-idea-in-the-first-place that happens to be part of the >World's Favourate Operating System.
Come up with a way to implement the functionality of GConf with Xresource files, and that sentiment might almost make sense.
>- Gconf is a minor issue, it's wrong but you can live with it.
What, precisely, is wrong? I like having a consistent configuration system.
>- Button re-ordering is crap why dont you write one line about it ? compare >where the OK CANCEL buttons are located in GNOME and look how they are in 99% of >the other apps.
Why should anyone rehash what has already been discussed to death on the GNOME mailing list?
>- Why don't you waste one line telling us why GNOME needs to pollute XFREE86 ?
Why don't you actually explain what you think is wrong with the libraries that are shared between GNOME and XFree86?
>- Why don't you waste one line about REDHAT, XIMIAN and SUN is directing GNOME >today ?
Why don't you take a grammar course? Or explain what you think is wrong with the input of commercial companies? Or explain why you discount all the developers who AREN'T from those companies?
>- Why don't you waste one line telling me why you like WINDOWS registry, GConf >IS windows registry. I can't understand why you want that.
Why don't you actually take the time to learn about a technology before having a knee jerk reaction to it?
>- Have you ever spent 1-2 years dealing with the people that work on GNOME ? If >not then do so then you realize what bunch of fucking retards they are. Why >didn't you loose one line about the kick off of Martin Baulig ?
He wasn't thrown out of the project. He was told to revert a major architectural change that he made without consulting the rest of the developers. The thread was much less cordial than it should have been, but he is not free from fault in this regard, having made statements blaming other developers of "destroying the dream of a component based GNOME", and so forth.
>* quotes #2 out of context and claims, incorrectly, that I'm ignoring the > work on improving the zone-transfer protocol;
Sorry if I quoted incorrect statements on your page.
>* claims, incorrectly, that BIND's implementation of the experimental IXFR > mechanism works (and has worked ``for years'') with hand-modified zone files;
That would explain all the IXFR transfers in my log files, of zones which are only modified by hand.
>* claims, incorrectly, that the DNSSEC architecture works without centralized >key management [cr.yp.to];
No, I made a snide remark comparing its usefulness to ssh without a centralized key authority. It can be used today in "island of trust" configurations.
>* claims, incorrectly, that scp [openssh.org] et al. are proprietary;
Where, precisely, did I make this claim? The only statement I made that I can even imagine you misconstrued as that would be:
Yep, instead of a file transfer system which leaves you tied to a specific
implementation of DNS software. I prefer zone transfers.
The reference wasn't to the software used to copy the files, merely the software used to serve them out on the other end. So far as I know, the format djbdns stores its zone data in is proprietary to djbdns.
>* claims, incorrectly, that TSIG is ``compatible'' and IPSEC isn't; and
When you're talking DNS, it is compatible, with virtually everything but djbdns. Scripts written to use IPSEC or ssh are likely to be very site dependent.
>* says that some of the disadvantages of zone transfers aren't issues for him, > as if this meant that they don't matter to anybody.
The feature I cited was automatic transfer of new zones. The point was this is sometimes UNdesirable behaviour. In other words, just because some of the disadvantages of your approach aren't issues for you doesn't mean that's true for everybody.
>Lesson for software authors: If you want to see what features are important, >watch people actually using the computer, not people speculating about how >other people use the computer. Typical speculation doesn't have much to do with >reality.
That's a lovely example of ad hominem. Thank you.
Getting back to reality though, I do "use the computer". Ironically enough a large part of my job is dealing with one of your software packages.
>NOTIFY is an optional standard. I don't support it because I have better tools >for the same thing. RTFM [cr.yp.to].
I've read your fine manual, and frankly I don't find it particularly convincing. Let's take a look at some of the claims on that page:
Instead of immediately sending new data to the slaves, you run a zone-transfer
service that accepts periodic connections from the slaves; your users complain
while they're waiting for the slaves to check for new data
That's what NOTIFY is for.
The zone-transfer protocol isn't a modular file-transfer system; it is an
ad-hoc system tied to the details of DNS.
Yep, instead of a file transfer system which leaves you tied to a specific implementation of DNS software. I prefer zone transfers.
The protocol has terrible compression and no security.
Compression I won't argue with you over, though its not a real consideration for most user's needs, particularly with IXFR.
There's only no security because you choose to discount TSIG and DNSSEC.
an experimental IXFR mechanism for incremental zone transfers (although the
BIND implementation doesn't work for zone files modified by hand or by
external tools)
It's worked for years.
BIND's May 2001 IXFR and TSIG implementations are supposedly free of the bugs
that caused crashes, data corruption, and root exploits in previous versions
of BIND
And here we are, over two years since the release of BIND 9, and there has been one native exploit, and it was in the resolver library not the server.
Now you might protest "but there has never been an exploit found in djbdns! And you're right, you're *software* is secure. On the other hand, your *solution*, which involved rsync + ssh, hasn't fared as well. In just the past year, there have been root exploits found in rsync, openssl, and openssh (arguably the more common ssh implementation), there were DDoS exploits found in each of those packages as well, and openssh had major integration issues (due to unresolved issues in their privsep code).
Just a couple things from your table that weren't really addressed above:
Automatic handling of new zones
Don't want it, don't need it. I often have slaves that I want only specific zones running on. Even in the instance that I do want a zone propogated, I prefer confirming the ACLs on the client side before making it live.
Usable for other services
I can't use djbdns to serve web traffic. It must suck. Hey, and I can't use it as a floor wax OR a non-dairy dessert topping. It must REALLY suck.
Sorry, Dan, but this, in and of itself, doesn't mean anything. Unless you expect everyone in the world to store their zone data in the same format, you NEED an implementation nuetral method of transfering it.
>Similarly, TSIG is an optional standard. I don't support it because I have >better tools for the same thing: for example, IPSEC and ssh.
At the expense of being incompatible with anyone else.
>As for DNSSEC, the protocol isn't even finished, let alone required. Basic >features are still in flux, and the system won't work without a centralized >key-management system that doesn't exist [cr.yp.to].
Yep. Just like SSH doesn't work without a centralized key management system. Right.
>Actually, that's incorrect. djbdns does implement DNS according to the >standards. Be aware, of course, that the RFCs incorrectly describe BIND-specific >implementation details as part of the standard, though, and there's no reason >for any other DNS implementor to copy those.
Sorry, just because Bernstein rationalizes things as "not standard" doesn't mean that they aren't. Djbdns fails to support things like NOTIFY, TSIG, and DNSSEC which are, in fact, implemented by a lot more than just BIND (hell, even MS DNS supports them all).
Likewise with qmail - TLS, Auth, DSNs, MDNs - all missing from qmail, but present in most major MTAs.
> Another factor, IMO, is the seeming death of the theme album. I ask this > question with all honesty: is there anything from the 90's and later that is > equivalent to Sgt. Pepper, Abbey Road, The Wall, and Bat Out of Hell? I'm open > to expand my contemporary music tastes here -- let the titles fly.
Try Marilyn Manson. Or "Scenes From A Memory" by Dream Theater. Or even Eminem.
>Cool! Wake me up when they come out with 100GB >backup drives.
You want to be woken up in 1999? Sorry, you'll have to wait until I invent a time machine. How about I just wake you up when the 200GB native LTO cartidges come out next year?
>Linux still suffers from the "let's throw files in >places that only a seasoned unix user will think >to look for them" mentality that is standard with >all Unix workalikes, and the commercial industry >still touches on it with a bit of uncertainty and >a whole lot of fear.
Um, modern distributions "suffer" from the "let's throw files in standard locations, which are actually pretty to learn even if you're not already familiar with them, and besides, the package manager can list the files for a particular program, so you can easily find them even if you're completely clueless."
>Of course there is a commandline too. It is the >only OS that has the following commandline >command: > >> list all files since yesterday > >(list = ls, all = -R, files = don't show >directories, since yesterday = only files since a >certain date);-)
>Both of the Mbus modules in my SparcStation 10 >have 1 meg of cache on them. I paid under $10 for >the second one on eBay that I plugged in last >week. And SMP is up and running fine on >NetBSD/Sparc, you just have to compile an SMP >kernal.
Yeah, my SS10 has SuperSPARC processors as well. The cache helps on certain applications, but overall the system is pretty slow. The systems with HyperSPARC modules, which have less cache (256k) actually tend to run signifigantly faster on most applications (since they're clocked higher and have superior FPUs).
My Ultra 1/170E actually performs pretty well, and these systems can be picked up really cheap. The integer performance is about analagous to a P-233MMX, but the floating point performance wasn't matched until the PII/350. These machines also have a UPA slot, which is downright speedy (1GB/sec).
>Any IPC/IPX will run circles in IO performace >next to a pentiumII.
You are seriously misinformed.
Sun used a bus called "mbus" for the main system bus (all the cpus, the memory controller, and southbridge sat on it) which ran at a peak speed of 50MHz in 64bit mode. The sustained throughput was typically from 80-140MB/sec. The expansion bus ("sbus") ran anywhere from 20-50MHz, and even in 64 bit configurations couldn't push more than 120MB/sec. Mind you the IPC and IPX sported a 32 bit bus running at 25MHz and 20MHz, respectively.
The Pentium II was originally introduced with a 66MHz bus which had approximately 528MB/sec worth of bandwidth, and the move to a 100MHz front side bus pushed it to 800MB/sec. The PCI bus of the time (32 bit, 33MHz) had a maximum throughput of 133MB/sec.
>By the time you get done buying all the parts for >your high end x86 solaris server with an adaptec >29160, 5 drive array, 2 gigs of ram, and a 2 >gigahertz processor you could have bought a >modern sun for the same price with half the ram >and half the processor speed, but three times the >memory and disk IO so it really evens out.
The Pentium IV or Xeon can push 4.2GB/sec over the 533MHz bus, or 3.2GB/sec over the 400MHz bus. The Fireplane interconnect used in the new UltraSparc IIIcu systems runs at 4.8GB/sec, and the older UltraSparc II processors that are used in the more affordable systems (e.g. V100, V120, 220R, 420R, etc) max out at 1.92GB/sec.
As for disk IO, that's a function of the expansion bus, chipsets, and drives. Even the highest end Sun machines are using the same 64bit, 66MHz PCI slots as everyone else, and their controller chipsets and drives are OEMed from the same exact companies PC manufacturers use.
Even if your claims WERE true and disk and memory IO *were* that much higher on Sun hardware, you'd probably find performance was as slow, if not slower, than the PC with more memory. It doesn't help you to have extra bandwidth if you end up using it to shunt data back and forth to drives when you could have had it all sitting in memory in the first place.
The Debian package format was introduced in 1995. The RPM package format was introduced in... 1995.
In terms of age they are pretty well matched. Red Hat was a growth of several other earlier package managers (RPP, PMS, PM) which may have made the transition a bit easier.
Probably the biggest thing Red Hat had going for it is that Caldera providing some of the funding for the initial development. In other words, it was multi-distribution from the start, whereas Debian for a long time was proprietary to their distribution (yes, I realize there are now several Debian based distributions out there).
Slashdot Mirror
> While it might seem from the Linux side of the fence that there isn't anything
> else but Linux and Windows, the *BSD family is big and growing. BSDI is just
> one part. FreeBSD is probably the biggest completely open source BSD, with the
> very prolific NetBSD and rock solidly secure OpenBSD being contenders. And not
> to forget that Apple's MacOS X core, Darwin is mixed Mach and FreeBSD.
Actually, I specifically said "commercial", which doesn't include FreeBSD/NetBSD/OpenBSD (since FreeBSD is no longer affiliated with a commercial company, AFAIK). I *did* forget to mention MacOS X which implements a BSD compatibility layer on top of the Mach kernel, which would qualify.
Matt
>Posix.. DEC's version of Unix, whatever it was called, I don't remember. Anyone
>remember Ultrix, by Sun Microsystems? There are scores of others.. This whole
>lawsuit is just stupid.. as is SCO. Although, I did enjoy using Xenix for a
>while.
You seem to be a bit confused. POSIX is the portable operating system standard. ULTRIX was the Digital version of Unix for its MIPS based line of workstations. They also sold DEC OSF/1, which was later rebranded as Digital UNIX, and then rebranded againt to Tru64 when Compaq aquired DEC.
Sun originally started selling its UNIX as SunOS, which was later rebranded as Solaris when they moved from a BSD core to a SYSV core. They also sold Interactive Unix after aquiring Interactive System's Intel UNIX business.
The "trump card" that SCO thinks it holds is that they own SVR5, which is the decendent of the original AT&T UNIX. Most commercial implementations of UNIX, aside from the BSD descendents (pretty much just BSDI at this point) contain licensed System V code (e.g. Solaris is based on SVR4, HP/UX is based on SVR3, etc). Given that the lawsuit if focusing on Linux, and Linux contains none of this copyrighted code, this is pretty much irrelevent. The entire basis of their case is alleged trade secret and contract violations, along with the unfair competition claim.
They do *not* hold the trademark as the parent claimed. The trademark was originally held by AT&T, who deeded it to USL when that was formed. Novell aquired USL and the UNIX trademark along with it, and then turned around and granted exclusive licence rights to X/Open. The trademark was later granted entirely to X/Open, and finally X/Open became part of The Open Group, who is the current trademark holder.
>If you buy anything but the cheapest tower Mac, it will BY DEFAULT have dual
>processors, an OS that works with those processors, and software that works
>with those processors.
One of the big reasons why this is the case is because Apple NEEDS dual processor to keep even somewhat competitive with the intel world.
If you buy a dual processor PC, it will by default have dual processors and an OS that works with those processors, and software that works with those processors. The only catch is most people don't need anything more than the $800 single CPU machine they bought instead of shelling out a few grand.
>As you rightly point out, although the wintel camp have dabbled with
>half-hearted attempts at SMP (not even bothering to make a chipset for the
>K5!), they are not shipping SMP systems to a large portion of their customers.
What, precisely, is half-hearted about Intel's SMP support?
Yes, AMD never got chipset manufacturers onboard for OpenPIC. It's hardly suprising, given they had a tiny marketshare at the time and weren't seen as a "high performance" chip manufacturer. When they did manage to get a high performance chip on the market, with a signifigant marketshare, that changed, and now there are a myriad of options for the MP chips, including quad processor systems.
Given the difference in marketshare between MacOS and Windows, I'd be willing to bet there are MORE dual processor Intel/AMD workstations being shipped than dual processor Apple machines.
If you include the server market, there's no question about it.
>Don't forget that Apple are a long way ahead of the wintel crowd in
>multi-processor department, all their medium and top spec tower machines have
>been dual processor for years, and OSX is designed to take advantage of that.
Intel has done SMP since 1989, with the 486. AMD had an SMP capable chip in 1995, with the K5 (though no chipset available for it), and their latest MP spec has been available sine 2000.
Linux has done SMP for years. Windows has done SMP for years.
>That 4Ghz AMD machine will be up against a dual, or quite possibly quad 2.5 Ghz
>Mac.
And that Mac in turn will up against the dual Athlon64, or quad Opteron. And with the Opteron, three seperate 6.4GB/sec buses instead of a single one.
I'm sorry, did you have a point you were trying to make?
>That's a window manager, not a desktop.
Funny, the author disagrees with you:
XFce is a lightweight desktop environment for various UNIX systems.
The window manager (XFwm) is only a component of the entire package.
Matt
>Look at colorForth [colorforth.com] for a modern conception of FORTH; from the
>original creator of FORTH, Chuck Moore.
Great, a programming language that 8% of the male population can't use. Primo idea. Really.
Matt
>find /documents/work -name \*.txt -exec grep -Hi novell {} \;
/documents/work -name \*.txt | xargs grep -Hi novell
/documents/work -name \*.txt -print0 | xargs -0 grep -Hi novell
That executes grep on every file individually. I prefer:
find
Or, to be a bit safer, in case there are embedded spaces in the filename:
find
You can likely drop the -H too, since more likely than not \*.txt is going to match more than one file.
Matt
>Serial ATA is BS. Why create a new standard? We currently have:
You know, it's hard to take someone's opinion seriously when they screw up all the figures.
>IDE (133mbit, a hack; but works well)
Not bit, byte.
>SCSI (160mbit)
Again - not bit, byte. And moreover, Ultra320 is already on the market.
>USB 2.0 (480mbit, again, a functional hack)
>firewire (400mbit).
Wow, you got two right.
>Both USB 2.0 AND firewire exceed the IO of _most_ motherboards. A 32bit 33mhz
>pci slot can only do about 132mbit.
Again - not bit, byte. Neither USB 2.0 nor Firewire exceed even bog standard PCI speeds. This is irrelevent in most cases anyways, as USB and firewire are hung off directly off the south bridge rather than the PCI bus.
Even if that wasn't the case, you're ignoring 64bit (266MB/sec), 66Mhz (266MB/sec), 64bit 66MHz (532MB/sec), and PCI-X (1066MB/sec).
>We don't need anything faster, or different. If anything, companies should be
>getting firewire directly on drives. We don't need to be forced into a
>'upgrade'.
Firewire is slower than just about every current drive interconnect, including USB 2.0, ATA/66 and above, Ultra2 and above, fiber channel, and SATA. Why on god's green earth would companies implement a slower bus?
>We have existing tech that is better. SerialATA=overpriced gear, forcing all of
>your old drives, etc, into obsolesce.
How is it forcing your current drives into obsolescence? It is signal compatible with parallel ATA, so even if manufacturers drop the old interface from their motherboards, you will be able to use your old drives with a simple, cheap adapter.
Matt
>Wrappers with -resource parameters? Immediate kludge I can think of, but it'd
>work. Again I question the necessity for doing this, but it's certainly an
>option for the BOFHs assuming they're not interested in a simple change to the
>source code or patching XLib.
Yeah, requiring non-standard X libraries is a grand solution. You've convinced me.
Locking down configuration options has a lot of uses, particular in lab or kiosk configurations.
>X's resources allow you to define any default, be it for an application, a
>widget, an application's widget, a widget in a widget, or anything else. Like
>this:
And its still a matter of policy, not the underlying implementation.
>Personally I can only think of the type of thing you'd find in themes, sounds,
>images, that kind of thing. XML cannot do those either.
Why on god's green earth would you store the contents of an image or a soundfile inside your configuration system?
>What exactly were you trying to represent in a configuration file for an
>application that required XML, couldn't be done easily with simple
>keyword/value pairs, and was within the scope of XML?
I gave two examples. You commented on them later. (Just to avoid having to deal with it again, tree structures could be used for something like bookmarks as well. No other examples come to mind right now, but to say there aren't uses is short-sighted.)
>The onus here is on you: You're saying that ASCII keyword/value files must be
>replaced by XML, and must be by a complicated system that maintains its own
>databases, runs over network connections using additional protocols, and must
>be incompatable with all that came before. What's your justification?
Actually, I said nothing of the sort. What format the backend uses is mostly inconsequential. The reasoning for the XML backend, to my recollection is primarly because people distrust binary formats, and because the parsers are already part of the platform and are used extensively through the rest of the desktop.
If you really wanted to you could write a GConf implementation that uses the XResource files for storing the settings.
As for the rest of it - yes, I think the benefits of GConf outweigh the "drawback" of being able to run on a network (using standard protocols, nonetheless) and migrating to the system (already done).
>I refer you to the comments I made earlier. GConf is unnecessarily complex,
It's honestly not that complex. Have you actually LOOKED at it?
>a switch over to an unnecessarily resource intensive method of storing
>configuration files,
I tend to consider sacrificing robustness to optimize a corner case as irretrivably stupid. What applications, precisely, do you know of that spend anything but a trivial amount of time reading their configuration, even using GConf? (Keep in mind that one of the functions of gconfd is to cache settings so each application doesn't have to reread them.)
>solving non-issues through redundant technologies and whose justifications are
>limited, in large part, to the desire to solve problems that cannot be solved
>technologically.
Actually it solves the problems it needs to quite nicely; i.e. providing a consistent mechanism for configuration data to be stored in a process transparent manner.
>It adds nothing to GNOME, and adds further administrative hell to those who
>have to maintain GNOME desktops.
Funny, but I think it's easier to administer than the older INI style files.
>No, but not every programming practice from the 1980's is bad either, and what
>you appear to be saying is that you feel fully justified in ditching a
>technology simply because it dates back that far.
No, I was saying that "people have been doing it that way since XXXX" isn't a justification. Nothing more, nothing less.
>I believe the onus is on the GConf people to demonstrate that the practice of
>using simple, easily edited, easily understood, easily parsed, text files to
>store configuration information is a bad one.
The core of GConf has nothing to do with how the data is actually stored. You keep ignoring this.
>Ok. Not exactly a reason for junking what we had already and building some
>daemon-laden kludge, but it may constitute an advantage.
The main reason for a daemon is to provide caching and notification. You've yet to explain how you would do this using only XResources.
>...which under Xresources you can do both via the command line (editres) and
>via library calls (XtSetValues, XtVaSetValues, etc)
That might be pertinent if GTK+ were based on XT, which it isn't. Even if it were, neither of these happens instantly and automatically when settings are changed.
>Needless to say, there is an API for getting keys. Setting keys is somewhat
>less in need of an API as such, as appending a line to a plain text file has
>never required anything dramatic.
And of course the only manipulation of settings that ever happens is adding a new one. Right.
>Which is a policy issue not a technological issue. Take a look in your
>{XLIB}/app-defaults/ directory, and if you can find a machine with Netscape 4.7
>on it, take a look at the Netscape.ad file in its */lib/netscape/ directory,
>and there's nothing really to stop someone going in more detail on any of
>these.
Comments in a file listing defaults does not equate to usable documentation in a desktop environment. Perhaps a standardized format could be adopted
to allow for easy retrieval of the information, and perhaps that format could have provisions for internationalization. But don't pretend that it is currently the same thing.
>None of the above shows good reason for reinventing the wheel. At best, in some
>cases, there was some justification for extending XLib.
And I'm sure the X Consortium would be delighted to standardize those changes right away, and every OS vendor will immediately package up a new binary
for their systems (including ones for releases done in the past five years, since we wouldn't want to count them out). Yep.
>GConf cannot be fixed. It's an ugly multimegabyte hack which owes more to
>buzzword compliance than it does to solving problems.
Um, multi-megabyte? Are you going solely by the size of the unpacked archive or something? You do realize that the majority of that space is translated strings, example code, and documentation, right? If you look at the actual source code, the latest release has about 14k LOC shared, 7.1k for the backends (currently xml and bdb), 1.7k for the daemon, and 2.2k for the front end tool.
The compiled binaries take all of 338k on my system, including the libraries, daemon, and command line tools. When you come up with your proposal to get the same functionality from XResources with less code, maybe I'll take you seriously.
>XML shouldn't be used for configuration files except in a very rare set of
>circumstances, because it's an unnecessarily complex format for storing very
>simple data that usually comprises of little more than a set of discrete
>values.
I don't necessarily disagree. I've stated the reasons for the choice of XML to the best of my recollection already.
>Programs shouldn't have to communicate with daemons to find out what colour to
>paint a widget.
As I already said, the daemon allows for caching and propogation. How do you propose this be implemented otherwise?
>Programs shouldn't fail because a third party configuration system hasn't set
>itself up correctly.
Yeah, just like programs shouldn't fail because a third party windowing system hasn't set itself up correctly. Or a third party networking system hasn't set itself up correctly. Et cetera, et cetera, et cetera.
>Files that are shared across a network should be accessed on conventional file
>sharing systems unless there's a very good reason not to.
These aren't "files", they're settings. They may be in files, they may be in a database, they may be written on paper and typed in by a trained monkey when you request them.
>If you have the source code to a system, it makes sense to extend it if you can
>to support additional features you want, rather than throw the entire thing out
>and start afresh.
Well, just as soon as you get the source code to every platform that runs Gnome for the project, that might be compelling argument.
>There was never any reason to junk Xresources. A configuration system shouldn't
>be as complex and bloated as GConf. It's just applications trying to get their
>settings for crying out loud. It's not rocket science.
I've yet to see any compelling argument from you to convince me that just over 300k of binaries and libraries constitutes "bloat" or that an API that consists of a bunch of get and set functions is complex. Sorry. But I will send you home with a years supply of Spam and a copy of the home game.
Matt
>Locking configuration options so users can't change them? Hardly a great
>advantage though a moderately competent sysdamin can indeed do that.
Since Xresource files are stuck in one big file instead of seperated out, and the entries in the users directory override system default, how do you remove the ability to edit SPECIFIC settings instead of all of them?
>As for network wide configurations: you allegation is nonsense. Configuration
>files are stored in the app-defaults directory, which could easily be a network
>share or just something updated through existing mechanisms such as NIS.
This doesn't work so well when dealing with, e.g. remote users on an untrusted network. Yes, there are ways of kludging around this, but I'd much rather use something like LDAP or ACAP.
>Not that I've seen, or rather, applications have to go out of their way to
>support such things, looking for several different settings and deciding which
>to use.
Um, settings are stored in a very easy to follow tree-structured namespace. I don't call:
gconf_client_get_string (client, "/gnome/foo/bar")
going out of their way. If there is a failure here its in policy, not in the technology.
>It's obvious from the above comments that the decision was made to replicate >the registry but attempt to address its, perceived, flaws, and it's obvious
>that at no point did the authors consider that Unix already had an existing
>configuration system.
If you insist on ignoring the benefits, sure its obvious.
>Do you believe, incidentally, that GConf actually fixes the documentation
>issues with registry keys, or that it simply hopes that by starting afresh with
>a new set of applications, the far sighted intelligent programmers who write
>them will make sure those damned keys are documented?
Whether the documentation is done is again a policy issue, not a design issue. My point is that it provides a mechanism for storing and retrieving documentation on keys, with proper internationalization support nonetheless.
>That's true of XML too. Have you ever written an XML parser, or tried to use a
>library that provides XML parsing?
No on writing one (why would I when there are more than a few available) and yes on two.
>And, to be honest, the shortcoming I was thinking of with keyword/value files
>concerned non-ascii datatypes, a problem XML has too.
What kind of non-ascii data do you expect desktop applications to need for configuration again?
>In all honesty though, you're claiming something as a solution to a problem
>that isn't. GConf still imposes its own percieved ideas about how the
>data should be structured. And it does it badly.
What, in particular, does it do badly?
>Oh come on! We're not comparing it to obscure binary files with indexes and
>other cruft. We're comparing it to keyword/value files, like Xdefaults, like
>.INI files, like what just about every programmer has been using since 1985.
Not every programming practice from the 80s is necessarily a good choice.
>Are you seriously suggesting that suddenly these have become unreadable, that
>there's no base of easy to use parsing code for these any more? Half the time
>it isn't even worth finding a generic routine to parse these things.
The value comes when you want to store something more complex than an atomic datatype (e.g. a list or a tree structure).
>Are you a programmer or a Buzzword Engineer? Do you have the slightest clue how
>parsable these different types of file are? Do you know what a pain in the arse
>XML parsing is, even given a library that supposedly does some of the work for
>you?
I've only done some simple parsing, but its not all that difficult in my experience, so long as your needs are simple. Which is the case with GConf.
>Ok, WHAT'S the serious functionality that GConf gives that Xresource files
>under Unix haven't got? So far, you've come up with sysadmins being able to
>easily override user preferences, something most of us would suggest is an
>extreme reason to completely rewrite a configuration system, replacing it with
>a bloated alternative that eschews standardisation and code reuse for buzzword
>compliance and bloat - I'm not even convinced it's not already in the Xresource
>system.
Just to sum them up again
- an arbitrary number of configuration sources
- pluggable backends to allow different types of sources
- administrator control of what options are changable
- live notification of changes to running applications
- heirarchical namespace
- api for getting and SETTING keys
- support for documenting keys
Et cetera blah blah and so on and yadda yadda...
Matt
>I'd say the problem with GConf is that it's a poor reimplementation of a system
... and limited. ... and lacking in a consistent method for documenting what options are available or what valid values exist.
... with no method for locking configuration options so the users COULDN'T override. ... without extensibility such that a network server could be used for storing configuration, either on a network wide or user basis.
... which is also true of gconf.
... and simplicity sometimes means inflexible.
... which is also true of gconf, as by default it stores each applications settings in seperate files.
... which doesn't allow for notification of configuration changes to running applications.
>that already existed.
>
>X11 always has had a consistant, centralised, configuration system, the
>Xresources mechanism. This had a number of very useful features:
>* It was simple
>* Sysadmins could easily set central defaults which could be easily overridden
>by users wanting to customise their own systems
>* You could fine tune settings so that some would apply to all apps that
>recognised the same keyword, some to specific combinations of controls and
>apps, and some to specific apps, as you, the user, prefered.
>* It was a genuinely simple configuration file format, little more than
>keyword/value pairs.
There is no allowance for more complex datatypes. There is no allowance for grouping application specific resources into their own files. Et cetera, ad nauseum.
>Pretty much impossible to foul up in such a way that a minor configuration
>issue would prevent all applications that use it from starting up.
>* The system is implemented as part of the basic X11 libraries, meaning no
>daemons running.
>GConf is nothing like the above. It's a bizarre reimplementation of the Windows
>Registry that assumes that the only fault with the registry is that it's one
>"proprietry" file.
Aside from being a unified configuration system, how is it a reimplementation of the Windows registry?
And have you bothered to read ANY of the documentation on it? Even the earliest proposals for GConf listed more drawbacks than that; e.g. lack of provision for sitewide administration and lack of documentation for registry keys.
>It fouls up easily - it took several successive installations of Galeon before
>that app started to work on my machine, for instance, because GConf had some
>problem with permissions on some centralised configuration file, and there was
>no obvious fix to this.
A problem with one specific application, with no indication of what was really wrong, does not prove that it fouls up easily.
>The files it uses are XML,
Correction: the files for the current default backend are XML.
>which is an unnecessarily complex format for storing app settings for most
>applications
Keyword here is *most*. The benefit of a unified configuration backend are lost when applications have to work around its shortcomings.
>and really offers little or no advantage over keyword/value pairs, and it's
>redundant!
It's also self-documenting, and can take advantage of prexisting parsers.
>Someone one day will explain a sane reason for GConf, but right now it looks
>like another symptom of the major complaint I have against Gnome - the
>pointless removal of a perfectly reasonable Unix-way of doing things in favour
>of a sub-optimal reimplementation of a
>not-terribly-good-idea-in-the-first-place that happens to be part of the
>World's Favourate Operating System.
Come up with a way to implement the functionality of GConf with Xresource files, and that sentiment might almost make sense.
Matt
>- Gconf is a minor issue, it's wrong but you can live with it.
What, precisely, is wrong? I like having a consistent configuration system.
>- Button re-ordering is crap why dont you write one line about it ? compare
>where the OK CANCEL buttons are located in GNOME and look how they are in 99% of
>the other apps.
Why should anyone rehash what has already been discussed to death on the GNOME mailing list?
>- Why don't you waste one line telling us why GNOME needs to pollute XFREE86 ?
Why don't you actually explain what you think is wrong with the libraries that are shared between GNOME and XFree86?
>- Why don't you waste one line about REDHAT, XIMIAN and SUN is directing GNOME
>today ?
Why don't you take a grammar course? Or explain what you think is wrong with the input of commercial companies? Or explain why you discount all the developers who AREN'T from those companies?
>- Why don't you waste one line telling me why you like WINDOWS registry, GConf
>IS windows registry. I can't understand why you want that.
Why don't you actually take the time to learn about a technology before having a knee jerk reaction to it?
>- Have you ever spent 1-2 years dealing with the people that work on GNOME ? If
>not then do so then you realize what bunch of fucking retards they are. Why
>didn't you loose one line about the kick off of Martin Baulig ?
He wasn't thrown out of the project. He was told to revert a major architectural change that he made without consulting the rest of the developers. The thread was much less cordial than it should have been, but he is not free from fault in this regard, having made statements blaming other developers of "destroying the dream of a component based GNOME", and so forth.
Matt
>* quotes #2 out of context and claims, incorrectly, that I'm ignoring the
> work on improving the zone-transfer protocol;
Sorry if I quoted incorrect statements on your page.
>* claims, incorrectly, that BIND's implementation of the experimental IXFR
> mechanism works (and has worked ``for years'') with hand-modified zone files;
That would explain all the IXFR transfers in my log files, of zones which are only modified by hand.
>* claims, incorrectly, that the DNSSEC architecture works without centralized
>key management [cr.yp.to];
No, I made a snide remark comparing its usefulness to ssh without a centralized key authority. It can be used today in "island of trust" configurations.
>* claims, incorrectly, that scp [openssh.org] et al. are proprietary;
Where, precisely, did I make this claim? The only statement I made that I can even imagine you misconstrued as that would be:
Yep, instead of a file transfer system which leaves you tied to a specific
implementation of DNS software. I prefer zone transfers.
The reference wasn't to the software used to copy the files, merely the software used to serve them out on the other end. So far as I know, the format djbdns stores its zone data in is proprietary to djbdns.
>* claims, incorrectly, that TSIG is ``compatible'' and IPSEC isn't; and
When you're talking DNS, it is compatible, with virtually everything but djbdns. Scripts written to use IPSEC or ssh are likely to be very site dependent.
>* says that some of the disadvantages of zone transfers aren't issues for him,
> as if this meant that they don't matter to anybody.
The feature I cited was automatic transfer of new zones. The point was this is sometimes UNdesirable behaviour. In other words, just because some of the disadvantages of your approach aren't issues for you doesn't mean that's true for everybody.
>Lesson for software authors: If you want to see what features are important,
>watch people actually using the computer, not people speculating about how
>other people use the computer. Typical speculation doesn't have much to do with
>reality.
That's a lovely example of ad hominem. Thank you.
Getting back to reality though, I do "use the computer". Ironically enough a large part of my job is dealing with one of your software packages.
Matt
>NOTIFY is an optional standard. I don't support it because I have better tools
>for the same thing. RTFM [cr.yp.to].
I've read your fine manual, and frankly I don't find it particularly convincing. Let's take a look at some of the claims on that page:
Instead of immediately sending new data to the slaves, you run a zone-transfer
service that accepts periodic connections from the slaves; your users complain
while they're waiting for the slaves to check for new data
That's what NOTIFY is for.
The zone-transfer protocol isn't a modular file-transfer system; it is an
ad-hoc system tied to the details of DNS.
Yep, instead of a file transfer system which leaves you tied to a specific implementation of DNS software. I prefer zone transfers.
The protocol has terrible compression and no security.
Compression I won't argue with you over, though its not a real consideration for most user's needs, particularly with IXFR.
There's only no security because you choose to discount TSIG and DNSSEC.
an experimental IXFR mechanism for incremental zone transfers (although the
BIND implementation doesn't work for zone files modified by hand or by
external tools)
It's worked for years.
BIND's May 2001 IXFR and TSIG implementations are supposedly free of the bugs
that caused crashes, data corruption, and root exploits in previous versions
of BIND
And here we are, over two years since the release of BIND 9, and there has been one native exploit, and it was in the resolver library not the server.
Now you might protest "but there has never been an exploit found in djbdns! And you're right, you're *software* is secure. On the other hand, your *solution*, which involved rsync + ssh, hasn't fared as well. In just the past year, there have been root exploits found in rsync, openssl, and openssh (arguably the more common ssh implementation), there were DDoS exploits found in each of those packages as well, and openssh had major integration issues (due to unresolved issues in their privsep code).
Just a couple things from your table that weren't really addressed above:
Automatic handling of new zones
Don't want it, don't need it. I often have slaves that I want only specific zones running on. Even in the instance that I do want a zone propogated, I prefer confirming the ACLs on the client side before making it live.
Usable for other services
I can't use djbdns to serve web traffic. It must suck. Hey, and I can't use it as a floor wax OR a non-dairy dessert topping. It must REALLY suck.
Sorry, Dan, but this, in and of itself, doesn't mean anything. Unless you expect everyone in the world to store their zone data in the same format, you NEED an implementation nuetral method of transfering it.
>Similarly, TSIG is an optional standard. I don't support it because I have
>better tools for the same thing: for example, IPSEC and ssh.
At the expense of being incompatible with anyone else.
>As for DNSSEC, the protocol isn't even finished, let alone required. Basic
>features are still in flux, and the system won't work without a centralized
>key-management system that doesn't exist [cr.yp.to].
Yep. Just like SSH doesn't work without a centralized key management system. Right.
Matt
>Actually, that's incorrect. djbdns does implement DNS according to the
>standards. Be aware, of course, that the RFCs incorrectly describe BIND-specific
>implementation details as part of the standard, though, and there's no reason
>for any other DNS implementor to copy those.
Sorry, just because Bernstein rationalizes things as "not standard" doesn't mean that they aren't. Djbdns fails to support things like NOTIFY, TSIG, and DNSSEC which are, in fact, implemented by a lot more than just BIND (hell, even MS DNS supports them all).
Likewise with qmail - TLS, Auth, DSNs, MDNs - all missing from qmail, but present in most major MTAs.
Matt
>Oh come on. If something works well and implements the standards, why should you
>bother to add more gimmicks? "If it ain't broke, don't fix it."
The problem is that Bernstein DOESN'T implement the standards. He appears to think he's above them.
Matt
> Another factor, IMO, is the seeming death of the theme album. I ask this
> question with all honesty: is there anything from the 90's and later that is
> equivalent to Sgt. Pepper, Abbey Road, The Wall, and Bat Out of Hell? I'm open
> to expand my contemporary music tastes here -- let the titles fly.
Try Marilyn Manson. Or "Scenes From A Memory" by Dream Theater. Or even Eminem.
Matt
>Cool! Wake me up when they come out with 100GB
>backup drives.
You want to be woken up in 1999? Sorry, you'll have to wait until I invent a time machine. How about I just wake you up when the 200GB native LTO cartidges come out next year?
Matt
>Linux still suffers from the "let's throw files in
>places that only a seasoned unix user will think
>to look for them" mentality that is standard with
>all Unix workalikes, and the commercial industry
>still touches on it with a bit of uncertainty and
>a whole lot of fear.
Um, modern distributions "suffer" from the "let's throw files in standard locations, which are actually pretty to learn even if you're not already familiar with them, and besides, the package manager can list the files for a particular program, so you can easily find them even if you're completely clueless."
Matt
>Of course there is a commandline too. It is the ;-)
>only OS that has the following commandline
>command:
>
>> list all files since yesterday
>
>(list = ls, all = -R, files = don't show
>directories, since yesterday = only files since a
>certain date)
find . -type f -ctime -1
Matt
Learn to name files with the proper extension
./a.out
$ cat source.c
> main(){
> printf("My computer is %d bits\n", sizeof(int)\
* 8);
> }
> !
$ gcc source.c
$
My computer is 32 bits
Matt
>Both of the Mbus modules in my SparcStation 10
>have 1 meg of cache on them. I paid under $10 for
>the second one on eBay that I plugged in last
>week. And SMP is up and running fine on
>NetBSD/Sparc, you just have to compile an SMP
>kernal.
Yeah, my SS10 has SuperSPARC processors as well. The cache helps on certain applications, but overall the system is pretty slow. The systems with HyperSPARC modules, which have less cache (256k) actually tend to run signifigantly faster on most applications (since they're clocked higher and have superior FPUs).
My Ultra 1/170E actually performs pretty well, and these systems can be picked up really cheap. The integer performance is about analagous to a P-233MMX, but the floating point performance wasn't matched until the PII/350. These machines also have a UPA slot, which is downright speedy (1GB/sec).
Matt
>It is cheaper and it is Solaris.
>
>RH has a price of $149.95
Or it has a price of $39.95 (http://www.redhat.com/software/linux/personal/).
Or it has a price of $0.00 (ftp://ftp.redhat.com/pub/redhat/linux/8.0/).
>so I don't see any price advantage for Linux.
Still not seeing the price advantage?
Matt
>Any IPC/IPX will run circles in IO performace
>next to a pentiumII.
You are seriously misinformed.
Sun used a bus called "mbus" for the main system bus (all the cpus, the memory controller, and southbridge sat on it) which ran at a peak speed of 50MHz in 64bit mode. The sustained throughput was typically from 80-140MB/sec. The expansion bus ("sbus") ran anywhere from 20-50MHz, and even in 64 bit configurations couldn't push more than 120MB/sec. Mind you the IPC and IPX sported a 32 bit bus running at 25MHz and 20MHz, respectively.
The Pentium II was originally introduced with a 66MHz bus which had approximately 528MB/sec worth of bandwidth, and the move to a 100MHz front side bus pushed it to 800MB/sec. The PCI bus of the time (32 bit, 33MHz) had a maximum throughput of 133MB/sec.
>By the time you get done buying all the parts for
>your high end x86 solaris server with an adaptec
>29160, 5 drive array, 2 gigs of ram, and a 2
>gigahertz processor you could have bought a
>modern sun for the same price with half the ram
>and half the processor speed, but three times the
>memory and disk IO so it really evens out.
The Pentium IV or Xeon can push 4.2GB/sec over the 533MHz bus, or 3.2GB/sec over the 400MHz bus. The Fireplane interconnect used in the new UltraSparc IIIcu systems runs at 4.8GB/sec, and the older UltraSparc II processors that are used in the more affordable systems (e.g. V100, V120, 220R, 420R, etc) max out at 1.92GB/sec.
As for disk IO, that's a function of the expansion bus, chipsets, and drives. Even the highest end Sun machines are using the same 64bit, 66MHz PCI slots as everyone else, and their controller chipsets and drives are OEMed from the same exact companies PC manufacturers use.
Even if your claims WERE true and disk and memory IO *were* that much higher on Sun hardware, you'd probably find performance was as slow, if not slower, than the PC with more memory. It doesn't help you to have extra bandwidth if you end up using it to shunt data back and forth to drives when you could have had it all sitting in memory in the first place.
Matt
The Debian package format was introduced in 1995. The RPM package format was introduced in... 1995.
In terms of age they are pretty well matched. Red Hat was a growth of several other earlier package managers (RPP, PMS, PM) which may have made the transition a bit easier.
Probably the biggest thing Red Hat had going for it is that Caldera providing some of the funding for the initial development. In other words, it was multi-distribution from the start, whereas Debian for a long time was proprietary to their distribution (yes, I realize there are now several Debian based distributions out there).
Matt