Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
> The problem is if you have data that is large > enough that you cannot tile the windows and they > have to overlap. Try working with 2048x1556 > images in the special effects industry and you > will know that this is not an unrealistic > scenario.
In other words you have somewhat peculilar requirements that make a particular type of interface less useful to you. This does not extend to "focus follows mouse is inherinetly superior and more innovative".
> And this is not a problem with just multiple > images, most programs have an extremely large > control panel and you cannot mess with it > because, raising it necessarily hides the image > you are working on!
Most programs? The majority of programs I work with have at most a menubar and a toolbar. The toolbars can be universally turned off, and often can have the menubar turned off. Other, such as Gimp or Glade, have multiple control windows, but they're set as toplevel, so raising them has no effect on other windows.
In other words, you're looking at things with blinders; i.e. your own experiences and the applications that you work with.
> Basically the problem is that you are using data > that is small enough that you can tile the > screen. When windows are arranged this way, > there is no difference between click-raise and > click-does-nothing.
Actually, I often use data that is too large to tile. In those instances I use keybindings to switch between windows. The only time this becomes insufficient and I tile is when I specifically need to see both data sets simultaneously, which wouldn't be solved by changing focus or raise behaviour.
> I'm sure you think this is sufficient but you > have been forced into this point of view by the > absolute necessity of tiling your data, because > click-raise makes overlapping windows impossible > to use.
No, you're ignoring that I explicitely stated that I've used multiple windowing systems, with a plethora of focus and raise behaviour. So, again, I reiterate, I've tried it your way, and it annoys me to no end. Not only that, but its not that the behaviour was too ingrained for me to see the benefits of autoraise. Before I ran Linux I had a 386 incapable of running Windows, and I explored my options on X *before* I settled on the behaviour I prefered (including focus follows mouse with auto-raise).
> Also I know that window edges are very narrow. > This is why programs should always raise the > window on clicks that don't serve any purpose.
> Most programs add a pretty significant border > inside the window that can be used to raise it. > I believe that as long as programs do this you > would never miss click-raise, as there is always > a very large amount of available clickable
I would contest that "most" applications add a signifigant border. Of the applications I have open right now (terminal, word processor, spreadsheet, web browser, mp3 player) the majority of the blank space is only on the menubar and toolbar, which is only at the top of the application window. This is far from being efficient.
> Also as I said the programmer can also decide > that various clicks mean that the user wants the > program in the foreground, ideally they should > do this when the actions make it clear that the > user is not copying or referring to data outside > the window but instead looking at data inside > the window.
I'm sorry, but applications should not decide on windows behaviour.
It's obvious you have a set of criteria for how YOU work. As I've stated twice already, it is not objectively better. Nor is mine.
It's not impossible to get a window manager to do what you want. You can focus and raise however you want, you can have it leave the stacking order of parents along when you raise a dialog, you could have your windows bounce across the screen like they're in pong if you'd like.
I just chafe at the implication that pandering to your preferences somehow equates to innovation.
Matt
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 2
>To me this means you have refused to try it... >Again I don't think you have tried a system that >correctly works.
I know its hard to conceive of someone who doesn't like your favourite pet features, but really, it doesn't mean they've never tried them, or they're being stubborn.
I've used TWM, FVWM2, Afterstep (classic, not the post 1.0 eye candy fest, ick), Sawfish, Enlightenment, MWM, Swm, XFwm, OLVM, Blackbox, Metacity, KWM. Just for good measure I've also used Windows 9x, Windows NT, and MacOS 7/8/9.
I've tried click-to-focus, focus-follows-mouse, and sloppy focus, I've tried workspaces and viewports, etc.
> However try MSWord and edit several documents > that you want to cross-reference and you will > quickly see the light.
Word isn't a particularly easy application for me to do anything in since I haven't had a Windows desktop in six years.:)
However, I edit and cross reference multiple documents all the time, usually in terminal windows. I've never had any issues switching between the windows I'm using with keyboard shortcuts or even the occasional mouse click. And if I'm making a lot of back and forth references, I *want* them to be tiled.
> PS: it is easy for click to raise windows, the > user can click on the title bar or any edges.
Window borders are typically narrow (don't want to waste screen real estate, do we?) so this require much more precise mouse movement than clicking on the window itself.
> Also any program can raise itself in response to > a click, so if you are writing software and are > convinced that this behavior is necessary, you > can make it do it.
So application authors have to anticipate the work habits of their users, and assume that it is consistent for ALL their users? Sorry, but I prefer consistency.
> And again you make the stupid assumption that > all communication can be done with cut & paste.
For a dialog box? Yes. Dialog boxes should never require extensive interaction. If they do, its a design bug.
> This makes overlapping main windows useless for > the same reason click-raise and > application-activation-raise make overlapping > windows between applications useless, by hiding > information you want.
You think it makes them useless. I think its useful to have the parent raised because typically when I interact with an windows dialog, I want to interact with that window again.
> Actually this is a serious bug because it > prevents a program from having more than one > "main" window.
Funny how I'm using multiple top level windows for several applications right now. How does it prevent it again?
> The result has been that virtually everybody has > been forced to single "tiled" main windows or > "MDI" main window containing all the subwindows, > which is a huge waste of screen realestate and > very confusing to the user because of the extra > borders.
I've never felt myself forced to use anything. I use multiple overlapping toplevel windows with no issues at all. As stated there are times I will deliberately tile windows, but when I am cross referencing heavily, I *want* everything on the screen on the same time.
(On a side note, there are very few Windows-style MDI applications on Unix if you hadn't noticed. The more prominent solution, tabs, don't waste much screen real estate and don't have extra borders.)
> Tiled windows are stupid, if they were a good > idea we would be using the Andrew window system > or Windows 3.1 and tiling *all* the windows.
Sorry, but that argument is just stupid. It might make sense if a) the only difference between AWS or Win 3.1 and other windowing systems was tiled vs. overlapping windows, and b) tiling is either the best solution for everything or the best solution for nothing.
In close, I repeat, "I'm not saying everyone should work how I do. I'm saying not everyone works how you do. Your preferences are not objectively better."
Re:Frequently Asked User Interface Questions
on
Inside Ximian
·
· Score: 3, Insightful
>POINT TO TYPE!!!!!! Goddamm it, make it the >default. Complete novices learn it very very >quickly and it makes it almost impossible to >return to a click-to-type system. This is the >biggest way to get Linux converts.
I personally hate that "feature" with a passion.
>It also does not confuse Windows users, if when a >new window openes or otherwise grabs the focus, >you warp the pointer to the window.
Another feature I hate. If I want my mouse pointer somewhere, I'll move it myself.
>STOP RAISING WINDOWS WHEN YOU CLICK ON THEM.
I prefer this behaviour myself.
>GET RID OF "LAYERS".
Another feature I prefer. If I didn't want my toolbars permenently visable, I'd set them to hide.
>GET RID OF "APPLIACATION ACTIVATION"... PLEASE >make it possible to raise a dialog without >raising the underlying window, so I can copy data >from another window into it!
I can count the number of times this would be useful to me on zero hands. I highlight from app A, raise app B, paste. No need for the window I'm pasting from to be raised when I've already gotten the data I'm copying from it.
On the other hand, it has been useful for me to have the window associated with a dialog raised when I'm going to interact with it again.
I'm not saying everyone should work how I do. I'm saying not everyone works how you do. Your preferences are not objectively better.
Matt
Re:Why do people use ximian?
on
Inside Ximian
·
· Score: 2
>I think what the orig poster may have been talking >about is what happens when you Install Ximian and >then try to use anything *other* than Redcarpet to >update...up2date doesn't play well with Ximian >packages, and it makes upgrading your distro a >PITA (first have to force rpm to remove all the >Ximian packages, then upgrade, then reinstall >Ximian...and hope it works).
I considered that, but it didn't seem to fit the "incompatible with gnome" statement very well.
In any case, I agree that upgrading the distribution after a Ximian install is harder than it should be. Unfortunately I think the problem transcends Ximian alone. If you install any third party package that overlaps with what Red Hat provides, there is a distinct chance of clashes.
One possible way these sorts of issues could be avoided would be for package management tools to make more intelligent use of the Vendor metadata tag. For example, the Red Hat installer could match for "Red Hat, Inc." (I believe they set this consistently), and either skip packages from other sources, or prompt the user.
It doesn't entirely solve the problem. Say I installed Ximian on Ficticious Linux 1.0. At the time FL 1.0 didn't ship anything that depended on libfoo, so Ximian installed libfoo-1.2.4. I go to upgrade to FL 2.0, and they now include an application which requires libfoo-1.2.7. It might turn out that the installer would ask me about the dependency, I'd tell it to go ahead an install the new version, and life would be grand. But even if you assume there's no incompatibilities, it still complicates the install process.
>I'd disagree with you on the apt-get being hard >comment, but I don't use debian on desktops.
If I gave the impression that I thought apt-get was difficult, I apologize. However, I do think it isn't as intuitive for inexperienced users as clicking on "Get Software" followed by clicking on "Upgrade Now" or choosing the new application you want to install.
Matt
Re:Why do people use ximian?
on
Inside Ximian
·
· Score: 2
>I've often wondered why people bother with ximian. >Are the packages it releases any better than the >ones released by gnome itself?
The Gnome project doesn't provide packages at all, so yes, the Ximian packages are better because they exist.:)
What they're really competing against is the distribution offerings. It seems the common consensus that Ximian is a much more polished product; e.g. the misfeature of filenames in save dialogs disappearing if you changed directories was first fixed in their distribution.
It becomes even more of an issue if you're running an older distribution, since the majority of companies only release bug fixes rather than new versions of software. So if you're running Red Hat 6.2 you have the option of sticking with Gnome 1.0.55, which shipped with it, compiling from scratch, or installing Ximian, which is based off 1.4.0.
>Sure, it has a pretty autoupdate feature, but >then so does debian and mandrake
I'm not familiar with the Mandrake solution, but Ximian is much more end user friendly than apt-get. I'm an experienced user, and I still find value in having a simple graphical interface to browse through updates.
>and it can be added to redhat... and one of the ways you can add autoupdating is by downloading Red Carpet.:)
>.... And if you install it then your >installation seems to be not quite compatible >with a standard gnome install.
What's not compatible? I've never had issues running either binaries or source I've compiled myself, and I've been running Ximian since they were Helix.
>Is it yet another linux company that is going to >crash and burn once it runs out of VC?
Without looking at their financials, wouldn't be able to tell you.:)
You should keep in mind, however, that their revenue is solely from product sales. Both Sun and Hewlett Packard have contracted them for work on getting Gnome ported and packaged to their respective platforms.
>Just what is there to encourage people to pay >them money?
Depends on the person. Someone looking for interoperability with Exchange might be encouraged by Red Carpet. Someone looking to deliver a standard desktop with centralized management across multiple platforms might be tempted by Ximian Gnome and Red Carpet CorporateConnect.
And I've already given examples of programming contracts.
>The 320 GB disk is even only 5400 RPM - that's as >slow as the good old Bigfoot disks of times >forgotten (Remember? they were the size of a >showbox and a lot heavier...).
I do, but I remember the specs a bit better than you. Bigfoot drives were only avaialble at 3600 and 4000 RPM.
A large number of consumer level IDE drives are still 5400 RPM, and a year ago it was probably the majority of them.
>Mac OS X, BSD, even windows 2000 have all allowed >64-bit file lengths/offsets for years, but linux >still uses a 32-bit offset. Extfs is hardwired to >only allow 32-bit file lengths, but jfs, xfs, >reiserfs, etc. aren't so limited. > >Hopefully, linus will accept the patch >[kernel.org] to allow 64-bit file lengths and >offsets in the vfs.
There has been 64-bit file support in the vfs and ext2 since 2.4.0.
>What happens when you have a fire, tornado, flood >at your server farm? Your precious raid array is >now paperweights.
Or more likely when someone accidently deletes something they shouldn't off the fileserver, or from their mailbox.
>What backups do you restore on the new system to >minimize down time? > >Until a viable backup methodology is developed, >businesses will rightly view these super large >drives as a liability, not an asset.
Note that those are all *native* capacities. You could theoretically back up one of these high capacity drives to a single tape, depending on the data you're storing.
A library would be a much better option, but even that isn't necessarily beyond the reach of even small businesses. A VXA AutoPAK 1x7 with a native capacity of 560GB is only $3,299 from Exabyte.
The problem with backup is largely one of what *home* users can do.
>That's because Redhat removed identification >information from the "About" boxes of KDE >applications.
No, they removed the "About KDE" boxes from KDE applications.
>You can't blame the KDE guys for getting pissesd >that they make this nice software, and the >project doesn't get recognized for it.
The "About" box that IS left in still lists what version of KDE the program is built on, so yes, they do get recognized for it. They just don't get credited TWICE.
>And there was no reason to do it.
I personally think it's unnecessarily redundant, and potentially confusing for new users. Should they put in an About box for every single library they link against? I for one would rather not go to the Help menu and find About, About KDE, About QT, About libxml2, etc, etc.
>Does it confuse users? I doubt it. People aren't >that stupid.
>And getting screamed at by the KDE team for it...
What do you expect? If a Red Hat employee farted during a KDE presentation at LinuxTag, I wouldn't be suprised if there was speculation on the mailing the next day that it's part of the grand Red Hat conspiricy to sabotage KDE.
>Thus, when someone comes up with the brilliant >idea that the average person should be able to >actually use the system, they're booed off. Yet >these boo-ers are the same people who bash the >mass market for using Microsoft or Apple's OS X.
Let's see.. When I started running Linux way back when I had to manually partition my hard drive, manually configure X (including plugging in video timings for my monitor), manually configure sound (including plugging in I/O addresses and IRQs), had to edit a config file in vi to add icons to my windowmanager (Afterstep Classic), had no real GUI filemanager, took 4 hours to figure out how to get my printer working properly, etc, etc.
Now, I can stick in a CD, have it autopartition, detect all my hardware, configure X, and has a full desktop environment with a GUI filemanager, where I can simply drag an icon to the panel. I can hot plug USB and PCMCIA devices to my heart's content. I can add new hardware, and it will detect and configure it on boot. I can sit back and let my machine take care of keeping itself up to date with all the latest security patches.
I must have missed an AWFUL lot of booing somewhere.
>Right now, when you install pretty much anybody's >distro,
Except for Lindows, Lycoris, Libranet, OEOne, Xandros...
Come the release of Red Hat 8.0, you can probably add that to the list, given the focus they've put into creating a rational, consistent desktop in the betas.
>you start up with an interface that has tons and >tons of menus, icons, widgets, and whatnot, >already up and running. It's an overload, and >instead of trying to learn it, newbies are >balking at it.
Taken a look at Gnome lately? From an end user perspective, all of the changes in Gnome 2.0 are aimed at usability, accessibility, simplification, and consistency. To paraphrase Havoc, they're removing the "crack rock" features, and "proving one good way of doing things instead of six broken ones".
>So why not have an easy-to-use kernel >configuration system?
Noone has objected to the concept, only to the implementation. At different points there were issues with the rulesets in CML2 differing from CML1 in ways that the developers didn't agree with. The frontends used a different UI. It globally loaded rules for all architectures.
It has long been Linus' policy not to accept patches which introduce more than one fundamental change. The proper course would have been to make CML2 a drop in replacement for CML1, with no changes to the rulesets, and with front ends that completely emulated the old ones. Then, and only then, discussions on rationalizing the rulesets and providing enhanced interfaces would be appropriate.
Did it solve the problem it set out to solve - i.e. providing a more flexible syntax and a single parsesr? Sure, but it bundled too many other changes, and when you come down to it, it was replacing a system known to work with an unknown one.
On a side note, the whole topic is moot. Does Windows provide you with an easy to use kernel configuration tool? Does MacOS? No, because the end user should NEVER have to configure a kernel.
>Why not have an independent object model, where >any distribution or window manager can use each >other's dialog pages?
>Most of us (myself included) would never put >redhat (For example) on a server unless we had no >other choice, because it is cumbersome.
Define "cumbersome". It's far from rocket science to configure a Red Hat system to have a foot print of only about 150MB, running only the services you want.
Managing a Red Hat system can be done just the same as most other Linux systems. All the standard tools work (ifconfig, fdisk, etc), they follow FHS policies for filesystem layout, and conform to the LSB.
The configuration tools they provide don't destroy changes made by hand like the ones provided by some other distributions do (*cough*YAST*cough*), and their convienence scripts (ifup/down, chkconfig, service) are just that - convienent. They in no way prevent you from manipulating these things by hand (e.g. you can still configure networking with ifconfig, you can still manupulate services by running the scripts in init.d and manually editing symlinks in rc.d).
>We might use gentoo, or slackware instead.
Sorry, but I'd seriously question "most of us", particularly if you include people who actually have real experience administrating servers in a production environment, instead of on their home network.
With Red Hat I can use kickstart to create replicated installation scripts. I boot off a CD, and in 15 minutes the type of machine (e.g. SMTP, POP) is ready to go.
With Slackware I can install each machine individually, or I waste my time developing, debugging and maintaining my own method for replicated installs. I actually did this, before we migrated *off* Slackware (choice of a previous admin who was 0ld sk3wl 31337, when there was only one server).
With Gentoo I have to their gawdawful primitave installer (I'm sorry, but having to manually load modules and set up networking is just stupid), or again waste my time writing my own installer.
With Red Hat I have a robust package management system and a secure update mechanism. They provide critical updates usually within a day, and it only takes me a few minutes to update every machine on my network.
With Slackware I can manually download updates, distribute them to the servers, and install them. Or roll my own system for doing updates. (Starting to see a pattern here?)
With Gentoo I have to emerge the old package, and then unmerge the old one. Mind you, there's no mention of testing to make sure services aren't negatively affected by their files changing underneath them, and "config file protection" is only turned on for/etc and KDE config files by default. Oh, and since they only provide binary packages for releases and snapshots, you have to wait for this to compile on each box individually.
I might have taken your comment more seriously if you had suggested Debian, which does have automated installation available, and provides a laudable upgrade system. On the other hand I've managed a large (~ 100 machine) Slackware installation in the past, and know the downfalls all too well. And Gentoo is, I'm sorry to say, piss in your pants laughable.
>It wasn't fine grained by any definition in 1996, >It wasn't fine grained when 2.2 come out and >sections of the kernel are under BKL even in 2.4 >and 2.5 development kernel. Not much difference >as compared to FreeBSD here.
I never claimed it was historically fine-grained, or completely fine-grained in the current release. I specifically said "relatively fine-grained", which I stand by completely.
The 2.0 kernel was a first implementation, and was dealing with a largely non-threaded kernel. In other words, it was largely bolted onto a code base that had been traditionally uniprocessor.
The 2.2 kernel added fine-grain locks for the scheduler, signal-handling, interupts, and much of the I/O layet
The 2.4 kernel has a multi-threaded TCP/IP stack, I/O layer, VM subsystem, page cache, scheduler, interrupt handler, etc, etc. Most of the traditional BKL bottlenecks *have* been removed.
Is scalability still optimal? No. Hence the word "reasonably".
The implementation of SMP in FreeBSD has been called "simplistic" and "rudimentary" even by the developers. Both 3.x and 4.x rely heavily on the BKL (or Big Giant Lock, or Giant Kernel Lock, or whatever nomenclature you prefer), although 4.x did move portions of the syscall code outside the lock.
It appears that the smpng code in 5.0 will be an immense improvement, in part due to the access developers had to the BSD/OS code base. But for current production releases, the "not much difference" verdict doesn't hold water. Maybe if you were comparing FreeBSD 4.0 against Linux 2.0.
>FreeBSD has is for Alpha and Sparc64 too, check >your facts before spewing them on public.
I apologize. I had forgotten about the Alpha support, and the Sparc64 support was only added earlier this year, and as far as I can tell only it's only in the as yet unreleased 5.0 branch.
>BSD is not dying ! Why is everyone saying that ? >BSD is the best OS in the world, anyone who >doesn't use it is an utter moron.
Depends on what your criteria are. Just as a quick example, what is the status of SMP support on the free BSD variants? OpenBSD has it in a CVS branch, but it still depends on a BKL (Big Kernel Lock). NetBSD has it, but only for Alpha in current, and AFAIK the only other architecture is i386, which is in CVS, and again depends on a BKL. FreeBSD has it, but only for i386, still has some serious known issues (e.g. race conditions), and won't be fine grained until 5.0 is released.
Contrast this to Linux which has had SMP support built in since 1996, is relatively fine grained, and support x86, Alpha, Sparc, PPC, ia64, MIPS, and s390.
And what kinds of clustering are supported in BSD? How about disk layouts? Filesystems?
No, Linux is by far not perfect in any of these respects. Neither are any commercial operating systems. BSD has its strengths, but it has weaknesses like everyone else.
>Linux really isn't that great compared to other >Unices. It is the media darling, partly because >it fits the "built in someone's garage" cliche. >It really is an alternative to Windows, and not >Unix systems.
It depends on what Unix systems you're refering to. Will it replace a 64 processor machine from HP or Sun? No. Will it replace dual processor machines from the same companies? Almost definitely.
In fact, depending on what hardware you're talking about, Linux is a BETTER alternative to traditional Unixes on the low end because it has lower overhead. For example, process creation, syacalls, and context switches are signifigantly (read: as much as 10 times) more expensive on Solaris than on Linux.
>My personal opinion as to why... It has always >just been something cool to hack away at. Very >little work has been done to get security and >stability overall. As an example, take the >filesystem, EXT2.
Funny how the kernel developers seem to talk about security and stability a whole lot on the mailing lists. Please provide some evidence to back this up.
>Linux rarely gets used on big iron. The only time >you'll hear about some fast set of machines is in >something like a cluster, for >non-mission-critical applications. Even IBM, the >diehard supporters of Linux, will openly admits >that it just can't compete with AIX.
And you know what? The majority of servers AREN'T big iron. If you look at the BSDs, Unixware, or Openserver, they're not running on big iron either.
As for only hearing about Linux on fast machines in clusters for "non-mission-critical" applications, I have direct experience to the contrary. I work at a company that bases its entire company (including the services we offer our customers) on Linux, with the exclusion of a handful of Sun machines. The company my brother works at runs their entire network infrastructure (mail, web, nis, nfs, firewalls, routers, vpn tunnels) on Linux.
>Anyone who has used Linux for more than a week >has had an Ext2 filesystem get corrupted. While I >realize that there are other filesystems now, and >that example is out-dated, I haven't used Linux >extensively for a while, so any examples I give >will be outdated.
I've been using Linux for over 7 years without experiencing filesystem corruption that wasn't recoverable with fsck. And this includes managing upwards of two terabytes of data.
Most of the people I hear who claim this are either parroting what they've heard elsewhere, or base their claim that ext2 is prone to corruption on its use of writing metadata async, unlike e.g. ffs. First off, this is only a problem if you've had an unclean shutdown. And second, e2fsck is a fantastic program. I've never had it fail recovery.
And yes, your experience is seriously outdated. Ext3 can journal just metadata, or metadata AND data, which is actually MORE robust than most commercial offerings.
>More than that there are consistency problems. So >much work is going into adding new features as >quickly as possible, that stability, consistency, >and ease of use just goes out the window.
The stable branches of the kernel (2.0, 2.2, 2.4) get only bug fixes and new drivers, NOT new features.
>Compiling a new kernel should be a simple process >(and one that should be unessecary) but instead >gives you tons of kernel modules that are >unuseable.
What makes you think its commonly necessary? In almost three years I've run a total of four kernels - started on 2.2, did an upgrade to fix an Intel driver issue (stupid MII lockups), moved to 2.4, did an upgrade to fix an obscure SG driver bug.
If you're using a distribution, upgrading a kernel can be as simple as a single command (rpm -Uvh). Even if you're building from scratch, you can "make oldconfig" to avoid having to deal with menu options.
As for unusable modules, they don't show up by default. You need to explicitely choose to see experimental features.
>Linux development just has the Windows' >attitude... Not a Unix attitude. I can't speak >for anyone else (although it statistically looks >like I do) but I don't think Linux has a chance >against stable, secure, consistent, >high-performance systems. I just think of it as a >geek toy... Like a Dreamcast
Odd how I can use a "geek toy" to provide e-mail for literally thousands of domains and millions of users.
And what exactly is "the Windows' development attitude"?
>2. O'Reilly did a survey and more new Mac users >were coming from the Linux camp than anywhere >else. From what I've seen of Apple's sales figures >(latest 10-Q) sales are much too high to be the >same old Mac users, the new ones are coming from >somewhere.
So are you just parroting something you heard, or are you deluded enough to think that the "survey" you're refrencing is actually a valid metric of who's migrating from what?
The "survey" consisted of a post to a mailing list, and got only 15 responses.
>However, I disagree with you and all others (seems >to be 90% of posters here) who claim that SCO is >failing in the market. First of all, everybody >who has worked with UnixWare described it as one >of the best Unix on any platform.
I've got SCO ACE certification in Openserver and Unixware, SCO Master ACE certification in Non-Stop Clusters and Openserver, and supported as far back as SCO Unix 3.2v4.0 and Unixware 1.1 (as a legacy product after it was purchased by SCO).
Openserver was a nightmare to work with. First off, just BUYING it was a task. Need a licence for the operating system, tcp/ip support, multiple processor support, disk mirroring, and whatever user count you need. If it was an upgrade, you had to know what version you were coming from, how many users you had licensed, what units they were licenced in, etc, etc.
Then you get to buying the hardware to install it on, and half the supported hardware is discontinued. Whoops.
Finally get a system to put it on, and you're greeting with a picky installed worse than what Redhat had on version 3.0.3, which you complete only to have to start the arduous task of installing all the patches and hardware supplements - RS505, OSS471, OSS491, OSS600, etc. And God help you if you accidently installed one out of order, because then its time to roll back, reapply, and pray it goes smoothly so you don't have to reinstall.
After installing nothing but the base operating system and the vendor supplied patches, its time to run a verify on the operating system, because oft times there'd already be issues with permissions and symlinks.
Then maybe you'd want to do a backup to your shiny new DAT drive. Whoops, have to relink the kernel for that. And as you manually type in the location of your tape drive, you accidently put in the wrong bus. When you notice your error you try to delete the device and add it correctly, but it won't go away. Turns out you have to manually edit six different files scattered across the filesystem, including the kernel headers.
Mind you, Unixware was better... at least Unixware 7 was. However the initial releases were buggy as hell, and were a bizarre mixture of SysV, Netwarisms, and Openserverisms.
I think their best bet for carving a niche for themselves was the Non-stop Cluster product. Platform aside, it was a pretty damn slick single system image cluster. I got to play with some of the first ones in existence, and actually built out four of them (two on my own, one while I was assisting a SCO instructor doing an on-site training, and one at an advance training out in Santa Cruz)). Very cool stuff, though it suffered from the expected flakiness of a new product; doubly so since it was built on a brand new operating system.
Unfortunately, it seems that they never managed to capture any marketshare, and from what I can see on the website, it looks like they only offer a high availability solution now.
So what do these products have to offer the market now aside from legacy support, and a few niche markets which are slow to change?
>My main point should have been this: when you're >designing a standard, why not go with the best >format with the longest track record? Why not go >with apt-get which has been around for what, 4+ >years now, instead of one thats cropped up in the >last year and isn't as proven?
The LSB specification doesn't specify package management front ends like apt-get; it specifies a package format.
RPM has been around for about seven years, and, whether you like it or not, is used by virtually all of the major Linux distributions (Red Hat, Mandrake, Caldera, SuSE, Turbo).
Add that the majority of what people think is wrong with RPM is based on ignorance or confusion with what a package format is and what a package manager is, and there's no really compelling reason to standardize on what is a fringe package format.
>The only problems I've had with Debian was when I >was running unstable. Under Redhat I ran into >dependancy hell when only trying to >install....sorry you need libz which needs >libx.2, but libx.2 confilcts with packages a, b >and c which need libx.1, and so on..
I tend to dislike when people say the other person is lying in an argument, but I'm tempted to here. Maybe if you told me what version of Red Hat wasn't able to resolve dependencies on install, I could go check and maybe believe you.
I don't doubt there are cases where circular dependencies exist, but I honestly have never run into one in the Red Hat provided packages, and haven't run into one for a couple years even with third party packages.
> consider that Darwin/OS X is installed on more > computers than all other Unices combined, and > then rethink your "non-standard GUI" comment.
Do you have figures to back this up? I've heard this claim bandied around a lot by Mac enthusiasts a lot. Or the less extreme, "larger installed base than any other single Unix". Or the even less extreme, "positioned to have a larger installed base than any other single Unix".
But I have never seen figures to back up this claim.
>npc@temple:(22:40:11):/usr/src/sys/kern] >grep "UNIX System Lab" * [snip] >You were saying...?
And what percentage of the codebase is that? One percent? Even before 4.4lite, it's reported that 90-95% percent of the codebase was rewritten.
Let's say way back when I owned a Packard Bell. Some cool game comes out, so I get a new video card. Then I start running out of space, so I throw in a new hard drive. And then the phone company screws up and doubles voltage, frying my modem, so I replace that. And then I decide I want something faster, so I throw in a new motherboard, processor and memory. Then I want a DVD drive, but there's no room in the case, so I put move the whole thing to a new case.
Am I still running a Packard Bell because I happen to have kept the mouse and sound card from that machine?
If we're going to accept that logic, is Windows XP a BSD since it has Berkeley code in it?
>I'm not sure what to make of it, but Tim Horton's >[timhortons.com] in Canada has coffee sizes Small, >Medium, Large and Extra Large, while in the U.S., >the same sizes are Extra Small, Small, Medium and >Large. Note that the lids on the cup still have >the S, M, L, XL labels molded in.
I'm in the U.S. and the sizes are labeled Small, Medium, Large and Extra Large.
>FreeBSD is, in fact, THE free Unix. Linux is a >Unix clone. FreeBSD is based on Berkeley Unix, and >is thus, a direct decendant of the original Unix >source code, not a rewrite. Not that it matters >much.
It doesn't matter, and it's not really accurate. FreeBSD is based on the 4.4-lite codebase, which is the version that removed the last vestiges of copyrighted USL (Unix Systems Lab) code from the Net/2 codebase released by Berkeley's CSRG (Computer Systems Research Group) as part of a settlement agreement in the lawsuit USL pressed against the BSDI and UCB. So yes, FreeBSD *is* a rewrite.
And even that is somewhat irrelevent, since if you want to be pedantic about the term, UNIX is now a specification and operating systems which are certified to conform to that specification. None of the free Unixes have gone through the certification process, and thus are all "unix-like" and not UNIX.
Matt
(And just as one side note, even if none of the above was true, saying "FreeBSD is THE free Unix" doesn't make sense, since OpenBSD and NetBSD are also derived from the 386BSD codebase, and would therefore qualify under your definition.)
>Read the parent post; I use the example because >it's what he used.
True, I hadn't caught his reference originally. But you still essentially reiterated his misunderstanding about the nature of BDB.
>That said, though, I've seen far too much data >corruption and too many performance failures in >Berkeley DB-based apps to trust it.
I think the reliability and performance of BDB is highly dependent on the person writing to it. Since it is decidedly low-level, there are perhaps more caveats, but this doesn't differ that much from an RDBMS implementation.
Slashdot Mirror
> The problem is if you have data that is large
> enough that you cannot tile the windows and they
> have to overlap. Try working with 2048x1556
> images in the special effects industry and you
> will know that this is not an unrealistic
> scenario.
In other words you have somewhat peculilar requirements that make a particular type of interface less useful to you. This does not extend to "focus follows mouse is inherinetly superior and more innovative".
> And this is not a problem with just multiple
> images, most programs have an extremely large
> control panel and you cannot mess with it
> because, raising it necessarily hides the image
> you are working on!
Most programs? The majority of programs I work with have at most a menubar and a toolbar. The toolbars can be universally turned off, and often can have the menubar turned off. Other, such as
Gimp or Glade, have multiple control windows, but they're set as toplevel, so raising them has no effect on other windows.
In other words, you're looking at things with blinders; i.e. your own experiences and the applications that you work with.
> Basically the problem is that you are using data
> that is small enough that you can tile the
> screen. When windows are arranged this way,
> there is no difference between click-raise and
> click-does-nothing.
Actually, I often use data that is too large to tile. In those instances I use keybindings to switch between windows. The only time this becomes insufficient and I tile is when I specifically need to see both data sets simultaneously, which wouldn't be solved by changing focus or raise behaviour.
> I'm sure you think this is sufficient but you
> have been forced into this point of view by the
> absolute necessity of tiling your data, because
> click-raise makes overlapping windows impossible
> to use.
No, you're ignoring that I explicitely stated that I've used multiple windowing systems, with a plethora of focus and raise behaviour. So, again, I reiterate, I've tried it your way, and it annoys me to no end. Not only that, but its not that the behaviour was too ingrained for me to see the benefits of autoraise. Before I ran Linux I had a 386 incapable of running Windows, and I explored my options on X *before* I settled on the behaviour I prefered (including focus follows mouse with auto-raise).
> Also I know that window edges are very narrow.
> This is why programs should always raise the
> window on clicks that don't serve any purpose.
> Most programs add a pretty significant border
> inside the window that can be used to raise it.
> I believe that as long as programs do this you
> would never miss click-raise, as there is always
> a very large amount of available clickable
I would contest that "most" applications add a signifigant border. Of the applications I have open right now (terminal, word processor, spreadsheet, web browser, mp3 player) the majority of the blank space is only on the menubar and toolbar, which is only at the top of the application window. This is far from being efficient.
> Also as I said the programmer can also decide
> that various clicks mean that the user wants the
> program in the foreground, ideally they should
> do this when the actions make it clear that the
> user is not copying or referring to data outside
> the window but instead looking at data inside
> the window.
I'm sorry, but applications should not decide on windows behaviour.
It's obvious you have a set of criteria for how YOU work. As I've stated twice already, it is not objectively better. Nor is mine.
It's not impossible to get a window manager to do what you want. You can focus and raise however you want, you can have it leave the stacking order of parents along when you raise a dialog, you could have your windows bounce across the screen like they're in pong if you'd like.
I just chafe at the implication that pandering to your preferences somehow equates to innovation.
Matt
>To me this means you have refused to try it...
:)
>Again I don't think you have tried a system that
>correctly works.
I know its hard to conceive of someone who doesn't like your favourite pet features, but really, it doesn't mean they've never tried them, or they're being stubborn.
I've used TWM, FVWM2, Afterstep (classic, not the post 1.0 eye candy fest, ick), Sawfish, Enlightenment, MWM, Swm, XFwm, OLVM, Blackbox, Metacity, KWM. Just for good measure I've also used Windows 9x, Windows NT, and MacOS 7/8/9.
I've tried click-to-focus, focus-follows-mouse, and sloppy focus, I've tried workspaces and viewports, etc.
> However try MSWord and edit several documents
> that you want to cross-reference and you will
> quickly see the light.
Word isn't a particularly easy application for me to do anything in since I haven't had a Windows desktop in six years.
However, I edit and cross reference multiple documents all the time, usually in terminal windows. I've never had any issues switching between the windows I'm using with keyboard shortcuts or even the occasional mouse click. And if I'm making a lot of back and forth references, I *want* them to be tiled.
> PS: it is easy for click to raise windows, the
> user can click on the title bar or any edges.
Window borders are typically narrow (don't want to waste screen real estate, do we?) so this require much more precise mouse movement than clicking on the window itself.
> Also any program can raise itself in response to
> a click, so if you are writing software and are
> convinced that this behavior is necessary, you
> can make it do it.
So application authors have to anticipate the work habits of their users, and assume that it is consistent for ALL their users? Sorry, but I prefer consistency.
> And again you make the stupid assumption that
> all communication can be done with cut & paste.
For a dialog box? Yes. Dialog boxes should never require extensive interaction. If they do, its a design bug.
> This makes overlapping main windows useless for
> the same reason click-raise and
> application-activation-raise make overlapping
> windows between applications useless, by hiding
> information you want.
You think it makes them useless. I think its useful to have the parent raised because typically when I interact with an windows dialog, I want to interact with that window again.
> Actually this is a serious bug because it
> prevents a program from having more than one
> "main" window.
Funny how I'm using multiple top level windows for several applications right now. How does it prevent it again?
> The result has been that virtually everybody has
> been forced to single "tiled" main windows or
> "MDI" main window containing all the subwindows,
> which is a huge waste of screen realestate and
> very confusing to the user because of the extra
> borders.
I've never felt myself forced to use anything. I use multiple overlapping toplevel windows with no issues at all. As stated there are times I will deliberately tile windows, but when I am cross referencing heavily, I *want* everything on the screen on the same time.
(On a side note, there are very few Windows-style MDI applications on Unix if you hadn't noticed. The more prominent solution, tabs, don't waste much screen real estate and don't have extra borders.)
> Tiled windows are stupid, if they were a good
> idea we would be using the Andrew window system
> or Windows 3.1 and tiling *all* the windows.
Sorry, but that argument is just stupid. It might make sense if a) the only difference between AWS or Win 3.1 and other windowing systems was tiled vs. overlapping windows, and b) tiling is either the best solution for everything or the best solution for nothing.
In close, I repeat, "I'm not saying everyone should work how I do. I'm saying not everyone works how you do. Your preferences are not objectively better."
>POINT TO TYPE!!!!!! Goddamm it, make it the
>default. Complete novices learn it very very
>quickly and it makes it almost impossible to
>return to a click-to-type system. This is the
>biggest way to get Linux converts.
I personally hate that "feature" with a passion.
>It also does not confuse Windows users, if when a
>new window openes or otherwise grabs the focus,
>you warp the pointer to the window.
Another feature I hate. If I want my mouse pointer somewhere, I'll move it myself.
>STOP RAISING WINDOWS WHEN YOU CLICK ON THEM.
I prefer this behaviour myself.
>GET RID OF "LAYERS".
Another feature I prefer. If I didn't want my toolbars permenently visable, I'd set them to hide.
>GET RID OF "APPLIACATION ACTIVATION"... PLEASE
>make it possible to raise a dialog without
>raising the underlying window, so I can copy data
>from another window into it!
I can count the number of times this would be useful to me on zero hands. I highlight from app A, raise app B, paste. No need for the window I'm pasting from to be raised when I've already gotten the data I'm copying from it.
On the other hand, it has been useful for me to have the window associated with a dialog raised when I'm going to interact with it again.
I'm not saying everyone should work how I do. I'm saying not everyone works how you do. Your preferences are not objectively better.
Matt
>I think what the orig poster may have been talking
>about is what happens when you Install Ximian and
>then try to use anything *other* than Redcarpet to
>update...up2date doesn't play well with Ximian
>packages, and it makes upgrading your distro a
>PITA (first have to force rpm to remove all the
>Ximian packages, then upgrade, then reinstall
>Ximian...and hope it works).
I considered that, but it didn't seem to fit the "incompatible with gnome" statement very well.
In any case, I agree that upgrading the distribution after a Ximian install is harder than it should be. Unfortunately I think the problem transcends Ximian alone. If you install any third party package that overlaps with what Red Hat provides, there is a distinct chance of clashes.
One possible way these sorts of issues could be avoided would be for package management tools to make more intelligent use of the Vendor metadata tag. For example, the Red Hat installer could match for "Red Hat, Inc." (I believe they set this consistently), and either skip packages from other sources, or prompt the user.
It doesn't entirely solve the problem. Say I installed Ximian on Ficticious Linux 1.0. At the time FL 1.0 didn't ship anything that depended on libfoo, so Ximian installed libfoo-1.2.4. I go to upgrade to FL 2.0, and they now include an application which requires libfoo-1.2.7. It might turn out that the installer would ask me about the dependency, I'd tell it to go ahead an install the new version, and life would be grand. But even if you assume there's no incompatibilities, it still complicates the install process.
>I'd disagree with you on the apt-get being hard
>comment, but I don't use debian on desktops.
If I gave the impression that I thought apt-get was difficult, I apologize. However, I do think it isn't as intuitive for inexperienced users as clicking on "Get Software" followed by clicking on "Upgrade Now" or choosing the new application you want to install.
Matt
>I've often wondered why people bother with ximian.
:)
... and one of the ways you can add autoupdating is by downloading Red Carpet. :)
:)
>Are the packages it releases any better than the
>ones released by gnome itself?
The Gnome project doesn't provide packages at all, so yes, the Ximian packages are better because they exist.
What they're really competing against is the distribution offerings. It seems the common consensus that Ximian is a much more polished product; e.g. the misfeature of filenames in save dialogs disappearing if you changed directories was first fixed in their distribution.
It becomes even more of an issue if you're running an older distribution, since the majority of companies only release bug fixes rather than new versions of software. So if you're running Red Hat 6.2 you have the option of sticking with Gnome 1.0.55, which shipped with it, compiling from scratch, or installing Ximian, which is based off 1.4.0.
>Sure, it has a pretty autoupdate feature, but
>then so does debian and mandrake
I'm not familiar with the Mandrake solution, but Ximian is much more end user friendly than apt-get. I'm an experienced user, and I still find value in having a simple graphical interface to browse through updates.
>and it can be added to redhat
>.... And if you install it then your
>installation seems to be not quite compatible
>with a standard gnome install.
What's not compatible? I've never had issues running either binaries or source I've compiled myself, and I've been running Ximian since they were Helix.
>Is it yet another linux company that is going to
>crash and burn once it runs out of VC?
Without looking at their financials, wouldn't be able to tell you.
You should keep in mind, however, that their revenue is solely from product sales. Both Sun and Hewlett Packard have contracted them for work on getting Gnome ported and packaged to their respective platforms.
>Just what is there to encourage people to pay
>them money?
Depends on the person. Someone looking for interoperability with Exchange might be encouraged by Red Carpet. Someone looking to deliver a standard desktop with centralized management across multiple platforms might be tempted by Ximian Gnome and Red Carpet CorporateConnect.
And I've already given examples of programming contracts.
Matt
>The 320 GB disk is even only 5400 RPM - that's as
>slow as the good old Bigfoot disks of times
>forgotten (Remember? they were the size of a
>showbox and a lot heavier...).
I do, but I remember the specs a bit better than you. Bigfoot drives were only avaialble at 3600 and 4000 RPM.
A large number of consumer level IDE drives are still 5400 RPM, and a year ago it was probably the majority of them.
Matt
>Mac OS X, BSD, even windows 2000 have all allowed
>64-bit file lengths/offsets for years, but linux
>still uses a 32-bit offset. Extfs is hardwired to
>only allow 32-bit file lengths, but jfs, xfs,
>reiserfs, etc. aren't so limited.
>
>Hopefully, linus will accept the patch
>[kernel.org] to allow 64-bit file lengths and
>offsets in the vfs.
There has been 64-bit file support in the vfs and ext2 since 2.4.0.
Matt
>What happens when you have a fire, tornado, flood
>at your server farm? Your precious raid array is
>now paperweights.
Or more likely when someone accidently deletes something they shouldn't off the fileserver, or from their mailbox.
>What backups do you restore on the new system to
>minimize down time?
>
>Until a viable backup methodology is developed,
>businesses will rightly view these super large >drives as a liability, not an asset.
DLT7000 (30GB/tape)?
VXA-1 (33GB/tape)?
AIT-2 (50GB/tape)?
M2 (60GB/tape)?
VXA-2 (80GB/tape)?
Ultrium (100GB/tape)?
SDL320 (160GB/tape)?
Ultrium 2 (200GB/tape)?
Note that those are all *native* capacities. You could theoretically back up one of these high capacity drives to a single tape, depending on the data you're storing.
A library would be a much better option, but even that isn't necessarily beyond the reach of even small businesses. A VXA AutoPAK 1x7 with a native capacity of 560GB is only $3,299 from Exabyte.
The problem with backup is largely one of what *home* users can do.
Matt
>That's because Redhat removed identification
>information from the "About" boxes of KDE
>applications.
No, they removed the "About KDE" boxes from KDE applications.
>You can't blame the KDE guys for getting pissesd
>that they make this nice software, and the >project doesn't get recognized for it.
The "About" box that IS left in still lists what version of KDE the program is built on, so yes, they do get recognized for it. They just don't get credited TWICE.
>And there was no reason to do it.
I personally think it's unnecessarily redundant, and potentially confusing for new users. Should they put in an About box for every single library they link against? I for one would rather not go to the Help menu and find About, About KDE, About QT, About libxml2, etc, etc.
>Does it confuse users? I doubt it. People aren't
>that stupid.
You haven't done desktop support much, have you?
>And getting screamed at by the KDE team for it...
What do you expect? If a Red Hat employee farted during a KDE presentation at LinuxTag, I wouldn't be suprised if there was speculation on the mailing the next day that it's part of the grand Red Hat conspiricy to sabotage KDE.
Matt
>Thus, when someone comes up with the brilliant
>idea that the average person should be able to
>actually use the system, they're booed off. Yet
>these boo-ers are the same people who bash the
>mass market for using Microsoft or Apple's OS X.
Let's see.. When I started running Linux way back when I had to manually partition my hard drive, manually configure X (including plugging in video timings for my monitor), manually configure sound (including plugging in I/O addresses and IRQs), had to edit a config file in vi to add icons to my windowmanager (Afterstep Classic), had no real GUI filemanager, took 4 hours to figure out how to get my printer working properly, etc, etc.
Now, I can stick in a CD, have it autopartition, detect all my hardware, configure X, and has a full desktop environment with a GUI filemanager, where I can simply drag an icon to the panel. I can hot plug USB and PCMCIA devices to my heart's content. I can add new hardware, and it will detect and configure it on boot. I can sit back and let my machine take care of keeping itself up to date with all the latest security patches.
I must have missed an AWFUL lot of booing somewhere.
>Right now, when you install pretty much anybody's
>distro,
Except for Lindows, Lycoris, Libranet, OEOne, Xandros...
Come the release of Red Hat 8.0, you can probably add that to the list, given the focus they've put into creating a rational, consistent desktop in the betas.
>you start up with an interface that has tons and >tons of menus, icons, widgets, and whatnot,
>already up and running. It's an overload, and
>instead of trying to learn it, newbies are
>balking at it.
Taken a look at Gnome lately? From an end user perspective, all of the changes in Gnome 2.0 are aimed at usability, accessibility, simplification, and consistency. To paraphrase Havoc, they're removing the "crack rock" features, and "proving one good way of doing things instead of six broken ones".
>So why not have an easy-to-use kernel
>configuration system?
Noone has objected to the concept, only to the implementation. At different points there were issues with the rulesets in CML2 differing from CML1 in ways that the developers didn't agree with. The frontends used a different UI. It globally loaded rules for all architectures.
It has long been Linus' policy not to accept patches which introduce more than one fundamental change. The proper course would have been to make CML2 a drop in replacement for CML1, with no changes to the rulesets, and with front ends that completely emulated the old ones. Then, and only then, discussions on rationalizing the rulesets and providing enhanced interfaces would be appropriate.
Did it solve the problem it set out to solve - i.e. providing a more flexible syntax and a single parsesr? Sure, but it bundled too many other changes, and when you come down to it, it was replacing a system known to work with an unknown one.
On a side note, the whole topic is moot. Does Windows provide you with an easy to use kernel configuration tool? Does MacOS? No, because the end user should NEVER have to configure a kernel.
>Why not have an independent object model, where
>any distribution or window manager can use each
>other's dialog pages?
Umm... what on earth is that supposed to mean?
Matt
>Most of us (myself included) would never put
/etc and KDE config files by default. Oh, and since they only provide binary packages for releases and snapshots, you have to wait for this to compile on each box individually.
>redhat (For example) on a server unless we had no
>other choice, because it is cumbersome.
Define "cumbersome". It's far from rocket science to configure a Red Hat system to have a foot print of only about 150MB, running only the services you want.
Managing a Red Hat system can be done just the same as most other Linux systems. All the standard tools work (ifconfig, fdisk, etc), they follow FHS policies for filesystem layout, and conform to the LSB.
The configuration tools they provide don't destroy changes made by hand like the ones provided by some other distributions do (*cough*YAST*cough*), and their convienence scripts (ifup/down, chkconfig, service) are just that - convienent. They in no way prevent you from manipulating these things by hand (e.g. you can still configure networking with ifconfig, you can still manupulate services by running the scripts in init.d and manually editing symlinks in rc.d).
>We might use gentoo, or slackware instead.
Sorry, but I'd seriously question "most of us", particularly if you include people who actually have real experience administrating servers in a production environment, instead of on their home network.
With Red Hat I can use kickstart to create replicated installation scripts. I boot off a CD, and in 15 minutes the type of machine (e.g. SMTP, POP) is ready to go.
With Slackware I can install each machine individually, or I waste my time developing, debugging and maintaining my own method for replicated installs. I actually did this, before we migrated *off* Slackware (choice of a previous admin who was 0ld sk3wl 31337, when there was only one server).
With Gentoo I have to their gawdawful primitave installer (I'm sorry, but having to manually load modules and set up networking is just stupid), or again waste my time writing my own installer.
With Red Hat I have a robust package management system and a secure update mechanism. They provide critical updates usually within a day, and it only takes me a few minutes to update every machine on my network.
With Slackware I can manually download updates, distribute them to the servers, and install them. Or roll my own system for doing updates. (Starting to see a pattern here?)
With Gentoo I have to emerge the old package, and then unmerge the old one. Mind you, there's no mention of testing to make sure services aren't negatively affected by their files changing underneath them, and "config file protection" is only turned on for
I might have taken your comment more seriously if you had suggested Debian, which does have automated installation available, and provides a laudable upgrade system. On the other hand I've managed a large (~ 100 machine) Slackware installation in the past, and know the downfalls all too well. And Gentoo is, I'm sorry to say, piss in your pants laughable.
>It wasn't fine grained by any definition in 1996,
>It wasn't fine grained when 2.2 come out and
>sections of the kernel are under BKL even in 2.4
>and 2.5 development kernel. Not much difference
>as compared to FreeBSD here.
I never claimed it was historically fine-grained, or completely fine-grained in the current release. I specifically said "relatively fine-grained", which I stand by completely.
The 2.0 kernel was a first implementation, and was dealing with a largely non-threaded kernel. In other words, it was largely bolted onto a code base that had been traditionally uniprocessor.
The 2.2 kernel added fine-grain locks for the scheduler, signal-handling, interupts, and much of the I/O layet
The 2.4 kernel has a multi-threaded TCP/IP stack, I/O layer, VM subsystem, page cache, scheduler, interrupt handler, etc, etc. Most of the traditional BKL bottlenecks *have* been removed.
Is scalability still optimal? No. Hence the word "reasonably".
The implementation of SMP in FreeBSD has been called "simplistic" and "rudimentary" even by the developers. Both 3.x and 4.x rely heavily on the BKL (or Big Giant Lock, or Giant Kernel Lock, or whatever nomenclature you prefer), although 4.x did move portions of the syscall code outside the lock.
It appears that the smpng code in 5.0 will be an immense improvement, in part due to the access developers had to the BSD/OS code base. But for current production releases, the "not much difference" verdict doesn't hold water. Maybe if you were comparing FreeBSD 4.0 against Linux 2.0.
>FreeBSD has is for Alpha and Sparc64 too, check
>your facts before spewing them on public.
I apologize. I had forgotten about the Alpha support, and the Sparc64 support was only added earlier this year, and as far as I can tell only it's only in the as yet unreleased 5.0 branch.
Matt
>BSD is not dying ! Why is everyone saying that ?
>BSD is the best OS in the world, anyone who
>doesn't use it is an utter moron.
Depends on what your criteria are. Just as a quick example, what is the status of SMP support on the free BSD variants? OpenBSD has it in a CVS branch, but it still depends on a BKL (Big Kernel Lock). NetBSD has it, but only for Alpha in current, and AFAIK the only other architecture is i386, which is in CVS, and again depends on a BKL. FreeBSD has it, but only for i386, still has some serious known issues (e.g. race conditions), and won't be fine grained until 5.0 is released.
Contrast this to Linux which has had SMP support built in since 1996, is relatively fine grained, and support x86, Alpha, Sparc, PPC, ia64, MIPS, and s390.
And what kinds of clustering are supported in BSD? How about disk layouts? Filesystems?
No, Linux is by far not perfect in any of these respects. Neither are any commercial operating systems. BSD has its strengths, but it has weaknesses like everyone else.
Matt
>Linux really isn't that great compared to other
>Unices. It is the media darling, partly because
>it fits the "built in someone's garage" cliche.
>It really is an alternative to Windows, and not
>Unix systems.
It depends on what Unix systems you're refering to. Will it replace a 64 processor machine from HP or Sun? No. Will it replace dual processor machines from the same companies? Almost definitely.
In fact, depending on what hardware you're talking about, Linux is a BETTER alternative to traditional Unixes on the low end because it has lower overhead. For example, process creation, syacalls, and context switches are signifigantly (read: as much as 10 times) more expensive on Solaris than on Linux.
>My personal opinion as to why... It has always
>just been something cool to hack away at. Very
>little work has been done to get security and
>stability overall. As an example, take the
>filesystem, EXT2.
Funny how the kernel developers seem to talk about security and stability a whole lot on the mailing lists. Please provide some evidence to back this up.
>Linux rarely gets used on big iron. The only time
>you'll hear about some fast set of machines is in
>something like a cluster, for
>non-mission-critical applications. Even IBM, the
>diehard supporters of Linux, will openly admits
>that it just can't compete with AIX.
And you know what? The majority of servers AREN'T big iron. If you look at the BSDs, Unixware, or Openserver, they're not running on big iron either.
As for only hearing about Linux on fast machines in clusters for "non-mission-critical" applications, I have direct experience to the contrary. I work at a company that bases its entire company (including the services we offer our customers) on Linux, with the exclusion of a handful of Sun machines. The company my brother works at runs their entire network infrastructure (mail, web, nis, nfs, firewalls, routers, vpn tunnels) on Linux.
>Anyone who has used Linux for more than a week >has had an Ext2 filesystem get corrupted. While I
>realize that there are other filesystems now, and
>that example is out-dated, I haven't used Linux
>extensively for a while, so any examples I give >will be outdated.
I've been using Linux for over 7 years without experiencing filesystem corruption that wasn't recoverable with fsck. And this includes managing upwards of two terabytes of data.
Most of the people I hear who claim this are either parroting what they've heard elsewhere, or base their claim that ext2 is prone to corruption on its use of writing metadata async, unlike e.g. ffs. First off, this is only a problem if you've had an unclean shutdown. And second, e2fsck is a fantastic program. I've never had it fail recovery.
And yes, your experience is seriously outdated. Ext3 can journal just metadata, or metadata AND data, which is actually MORE robust than most commercial offerings.
>More than that there are consistency problems. So
>much work is going into adding new features as
>quickly as possible, that stability, consistency,
>and ease of use just goes out the window.
The stable branches of the kernel (2.0, 2.2, 2.4) get only bug fixes and new drivers, NOT new features.
>Compiling a new kernel should be a simple process
>(and one that should be unessecary) but instead
>gives you tons of kernel modules that are
>unuseable.
What makes you think its commonly necessary? In almost three years I've run a total of four kernels - started on 2.2, did an upgrade to fix an Intel driver issue (stupid MII lockups), moved to 2.4, did an upgrade to fix an obscure SG driver bug.
If you're using a distribution, upgrading a kernel can be as simple as a single command (rpm -Uvh). Even if you're building from scratch, you can "make oldconfig" to avoid having to deal with menu options.
As for unusable modules, they don't show up by default. You need to explicitely choose to see experimental features.
>Linux development just has the Windows'
>attitude... Not a Unix attitude. I can't speak
>for anyone else (although it statistically looks
>like I do) but I don't think Linux has a chance
>against stable, secure, consistent,
>high-performance systems. I just think of it as a
>geek toy... Like a Dreamcast
Odd how I can use a "geek toy" to provide e-mail for literally thousands of domains and millions of users.
And what exactly is "the Windows' development attitude"?
Matt
>2. O'Reilly did a survey and more new Mac users
>were coming from the Linux camp than anywhere
>else. From what I've seen of Apple's sales figures
>(latest 10-Q) sales are much too high to be the
>same old Mac users, the new ones are coming from
>somewhere.
So are you just parroting something you heard, or are you deluded enough to think that the "survey" you're refrencing is actually a valid metric of who's migrating from what?
The "survey" consisted of a post to a mailing list, and got only 15 responses.
Matt
>However, I disagree with you and all others (seems
>to be 90% of posters here) who claim that SCO is
>failing in the market. First of all, everybody
>who has worked with UnixWare described it as one
>of the best Unix on any platform.
I've got SCO ACE certification in Openserver and Unixware, SCO Master ACE certification in Non-Stop Clusters and Openserver, and supported as far back as SCO Unix 3.2v4.0 and Unixware 1.1 (as a legacy product after it was purchased by SCO).
Openserver was a nightmare to work with. First off, just BUYING it was a task. Need a licence for the operating system, tcp/ip support, multiple processor support, disk mirroring, and whatever user count you need. If it was an upgrade, you had to know what version you were coming from, how many users you had licensed, what units they were licenced in, etc, etc.
Then you get to buying the hardware to install it on, and half the supported hardware is discontinued. Whoops.
Finally get a system to put it on, and you're greeting with a picky installed worse than what Redhat had on version 3.0.3, which you complete only to have to start the arduous task of installing all the patches and hardware supplements - RS505, OSS471, OSS491, OSS600, etc. And God help you if you accidently installed one out of order, because then its time to roll back, reapply, and pray it goes smoothly so you don't have to reinstall.
After installing nothing but the base operating system and the vendor supplied patches, its time to run a verify on the operating system, because oft times there'd already be issues with permissions and symlinks.
Then maybe you'd want to do a backup to your shiny new DAT drive. Whoops, have to relink the kernel for that. And as you manually type in the location of your tape drive, you accidently put in the wrong bus. When you notice your error you try to delete the device and add it correctly, but it won't go away. Turns out you have to manually edit six different files scattered across the filesystem, including the kernel headers.
Mind you, Unixware was better... at least Unixware 7 was. However the initial releases were buggy as hell, and were a bizarre mixture of SysV, Netwarisms, and Openserverisms.
I think their best bet for carving a niche for themselves was the Non-stop Cluster product. Platform aside, it was a pretty damn slick single system image cluster. I got to play with some of the first ones in existence, and actually built out four of them (two on my own, one while I was assisting a SCO instructor doing an on-site training, and one at an advance training out in Santa Cruz)). Very cool stuff, though it suffered from the expected flakiness of a new product; doubly so since it was built on a brand new operating system.
Unfortunately, it seems that they never managed to capture any marketshare, and from what I can see on the website, it looks like they only offer a high availability solution now.
So what do these products have to offer the market now aside from legacy support, and a few niche markets which are slow to change?
Matt
>My main point should have been this: when you're
>designing a standard, why not go with the best
>format with the longest track record? Why not go
>with apt-get which has been around for what, 4+
>years now, instead of one thats cropped up in the
>last year and isn't as proven?
The LSB specification doesn't specify package management front ends like apt-get; it specifies a package format.
RPM has been around for about seven years, and, whether you like it or not, is used by virtually all of the major Linux distributions (Red Hat, Mandrake, Caldera, SuSE, Turbo).
Add that the majority of what people think is wrong with RPM is based on ignorance or confusion with what a package format is and what a package manager is, and there's no really compelling reason to standardize on what is a fringe package format.
>The only problems I've had with Debian was when I
>was running unstable. Under Redhat I ran into
>dependancy hell when only trying to
>install....sorry you need libz which needs
>libx.2, but libx.2 confilcts with packages a, b
>and c which need libx.1, and so on..
I tend to dislike when people say the other person is lying in an argument, but I'm tempted to here. Maybe if you told me what version of Red Hat wasn't able to resolve dependencies on install, I could go check and maybe believe you.
I don't doubt there are cases where circular dependencies exist, but I honestly have never run into one in the Red Hat provided packages, and haven't run into one for a couple years even with third party packages.
Matt
> consider that Darwin/OS X is installed on more
> computers than all other Unices combined, and
> then rethink your "non-standard GUI" comment.
Do you have figures to back this up? I've heard this claim bandied around a lot by Mac enthusiasts a lot. Or the less extreme, "larger installed base than any other single Unix". Or the even less extreme, "positioned to have a larger installed base than any other single Unix".
But I have never seen figures to back up this claim.
Matt
Noone really has a crush on the support alias for my company? I don't know how I'm going to break the news to it.
>It is accurate enough. If memory serves me right,
>only six files were removed from the codebase as
>part of a lawsuit settlement.
And before that, 90-95% of the code base was rewritten. Which is why I said "the last" of the contested code.
Matt
>npc@temple:(22:40:11):/usr/src/sys/kern]
>grep "UNIX System Lab" *
[snip]
>You were saying...?
And what percentage of the codebase is that? One percent? Even before 4.4lite, it's reported that 90-95% percent of the codebase was rewritten.
Let's say way back when I owned a Packard Bell. Some cool game comes out, so I get a new video card. Then I start running out of space, so I throw in a new hard drive. And then the phone company screws up and doubles voltage, frying my modem, so I replace that. And then I decide I want something faster, so I throw in a new motherboard, processor and memory. Then I want a DVD drive, but there's no room in the case, so I put move the whole thing to a new case.
Am I still running a Packard Bell because I happen to have kept the mouse and sound card from that machine?
If we're going to accept that logic, is Windows XP a BSD since it has Berkeley code in it?
Matt
>I'm not sure what to make of it, but Tim Horton's
>[timhortons.com] in Canada has coffee sizes Small,
>Medium, Large and Extra Large, while in the U.S.,
>the same sizes are Extra Small, Small, Medium and
>Large. Note that the lids on the cup still have
>the S, M, L, XL labels molded in.
I'm in the U.S. and the sizes are labeled Small, Medium, Large and Extra Large.
Matt
>FreeBSD is, in fact, THE free Unix. Linux is a
>Unix clone. FreeBSD is based on Berkeley Unix, and
>is thus, a direct decendant of the original Unix
>source code, not a rewrite. Not that it matters
>much.
It doesn't matter, and it's not really accurate. FreeBSD is based on the 4.4-lite codebase, which is the version that removed the last vestiges of copyrighted USL (Unix Systems Lab) code from the Net/2 codebase released by Berkeley's CSRG (Computer Systems Research Group) as part of a settlement agreement in the lawsuit USL pressed against the BSDI and UCB. So yes, FreeBSD *is* a rewrite.
And even that is somewhat irrelevent, since if you want to be pedantic about the term, UNIX is now a specification and operating systems which are certified to conform to that specification. None of the free Unixes have gone through the certification process, and thus are all "unix-like" and not UNIX.
Matt
(And just as one side note, even if none of the above was true, saying "FreeBSD is THE free Unix" doesn't make sense, since OpenBSD and NetBSD are also derived from the 386BSD codebase, and would therefore qualify under your definition.)
>Read the parent post; I use the example because >it's what he used.
True, I hadn't caught his reference originally. But you still essentially reiterated his misunderstanding about the nature of BDB.
>That said, though, I've seen far too much data
>corruption and too many performance failures in
>Berkeley DB-based apps to trust it.
I think the reliability and performance of BDB is highly dependent on the person writing to it. Since it is decidedly low-level, there are perhaps more caveats, but this doesn't differ that much from an RDBMS implementation.
Matt