Date: Tue, 20 Nov 2001 20:00:50 -0600 From: Mike Meyer <mwm@mired.org> To: "Anthony Atkielski" <anthony@atkielski.com> Cc: <questions@freebsd.org> Subject: Re: home pc use Message-ID: <15355.2770.644343.846234@guru.mired.org> In-Reply-To: <019701c17224$013e6520$0a00000a@atkielski.com> References: <15354.60877.44081.17515@guru.mired.org> <019701c17224$013e6520$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@atkielski.com> types: > Mike writes: > > > Try the following: > > > > $ cd > > $ mv .xinitrc save.xinitrc > > $ echo netscape > .xinitrc > > $ startx > > Poof. You're now running netscape without a > > window manager. > Fascinating. I don't care for Netscape, but I presume I could do the same with > the Linux version of Opera. You can do it with any X application. > > From the sysadmins point of view, this was great. > > You only had to manage one system, as the boxes > > you put on desks didn't require management beyond > > the power switch. It also provided the kind of user > > mobility in the late 80s and early 90s that > > Windows didn't get until the last few years. > So are X Terminals still in common use? If not, why not? They sound like an > excellent solution to a recurring problem with Windows (namely, the fact that > users tend to screw up machines that they can fiddle with themselves). No, they've died. [Begin rant] They died because users want to "own" their things. They don't want to have to trust their data to some central server controlled by the IT staff, though they expect the IT staff to back up their machines. [end rant] > > Actually, the thought of moving *any* production > > environment from one OS to another is chilling. > I learned the hard way that just going from one release to the next--or even > just applying the latest set of patches--can be pretty chilling, too. Yup. Never run .0 releases on production machines. Always test patches, etc. on non-production machines *first*. Even then, you may get bit, because the patches you tested on the test machine clash with patches on the production machine that weren't on the test machine. The short version of this is "computers suck." > > That's one of the things that IBM depended > > on for cash flow, and that MS depends on now. > Yes, all PC software companies depend on it. Unfortunately, that situation > cannot endure. I'm a bit confused myself because, on the one hand, I know that > Microsoft has little choice but to go to the XP model of "pay forever," but on > the other hand, I'm absolutely opposed to paying for anything of the kind > myself. Indeed, the day I got my FreeBSD system was the day after Windows XP > went on sale. There are those who claim that XP is going to shake out all the people who don't want to pay for an OS. On the other hand, I've already been offered a copy of XP Professional that supposedly had the code that enforces the "pay forever" model ripped out. > I worry about open-source products like FreeBSD, too. It's great to have such > nice software for free, but where is the money going to come from to keep such > products alive? Money isn't the crucial resource, programmer time is. After all, that's where the money mostly goes. Some of it goes to marketing, but that's because more programmers using FreeBSD means more programmers working on keeping the product alive. And the programmer time for all this is going to come from the same place it's always come from - the programmers that are using it. > > Exactly. If I wanted to clone Windows, I wouldn't > > run FreeBSD on my desktop. > Agreed. That's why FreeBSD has just a plain text console on my desktop right > now. There are *lots* of other options. > > I don't use window managers that provide > > drop shadows or icons. > Which window manager provides the cleanest desktop under UNIX? You're confusing two issues again. There are "desktop" managers and "window" managers. The two desktop managers available for FreeBSD KDE and Gnome; the only other Unix deskopt manager I know of is CDE. I don't run any of them, so I can't be sure of the exact relationship, only that there some window managers are "compliant" with some desktop managers, and some not. Oh yeah - and that people who write simple window managers generally have evil things to say about what it takes to be compliant. I don't believe there's a clean desktop manager. Ratpoison is the cleanest window manager. I discussed that at length elsewhere in my reply. > Also, if the > window manager is just another X client, how does it manage to influence the > appearance of windows created by other clients? The only appearance it really gets to influence is the frame - which the window manager draws. Various things done by the window manager and the client get passed back and forth through the X server - windows opening, closing and resizing being typical - so they can react appropriately. > > Well, nobody sells FreeBSD, but it sees a lot > > of use in production environments with exactly > > that level of support. > I meant selling in the sense of successful advocacy. You mean inside the company. > > Doesn't sound like you've had much experience > > with commercially supported OS tech support. > On the contrary, I've had a ton of experience, on _both_ sides of that fence. > But if you have a hotline, you can tell your management that the vendor is > working on something, and then the pressure is off. Making no progress when the > ball is in the vendor's court is _much_ different from making no progress when > the ball is in your court. If you've got sufficiently good - or stupid - management, you *can* tell them you're waiting on an answer from the support list. The ball is no longer in your court. > > Telling managers "I'm waiting for an answer > > from vendor tech support" is a *very* common > > occurence with them. > Yes, and it works well. But it only works if there _is_ a vendor tech support. You do know you can buy tech support for FreeBSD if you really want it, don't you? That means you're paying someone else to ask -questions :-). > Many vendors have an implicit or even an explicit obligation of performance in > their support contracts, so managers know that it can't ride forever, and even > if it does, they can get a lot of mileage out of saying the vendor is looking > into it. You got it right the second time - it can ride forever, and you're getting milage out of giving someone else grief over it. Which is what you're really paying for when you buy tech support - the right to give someone else grief over it. > > If you can find the .001% of applications that > > aren't useless in the .1% that don't run on Windows, > > you'll do fine. > The chances of finding such an application would be the product of these two > probabilities--or one in one hundred million. I agree - the chances of a typical user having a use for an application that is only available under Windows is about one in one hundred million. > > You can build an almost complete web development > > environment on FreeBSD. > Probably. What would be the nearest equivalent of Visual InterDev on FreeBSD? > I wouldn't need any of the fancy features, just something to manage the files in > a Web-friendly way, and a nice source editor like Visual InterDev has. Does it have to be an integrated tool? I have as yet to find a point-n-clicky html or xml editor that was as nice as psgml mode in emacs. You'll also have to describe what fice management features you want. > > ... because MSIE is your typical buggy MS trash, so > > you have to QA against it to find out where they > > aren't following the standards. > In the most recent independent tests I've seen, MSIE adheres to Web standards > better than any other browser. Only Opera makes a comparably good showing. > Netscape is significantly behind, even in version 6.x; the old version 4.x had > thousands of bugs and isn't even in the running (never was, actually). Sounds like things have improved radically since I got sick of dealing with it. From the looks of the web, MS still supports their extensions, as that's what people are using. > > Since MSIE runs on Solaris/SPARC, you can put > > together a complete web development environment > > on that Unix platform. > But that wouldn't be free. Being in the clutches of Sun is at least as bad as > being in the clutches of MS. Having been in the clutches of Sun (and DEC, and IBM, and a few others), I have to disagree. For one thing, Sun supports their product, instead of palming support off on resellers so they don't have to deal with bugs. Second, Sun provides a platform that adheres to some of the Unix standards, so most of the software that works on your typical FreeBSD server will work on it. That latter is the real difference. Writing an application that works in a GUI environment on both Windows and other platforms is a PITA, and MS is doing everything they can to keep it that way. This means that, as you point out, lots of applications only run on Windows. Should you wind up with critical functionality in such an application, you're hosed. Most of the people selling applications for Sun sell it for other platforms, and migrating the data is straightforward. Maybe not trivial, but it's at least there. > > Since it's not repeating, I'd write it off as a > > hardware hiccup. > That is almost my conclusion, but I tend to write it off as a software bug that > occurs only under some weird set of hardware conditions. As long as it is not > occurring again and again, I'm not too worried about it. Already I am running a > card with no support (some sort of GeForce card--it came with the hardware, but > I run it in plain text mode), so perhaps it hit something there. The processor > gets pretty warm with setiathome (49 degrees), but that still seems to be within > limits, and in any case, as far as I know neither chipset/MB nor the AMD > processor has any provision to boot the system if the temperature gets too high. We used to call these "stray alpha particles". Basically, some bit in the system got into a state it didn't belong in, and it went kerplop. Whether this is a hardware bug, because it shoudn't do that, or a software bug, because the software should catch it doing that, is sort of moot. > > If that doesn't satisfy you, make sure you're > > set up to capture core dumps, be prepared to debug > > them, and wait for it to happen again. > Dumps are not produced by default? And if it was a hard reboot (branching to > the initialization address in the BIOS, or something), how would FreeBSD get a > dump? Dumps are not produced by default. The question then is - what happened to produce the hard reboot? If someone power cycled the thing or some such, it won't have a dump. All traps in kernel mode go through a procedure that does a core dump before rebooting the machine. If you've got a problem that's causing a hard reboot without creating a trap in kernel mode, you've got a *nasty* problem. Since it's not repeatable, it's hard to tell. > > KDE is not an X server. KDE is a desktop environment. > > It can be run on any machine with IP connectivity > > to the X server. > Including a Windows machine? Or would I still have to spend hundreds of dollars > on an X server for Windows to do that? I have no idea if KDE can be compiled to run on a Windows machine. However, it isn't an X server, it has to have one to talk to. Let's go over the parts again: You have a display device, which is usually hardware. You have an X server, which talks to the display device directly. There are X servers - see Xnest in the XFree86-4 port or the VNC port for examples - which don't use display hardware, but talk to other software which talks to the hardware. More on that in a bit. You then have window managers and desktop managers. They are both clients of the X server, and they talk to each other somehow. Finally, you have real applications, which are clients of the X server, and may also be clients of the desktop manager - at least, some of the things in the ports tree are tagged as "for KDE" or "for GNOME". Back to "soft" X servers. Xnest opens one or more windows on an X server, and then listens for X requests like any other X server. It implements the requests inside of the windows on the X server. It's a nice tool if you want to play with window managers, as you can run a window manager on the Xnest server that's different than the one you're using on the server that Xnest is a client of. I recently used it to fix the support for multiple screens in ratpoison. VNC does the same kind of thing, only it's not limited to X, and it's split into two halves. A VNC server provides a workspace that depends on the system it's running on. On Unix, it's an X server whose "display hardware" is actually the VNC client. As such, you can have KDE talking to it. There are VNC servers for Windows - even Win95 - and clients for damn near anything that moves: X, Windows, VGA, Palms, high-end cell phones, and java-enabled web browsers. Are you sufficiently confused yet? <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15355.2770.644343.846234>