Ever talk to Larry McVoy (chief architect behind SunOS 4
Nope. SunOS 4.0 shipped before Larry joined Sun (Larry joined either just before I left, or after I left); I'm not sure there's any one person who could be called a "chief architect behind SunOS 4" - if you consider the new VM system to have been the biggest change in SunOS 4.0, then the main people involved in the design and implementation of it were Bill Shannon, Rob Gingell, and Joe Moran, as I remember.
Larry did stuff for SunOS 4.1[.x], such as the pseudo-extent stuff in the 4.1[.x] file system, and was, I think, the person one might consider the architect of the SPARCcluster-1 system.
Anyway, the thing I'm most curious about is why KDE has one default standard windows manager.
So that somebody can have KDE provide their desktop environment; the window manager provides part of the desktop environment, so KDE includes a window manager.
Unless that particular one is the most customizable wm ever then i don't see the point.
Why would it need to be "the most customizable wm ever"? If somebody wants a different window manager, they can choose a different one, although they may have to tweak files by hand to do so, and not all window managers will necessarily support all the KDEisms that the KDE window manager supports.
Quadruple head support. But this only works if you have four Matrox cards or two G400s.
I have only one video card, but I've decided to do twice as well as Zaphod Beeblebrox, and I now have four heads. Can I use the quadruple-head support?
The name under which the Renault 5 was sold in the US at one time. (Too bad they didn't sell the R5 Turbo - a wacky idea done as, I think, a homologation special; move the engine from the front to behind the driver, make it drive the rear wheels rather than the front wheels, and turbocharge the hell out of it - here.)
Note that when I said "I've used up-arrow under NT4", I meant that I used up-arrow in standard cmd.exe windows, not that I used it in Cygwin shell windows - I usually use ^P in those windows....
Not exactly done right, though it's nice that the shell they use for command.com now allows you to use your up arrow instead of that stupid F3 key. I wonder where they got that from?
The previous release of NT? (I've used up-arrow under NT4 - heck, I didn't even know that F3 did something in a shell window - although most of the command-line typing I do on NT boxes these days is typed at bash.exe, not at cmd.exe, thanks to Cygwin.)
K and G are the obvious contenders now, but things can change very quickly in computers and while I wish these Eazel people luck
You are aware (as Havoc Pennington, GTK+ developer at Red Hat, has pointed out several times in various replies to various comments) that Eazel are not doing a new desktop, they're doing the next generation of file manager for the GNOME dekstop, right?
PS: GNOME supports loads of virtual desktops (in fact 2x2 the default, I don't know what K's default is, it's been a couple of years since I used it, I must try it again actually)
2x2's the default in KDE, as well.
Technically, it's a wm feature isn't it?
The switcher is in the KDE and, I think, GNOME panel, which is a separate program from the wndow manager, so, no, it isn't necessarily a WM feature, although the WM may do some of the work, and one could conceivably run a WM that does its own virtual desktops.
So, GNOME/KDE support but don't implement them
As GNOME doesn't (yet?) have a default standard window manager, if some of the virtual desktop switching is done by the WM rather than by the GNOME panel, one could say that GNOME doesn't (yet?) provide all the support for virtual desktops.
KDE, however, does have a default standard window manager, so it does implement virtual desktops.
Most (if not all) two-letter domains are ISO 3166 country codes, and "CX" is the code for Christmas Island, which is "an Australian Territory" near Java (the Indonesian island, not The Programming Language Formerly Known As Oak:-)).
However, this does not necessarily mean that the Anonymous Coed in question is necessarily on Christmas Island; it is, I suspect, possible to buy Christmas Island domains if you're a non-resident (various other countries, such as Tonga (".to"), do the same).
To switch apps, you would have to walk "outside and down a virtual Main Street to find the correct building/app. yuck...
That makes "switching apps" even more irritating than it is now. I might personally prefer an interface that exposes "apps" somewhat less - for example, if I'm editing a bit of source code, I wouldn't mind being able to put a link into it to a spec for the protocol it implements or dissects, and be able to click on that link, while editing the source code, to pop up a copy of the spec.
I've wondered whether a document/hyperlink-based desktop metaphor might work better for my files - source files, specifications, notes to myself, Web pages on other sites, saved netnews articles, saved mail messages, etc., etc. - than the directory-based metaphor used by existing OSes/desktops. I hate having to manually search for the damn mail message/note-to-myself file/whatever that explained how to do XXX....
In X, you middle-click to paste highlighted text, or if you have a two-button mouse, press the right and left buttons at the same time.
But what if you want to paste something other than the highlighted text? What if, for example, you highlighted some block of text, copied it to the clipboard, and then want to replace some other block of text with the copied text, by highlighting that other block of text and then pasting the copied text?
Paste-current-selection is not, the apparent belief of some UNIX/X users nonwithstanding, the be-all and end-all of cut-and-paste in UNIX/X.
The problem he had with the KDE editor and Netscape probably stems from Qt not pasting to the damn clipboard; if a Qt application (such as a KDE application) does a paste with a Qt call, it pastes to the primary selection, rather than the clipboard, so that applications that implement "Paste" (not "paste current selection", "Paste") as "paste clipboard" don't work with Qt applications.
I have no idea why the folks at Troll Tech decided to do this. It has apparently, on at least two occasions, violated the principle of least surprise (the person to whom you're responding didn't get what they expected, and somebody in another Slashdot thread ages ago had a similar problem, which is what prompted me to go look at the Qt source and discover that it paid no attention to the X clipboard). GTK+, and probably at least some other toolkits (e.g., Motif, that being what the current Netscape uses), behave correctly here. I consider this an example of the sort of inconsistency the person about which the person to whom you're replying was complaining.
(On the other hand, Quicken 2000 for Windows, for some unknown reason, doesn't use Ctrl-C/Ctrl-X/Ctrl-V for copy/cut/paste, so UNIX/X isn't the only platform with applications that sometimes don't quite match other stuff running on the platform. It's also irritating that the "OK" box in some dialogue boxes in Quicken, such as the one for Split items, doesn't seem to be activated by the key - that key just takes you to the next line, which makes some sense, but I just want to be able to enter the entire damn transaction without taking my hands off the damn keyboard.)
Yes, using the middle button for paste-current-selection is, in many circumstances, a workaround, and often obviates the need for cut-and-paste or copy-and-paste - but I wouldn't assume that it always obviates the need for it.
But it's not something that a real UNIX pro would use.
Define "use".
I've done UNIX development, both kernel and userland, since 1977-1978 or so.
I use a KDE desktop on my machine at home, including using, shock horror, the file manager for some things (I have a few PDF standards documents, and I find it more convenient to have a "Standards" folder on my desktop, and click it open, and then click on the relevant subdirectory and click on the document I'm interested in, than to go find an xterm not running something or put what's running there in the background, pushd to the appropriate directory, and fire up Acroread on the file in question). I also have another desktop icon to fire up xmms and have it play a local radio station.
Now, for administrative stuff (on the rare occasion that it's necessary), I'll just go tweak the config files directly, blah blah blah - but there are, your apparent belief to the contrary nonwithstanding, reasons why "a real UNIX pro" might well use a file manager (why should I waste a perfectly good xterm firing up Acroread, when I could be using it to do compiles, or greps, or...?:-)).
One thing that would be good is to add kernel support for Windows binaries so that a Win32 emulator could be made.
"Kernel support" in what sense? Supporting exec-family calls being able to run Windows binaries (which may just involve telling the kernel to fire up Wine on them)? Or support in the kernel as necessary to make Wine work better? Or both?
Jakob Neilsen has some interesting stuff on his Web site, such as his Death of File Systems paper, on why he thinks that the hierarchical directory tree model isn't necessarily what you want to expose to the end user; there's also a paper by him and Don Gentner, Anti-Mac, with thoughts on what a different-and-possibly-better user interface might look like.
Because whatever standard is chosen will be the one that is easiest for complete newbies (no virtual desktops, either 2-button or, god forbid, 1 button).
Indeed? The two biggest desktop candidates both, as far as I know:
support virtual desktops (KDE definitely, GNOME almost certainly);
support 3 mouse buttons (with the "standard" UNIX/X interpretations for common cases).
In addition to the normal "update everything at once" that all GNOME users have to do, he has to go through and patch all the Linux-isms.
Is he then sending those changes back to the GNOME folks? If not, he should (assuming he hasn't already done that without success). If so, are the GNOME folks then picking them up (assuming they don't break other platforms, say)? If not, they probably should.
This is one of the problems right now in general, in that the skill of portable programming is fading and many (certainly not all) coders are writing for Linux not Unix.
Is it fading, or was it not ever there as much as one might like? I.e., is this a case of programmers now writing for Linux rather than, when possible, generic UNIX, or is it a case of programmers now writing for Linux rather than writing for, say, 4.2BSD, or SunOS 4.x, or...?
(And are they writing for Linux, or for Linux/x86? "I don't have to worry whether this pointer points to an address aligned on a 4-byte boundary, right?" If you want your code to run on all the various non-x86 Linux systems, much less non-x86 non-Linux systems, yes, you do.)
I think TM should at least document the instruction set for their chips
You left an "s" out following "instruction set"; Transmeta's technical white paper on Crusoe says on pages 7 and 8 that "the native ISA of the model TM5400 is an enhancement (neither forward nor backward compatible) of the model TM3120's ISA and therefore runs a different version of Code Morphing software."
As others have noted, publishing the native instruction set architecture may trap them into continuing to provide products that implement that ISA (or writing a binary-to-binary translator (he says, avoiding the "CM" phrase) to map that ISA to the new chip's native ISA), and that appears to be one thing they don't want to do - they want to be able to change the internal instruction set from product to product as they think appropriate.
} % gcc -c -O2 -Wall foo.c foo.c: In function `foo': foo.c:10: warning: unused variable `a' foo.c: At top level: foo.c:3: warning: `unused' defined but not used
although it doesn't get the other two (although "function arguments that aren't referenced" are sometimes desirable if the function is called through a pointer, and some functions pointed to do use the argument in question; other times, though, it's an indication of an error).
To gcc's credit, it does do some pretty spiffy control-flow analysis with -O9
Does -O9 do better than, say, -O2?
(One problem with said flow analysis is that it sometimes gives "false hits", so one occasionally either has to filter out the noise or stick in an unnecessary initialization.)
Back to gcc, I'll have to try -W along with -Wall... that really turns up the analness?
I don't think so. The man page says:
-W Print extra warning messages for these events:
[list of events elided]
...
-Wall All of the above `-W' options combined. These are all the options which pertain to usage that we recommend avoiding and that we believe is easy to avoid, even in conjunction with macros.
so -Wall would appear to include -W.
(At work, we compile the software for our products with -Wall, some other -W options to insist that functions have prototype declarations to increase the chances that a prototype declaration will be available when the function is called, and-Werror to ensure that if you violate the rules you don't get an image to download to the box....)
BSD/dev is quite different to Linux. BSD doesn't have/proc.
Gee, don't tell my FreeBSD partition that:
% uname -sr FreeBSD 3.4-RELEASE % ls -l/proc total 30 dr-xr-xr-x 13 root wheel 512 Feb 16 22:46 0 dr-xr-xr-x 13 root wheel 512 Feb 16 22:46 1 dr-xr-xr-x 13 root wheel 512 Feb 16 22:46 121 dr-xr-xr-x 13 daemon wheel 512 Feb 16 22:46 130 ...
It doesn't have a/proc exactly like Linux's, but that's a different matter (and one might consider that a feature, not a bug; it's perhaps nice to have most system information readable and writable through the file system, but whether stuff unrelated to processes belongs under/proc rather than on some other pseudo-file-system, or whether it should be in a form designed for humans to read rather than for programs and shell scripts to read, is another matter).
The best part about commercial software providers wanting to port to FreeBSD is that it makes porting to Darwin and MacOS X from there practically trivial, especially for server apps.
You might want to rephrase that as "at least for server apps"; GUI apps are probably unlikely to port very well at all (unless the OpenStep folk turn themselves into the OpenCocoa folk, complete with a Display PDF implementation - and perhaps unless an OpenCarbon group starts up as well).
(That's probably what you meant, but people sometimes seem to move from "Darwin has a BSD API and a lot of BSD code" to "therefore it's easy to port MacOS X applications to BSD" or "...to UNIX".)
Slashdot Mirror
Nope. SunOS 4.0 shipped before Larry joined Sun (Larry joined either just before I left, or after I left); I'm not sure there's any one person who could be called a "chief architect behind SunOS 4" - if you consider the new VM system to have been the biggest change in SunOS 4.0, then the main people involved in the design and implementation of it were Bill Shannon, Rob Gingell, and Joe Moran, as I remember.
Larry did stuff for SunOS 4.1[.x], such as the pseudo-extent stuff in the 4.1[.x] file system, and was, I think, the person one might consider the architect of the SPARCcluster-1 system.
So that somebody can have KDE provide their desktop environment; the window manager provides part of the desktop environment, so KDE includes a window manager.
Why would it need to be "the most customizable wm ever"? If somebody wants a different window manager, they can choose a different one, although they may have to tweak files by hand to do so, and not all window managers will necessarily support all the KDEisms that the KDE window manager supports.
I have only one video card, but I've decided to do twice as well as Zaphod Beeblebrox, and I now have four heads. Can I use the quadruple-head support?
Nice to know they're using the latest and greatest hardware....
The name under which the Renault 5 was sold in the US at one time. (Too bad they didn't sell the R5 Turbo - a wacky idea done as, I think, a homologation special; move the engine from the front to behind the driver, make it drive the rear wheels rather than the front wheels, and turbocharge the hell out of it - here.)
Can't help you for ^U^O, but for tab completion, this article says there's a (surprise, surprise) hidden registry knob to tweak to get tab completion.
Of course, you can just use bash and be done with it, by installing Cygwin.
Note that when I said "I've used up-arrow under NT4", I meant that I used up-arrow in standard cmd.exe windows, not that I used it in Cygwin shell windows - I usually use ^P in those windows....
The previous release of NT? (I've used up-arrow under NT4 - heck, I didn't even know that F3 did something in a shell window - although most of the command-line typing I do on NT boxes these days is typed at bash.exe, not at cmd.exe, thanks to Cygwin.)
You are aware (as Havoc Pennington, GTK+ developer at Red Hat, has pointed out several times in various replies to various comments) that Eazel are not doing a new desktop, they're doing the next generation of file manager for the GNOME dekstop, right?
2x2's the default in KDE, as well.
The switcher is in the KDE and, I think, GNOME panel, which is a separate program from the wndow manager, so, no, it isn't necessarily a WM feature, although the WM may do some of the work, and one could conceivably run a WM that does its own virtual desktops.
As GNOME doesn't (yet?) have a default standard window manager, if some of the virtual desktop switching is done by the WM rather than by the GNOME panel, one could say that GNOME doesn't (yet?) provide all the support for virtual desktops.
KDE, however, does have a default standard window manager, so it does implement virtual desktops.
Most (if not all) two-letter domains are ISO 3166 country codes, and "CX" is the code for Christmas Island, which is "an Australian Territory" near Java (the Indonesian island, not The Programming Language Formerly Known As Oak :-)).
However, this does not necessarily mean that the Anonymous Coed in question is necessarily on Christmas Island; it is, I suspect, possible to buy Christmas Island domains if you're a non-resident (various other countries, such as Tonga (".to"), do the same).
That makes "switching apps" even more irritating than it is now. I might personally prefer an interface that exposes "apps" somewhat less - for example, if I'm editing a bit of source code, I wouldn't mind being able to put a link into it to a spec for the protocol it implements or dissects, and be able to click on that link, while editing the source code, to pop up a copy of the spec.
I've wondered whether a document/hyperlink-based desktop metaphor might work better for my files - source files, specifications, notes to myself, Web pages on other sites, saved netnews articles, saved mail messages, etc., etc. - than the directory-based metaphor used by existing OSes/desktops. I hate having to manually search for the damn mail message/note-to-myself file/whatever that explained how to do XXX....
Havoc Pennington, GTK+ developer at Red Hat, said in this article:
But what if you want to paste something other than the highlighted text? What if, for example, you highlighted some block of text, copied it to the clipboard, and then want to replace some other block of text with the copied text, by highlighting that other block of text and then pasting the copied text?
Paste-current-selection is not, the apparent belief of some UNIX/X users nonwithstanding, the be-all and end-all of cut-and-paste in UNIX/X.
The problem he had with the KDE editor and Netscape probably stems from Qt not pasting to the damn clipboard; if a Qt application (such as a KDE application) does a paste with a Qt call, it pastes to the primary selection, rather than the clipboard, so that applications that implement "Paste" (not "paste current selection", "Paste") as "paste clipboard" don't work with Qt applications.
I have no idea why the folks at Troll Tech decided to do this. It has apparently, on at least two occasions, violated the principle of least surprise (the person to whom you're responding didn't get what they expected, and somebody in another Slashdot thread ages ago had a similar problem, which is what prompted me to go look at the Qt source and discover that it paid no attention to the X clipboard). GTK+, and probably at least some other toolkits (e.g., Motif, that being what the current Netscape uses), behave correctly here. I consider this an example of the sort of inconsistency the person about which the person to whom you're replying was complaining.
(On the other hand, Quicken 2000 for Windows, for some unknown reason, doesn't use Ctrl-C/Ctrl-X/Ctrl-V for copy/cut/paste, so UNIX/X isn't the only platform with applications that sometimes don't quite match other stuff running on the platform. It's also irritating that the "OK" box in some dialogue boxes in Quicken, such as the one for Split items, doesn't seem to be activated by the key - that key just takes you to the next line, which makes some sense, but I just want to be able to enter the entire damn transaction without taking my hands off the damn keyboard.)
Yes, using the middle button for paste-current-selection is, in many circumstances, a workaround, and often obviates the need for cut-and-paste or copy-and-paste - but I wouldn't assume that it always obviates the need for it.
Define "use".
I've done UNIX development, both kernel and userland, since 1977-1978 or so.
I use a KDE desktop on my machine at home, including using, shock horror, the file manager for some things (I have a few PDF standards documents, and I find it more convenient to have a "Standards" folder on my desktop, and click it open, and then click on the relevant subdirectory and click on the document I'm interested in, than to go find an xterm not running something or put what's running there in the background, pushd to the appropriate directory, and fire up Acroread on the file in question). I also have another desktop icon to fire up xmms and have it play a local radio station.
Now, for administrative stuff (on the rare occasion that it's necessary), I'll just go tweak the config files directly, blah blah blah - but there are, your apparent belief to the contrary nonwithstanding, reasons why "a real UNIX pro" might well use a file manager (why should I waste a perfectly good xterm firing up Acroread, when I could be using it to do compiles, or greps, or...? :-)).
"Kernel support" in what sense? Supporting exec-family calls being able to run Windows binaries (which may just involve telling the kernel to fire up Wine on them)? Or support in the kernel as necessary to make Wine work better? Or both?
Jakob Neilsen has some interesting stuff on his Web site, such as his Death of File Systems paper, on why he thinks that the hierarchical directory tree model isn't necessarily what you want to expose to the end user; there's also a paper by him and Don Gentner, Anti-Mac, with thoughts on what a different-and-possibly-better user interface might look like.
Indeed? The two biggest desktop candidates both, as far as I know:
Is he then sending those changes back to the GNOME folks? If not, he should (assuming he hasn't already done that without success). If so, are the GNOME folks then picking them up (assuming they don't break other platforms, say)? If not, they probably should.
Is it fading, or was it not ever there as much as one might like? I.e., is this a case of programmers now writing for Linux rather than, when possible, generic UNIX, or is it a case of programmers now writing for Linux rather than writing for, say, 4.2BSD, or SunOS 4.x, or...?
(And are they writing for Linux, or for Linux/x86? "I don't have to worry whether this pointer points to an address aligned on a 4-byte boundary, right?" If you want your code to run on all the various non-x86 Linux systems, much less non-x86 non-Linux systems, yes, you do.)
I.e., components, such as Nautilus and, I think, the KDE 2.0 file manager will use?
There are other ways to link tools together than to build shell scripts, pipelines, and the like.
Well, that's annoying; any idea what the rationale for not including the -W warnings in the list of "all" (not-too-hard-to-eliminate) warnings was?
Oh, well, time to tweak the recipe files from which Makefiles are built at work, and to tweak Makefile.am for Ethereal....
You left an "s" out following "instruction set"; Transmeta's technical white paper on Crusoe says on pages 7 and 8 that "the native ISA of the model TM5400 is an enhancement (neither forward nor backward compatible) of the model TM3120's ISA and therefore runs a different version of Code Morphing software."
As others have noted, publishing the native instruction set architecture may trap them into continuing to provide products that implement that ISA (or writing a binary-to-binary translator (he says, avoiding the "CM" phrase) to map that ISA to the new chip's native ISA), and that appears to be one thing they don't want to do - they want to be able to change the internal instruction set from product to product as they think appropriate.
although it doesn't get the other two (although "function arguments that aren't referenced" are sometimes desirable if the function is called through a pointer, and some functions pointed to do use the argument in question; other times, though, it's an indication of an error).
Does -O9 do better than, say, -O2?
(One problem with said flow analysis is that it sometimes gives "false hits", so one occasionally either has to filter out the noise or stick in an unnecessary initialization.)
I don't think so. The man page says:
so -Wall would appear to include -W.
(At work, we compile the software for our products with -Wall, some other -W options to insist that functions have prototype declarations to increase the chances that a prototype declaration will be available when the function is called, and -Werror to ensure that if you violate the rules you don't get an image to download to the box....)
BDS is one of the leading coin and commercial laundry equipment companies in North America.
Gee, don't tell my FreeBSD partition that:
It doesn't have a /proc exactly like Linux's, but that's a different matter (and one might consider that a feature, not a bug; it's perhaps nice to have most system information readable and writable through the file system, but whether stuff unrelated to processes belongs under /proc rather than on some other pseudo-file-system, or whether it should be in a form designed for humans to read rather than for programs and shell scripts to read, is another matter).
You might want to rephrase that as "at least for server apps"; GUI apps are probably unlikely to port very well at all (unless the OpenStep folk turn themselves into the OpenCocoa folk, complete with a Display PDF implementation - and perhaps unless an OpenCarbon group starts up as well).
(That's probably what you meant, but people sometimes seem to move from "Darwin has a BSD API and a lot of BSD code" to "therefore it's easy to port MacOS X applications to BSD" or "...to UNIX".)