Domain names are not supposed to point to ANYTHING. *Host* names are supposed to point to machines, and technically, a given name can't be both a domain name and a hostname.
Since when? Do you have an RFC cite for this? DNS is quite unopinionated on the subject - host names and domain names are treated the same.
But somewhere in the mid-90s the web grew to be the Most Important Thing On the Internet, and it became normal practice to basically make one's domain name also a hostname pointed to one's web server.
I remember back in '93 hmc.edu used this technique, but not for a web site. It had an MX record, but some broken mail clients of the day did not consult MX records, so it also had an A record for the appropriate IP address.
I believe this was a widespread technique to work around these broken mail clients long before the web became popular, although I don't have any evidence to back this up.
It certainly would be dangerous for someone with blood sugar control problems (e.g., diabetic), although if the implant is smart enough, it might be able to _provide_ that control for someone.
Yeah, that's what I was thinking. The device would not allow whatever blood chemicals it consumed (probably the glucose) to fall below a specific level.
For those of us whose level of physical activity is much lower than our calorie intake, this kind of implant might be the only "practical" barrier between us & obesity:-)
Sure. (:
Of course, there is the nontrivial barrier of inventing an artificial form of cellular respiration (or other means of extracting energy from glucose) that will fit in whatever physical constraints this device needs to have.
Here's one I didn't notice in the article. How about sucking chemical energy from blood chemicals? Basically we're talking about a dialysis-like blood filter that pulls out stuff like glucose and fatty acids and does its own cellular respiration.
Good for controlling your weight... diabetes... arteriosclerosis... but bad for maintaining high energy and preventing chronic fatigue... hmmm, maybe it isn't such a good idea. (:
I work for the unix dept. at the claremont colleges (just outside of LA), 7 schools (averaging about 800 students each), on a single class B.
134.173.*.*, yeah baby. I remember sittin' at Mudd back in '93 sort of feelin' sorry for all those latecomer colleges that had to make do with multiple class C's. (:
To get good movements etc, a real actor could control all the movements with the CG character being essentially a mask. I'm thinking of a sort of vr situation, whith the results saved & edited.
It's called motion capture, and animation houses definitely use it. Not to the extent that you're talking about (where every significant movement is captured) but it's used for things like gestures.
I agree with you that mocap is only going to increase in animation production.
However, this sounds like a bug to me, because a machine's NetBIOS name doesn't have to be the same as it's DNS name.
Not only that, but NetBIOS names are not even analogous to DNS names. A DNS name is presumed to be for a single server (in practice, of course, it is often round-robin, but that's the theory anyway) whereas a NetBIOS name is per-service on a given server.
Sure, on an average Win95 box or NT workstation you don't see much difference, but do a NetBIOS name status query ('nbtstat -a' on Windows, 'nmblookup -S' on Unix with Samba) on a domain controller, Exchange server and/or IIS server some time. All three add funky names to the namespace advertising their services.
Which isn't to say DNS-lookup-via-NetBIOS-names doesn't work (it does) but it's conceptually wrong.
I don't see where someone would be clueful enough to set up a WINS server but not a DNS server;
No doubt you are right, but by WINS lookup I meant NetBIOS name lookup (you know, the "other" Microsoft definition of WINS), not necessarily via a WINS server. NetBIOS names are more or less plug-n-play on a simple network topology.
NetBIOS is a M$ hack that lets you use SMB file sharing over a TCP/IP network.
<lie>I hate to be pedantic</lie>, but NetBIOS is SMB file sharing (and printing, and MSRPC). The M$ hack you are thinking of is NBT, or NetBIOS-over-TCP/IP. NBT includes NBNS, the NetBIOS name service, which Microsoft calls WINS. The other confusing bit is that Microsoft sometimes uses "WINS" to refer to "NBT name resolution by any mechanism", and sometimes to mean "NBT name resolution by consulting an NBNS server".
And... while ordinarily WINS has nothing to do with email delivery, in Microsoft land this is not always true - the TCP/IP stack will use NetBIOS to look up what should be DNS names - sometimes, at least - before falling back to DNS. I'm not sure whether to consider this a bug or a feature, because it would help in a case where you run an internal web server ("intranet" in LRMT, the Lexicon of Redundant and Misleading Terms) but are too clueless to run your own DNS.
(Whether such people should be encouraged to manage a web server at all is an open question.)
Wasn't there something about an NSA key/door discovered in WinNT4.x not so long ago?
Allegedly. I guess some bonehead at Microsoft accidentally shipped a service pack without stripping the symbols (meaning: all the names of global variables and functions that aren't usually exported were visible). And someone was looking through the symbols and found a variable in the crypto module called NSAKEY, whose value turned out to be a valid key (distinct from the usual Microsoft key) for things like code signing for upgrades. The immediate peanut gallery theory emerged that this key was held in escrow by the NSA in case they ever needed to send anyone a spyware trojan.
Microsoft came up with an alternate explanation, of course, which I don't remember off hand, but it sounded at least semi-plausible. I imagine we'll never know.
HTTP/1.1 (which I see as offering the tools needed to surpass FTP) may have to make use of a second connection at times, IIRC, though.
Really? I've never heard that. I've always thought HTTP did everything in-band.
But where's the application support beyond "see the file, click on the link"? Please point me in the direction of a robust and well-supported HTTP agent that can duplicate the functionality of any standard FTP client. Please.
Point taken. I guess the difficulty is that nobody has thought to build an interactive HTTP client that assumes "nothing on the page is really useful HTML, just snarf the links and assume they are files in a directory". Not insurmountable, by any means.
Speaking of "useful HTML", note that HTTP has one feature over FTP that I forgot about until now. Content-type! The server can be configured to know what its own content types are. With FTP, the client has to guess if the files are binary or ascii, which blows chunks, and doesn't allow for finer-grained content types - you end up relying on "well-known" filename extensions, which is confining.
I'm not so certain about this. I haven't seen many auth methods implemented in clients other than https
What? You've never tried to go to a page and been presented with a pop-up box asking you for user and password for such-and-such an authentication domain?
HTTP defines the "Auth-Type" header, with the two commonly supported methods "Basic" and "Digest" (the latter does not send cleartext passwords). The web server can trigger an auth request for any page it wants to, and popular web servers have ways to tie this in to your system user list, a custom list, a user database query, etc.
Of course you also have cookie-based authentication, which you just now used to post to Slashdot. And URL-based "poor man's cookies".
1. Error recovery and restart from an arbitary point in a given file;
Several command-line http clients implement "reget" functionality using the "Range" or "Byte-Range" (whatever it's called) HTTP header, which I think (but am not sure) even/1.0 supports.
2. Recursive download;
Again, command-line clients like GNU wget usually support "suck mode" where they recursively follow links from pages downloaded as long as the links stay within a base URL. You can easily pull down a whole web site that way if you wish, assuming none of it is server-parsed. No reason a more interactive client couldn't do the same.
Hmmm, there's one I truly hadn't thought of. Again, the HTTP protocol support is there, using the "Auth-Type" header.
5. The flexibility of a system built for file transfer... this is what I'm looking for and it is difficult to describe succinctly. Is there an HTTP client as friendly and flexible as FTP as far as the mechanics of file access is concerned?
There's the problem, and there is where you've convinced me that FTP is not dead yet. Nobody has written a proper interactive HTTP download client that doesn't look and act like a web browser.
I simply question the view that HTTP is a simple (and better) replacement for FTP.
For uploads, FTP is still probably better, if only because nobody seems to use the HTTP PUT command.
For downloads, though...
both require a new connection for each dir listing or file transfer - except HTTP/1.1 which can reuse a connection. HTTP wins.
FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.
Many sites are already running an HTTP server, so using that for file transfer means one less daemon. Mitigated by running ftpd out of inetd, which most people do, but still... HTTP wins.
HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories (without using Unix permissions, which can occasionally get clunky, or you can use Unix permissions if you prefer). FTP only has user/password/account auth, and nobody uses the "account" part anyway. HTTP wins.
What are the advantages to FTP for downloads (especially anonymous, but also authenticated)? I honestly can't think of any ATM.
like science books that discuss new topics like evolution and the fact that disease is not caused by evil spirits (Offer void in KS).
Yeah, yeah, I know this was just a joke, but it sort of pisses me off whenever I hear this particular cheap shot. Because it seems some people actually believed the FUD spread around a couple years ago by panic-stricken... well, I'm not sure whom. Someone who felt threatened, I guess. For the record (*sigh*, one more time), the Kansas Board of Education did not
forbid teachers to teach the theory of evolution by natural selection (TE/NS)
forbid students to learn the TE/NS
forbid textbook writers to write about the TE/NS
forbid schools to buy textbooks that include material on TE/NS or even
forbid local school boards from mandating the teaching of the TE/NS
All they did was remove the subject from the list of mandatory topics to be covered in a high school science curriculum. Local school boards were free to re-mandate it if desired. Individual schools, or teachers, could likewise teach what they wanted - so long as they include all the state-mandated topics. (Which did not and do not include any "anti-evolution" topics.)
In other words, they referred the question down to the local level. That's all.
I'm not sure why people felt so threatened as to spread FUD about this. It seems that some people feel vehemently that some great calamity befalls children who are told that evolution by natural selection is anything other than a proven fact... as opposed to a theory with some major difficulties, accepted on faith by atheists mainly because no other current theory is compatible with strict atheism (where strict atheism != agnosticism).
One thing that they (GUI developers -- KDE, MS, Apple, etc) should implement RIGHT NOW is a feature I've seen on SGIs: A wheel widget that scales the contents of a file browser window.
Yeah! I think for SGI it was mostly to show off their vector-based icons, but this can be useful. Something like:
mouse wheel alone -> operate scrollbar
ctrl+wheel -> zoom window contents
alt+wheel -> resize window, keeping aspect ratio
ctrl+alt+wheel -> zoom and resize (so window keeps same amount of content)
...or something. Would this not rock?
Sure, it would require quite a bit of application support (or some rather expensive 2-D scale transforms in GDI/Gtk+/Qt/Xlib)... but hey, scalable fonts are old news so how hard can it be? (:
one could hope there will be an (identical) patch-2.5.1.gz file in the 2.5 directory...
See 2.5.1-pre1. The patch is not identical to the v2.4 version, but that shouldn't surprise anyone who follows kernel development - sometimes the "conceptually correct" fix to a problem is not the same as the "most obvious and bug-free" fix.
I've had 2.4.14 running for about month. Stable as hell, and that new VM code works an absolute treat keeping my baby zipping along. Give it a whirl. It doesn't work with VMWare yet
You mean VMWare doesn't work with 2.4.14 yet. Not the other way around. Since VMWare is closed-source (yes there is an open-source shim layer but it is just a shim layer) it is their responsibility to make it work with Linux.
If a regular application breaks with a new kernel release, it is the responsibility of the kernel maintainers. (Oh, except that Java thing from 2.2.18 or so - the JRE was relying on undocumented behavior so too bad.) But VMWare is not a regular application, it is more of a kernel mod.
Perhaps it's somewhat odd, but is this a sign that even kernels with an even minor version and an odd release number should be considered a bit odd, and the odd concept of using even and odd numbers to mark stable/unstable should be extended also to release numbers?
(:
That doesn't explain 2.4.9 versus 2.4.10. I had such a bad experience with 2.4.10 that it scared me away from using the new VM until 2.4.15 (luckily I didn't upgrade to that either yet, but I will try 2.4.16 probably today).
Win32 has the System32 (or System) directory, *nix has/usr/bin,/usr/share/bin,/usr/local/bin etc...
Two major problems Windows has because of this (well, major IMO): one, it doesn't have an analogue for LD_LIBRARY_PATH - loading a DLL searches the same path locations as loading an EXE. Therefore %SYSTEMROOT%\System32 is bloated with DLLs and other hangers-on rather than just EXEs.
(Thus, I would argue that the/usr/bin layout is in fact superior to the System32 layout, because we also have/usr/lib and/usr/share to syphon off some of the clutter.)
Second, Microsoft seems to espouse the position that "non-8.3 filenames are not reliable enough to depend on for system DLLs" - thus, the namespace is really cramped and it's hard to version the shared libraries... leading to DLL Hell. FWIW, the "Long Filenames Considered Flaky" assumption is IMO correct, at least on FAT partitions. And I guess they still have to support installing to FAT..
Sometimes I feel sorry for MS OS developers. I really do. The mess is of their own making, but it still can't be much fun to deal with.
With both rpm and apt, if you compile a library from source, the package manager won't consider said library to be installed.
True. The usual workaround (or "fix" if you want to term it such) is to apply the Debian diff to your source tree (which if it's a different version may or may not apply cleanly, but often works fine), then use 'dpkg-buildpackage' to make a binary.deb from it, then install that.
Can't customise the build? This depends on the packaging job, but often you can run the './configure' step or whatever, then have dpkg-buildpackage take over from there, using the '-nc' ("do not clean") option. YMMV. There are other ways to trick 'dpkg-buildpackage' too, again depending on how the package was packaged.
Note that you also have to make sure 'apt' doesn't try to overwrite your custom-compiled package with an "upgrade" - normally done by marking the package "on hold".
but as one user pointed out maybe we need a smarter shell to deal with recursive PATHs.
[[ First of all, note that it's not just the shell - the C library also makes use of $PATH in its execlp() and execvp() functions, so that would have to be updated as well. Not a problem, if you have the ear of a glibc developer or are willing to subject yourself to LD_PRELOAD hacks.... ]]
It might be instructive to note that XEmacs dealt with precisely this issue. The original GNU Emacs has lots of bundled LISP packages, and they used to come in one colossal directory. The XEmacs people started splitting things into their own dirs, but Emacs has a variable 'load-path' that works like $PATH for elisp files. Eventually they came up with a function that scanned the lisp dirs and made a list of subdirs - then used that function to build 'load-path' at runtime, when you start XEmacs.
Kind of clunky, but the same could be done with/etc/PATH or whatever the script might be called for your shell and your OS.
The system does not go through all of the directories in the path every time you type a command. No shell that I know of is stupid enough to do that.
True, but it doesn't help in the situation where you have a short shell script running - the shell that runs the script has to hash all those directories.
It just adds to overhead of running a shell script, and that is something I am opposed to on principle. (It's also why I use ash for/bin/sh rather than bash.)
Now, I believe the truly intelligent shells do not pre-emptively cache your whole path, they just add entries to the cache as needed. Either way, though, having a long path is harmful to performance - and a short-running shell (running a short script, say) is penalised more than a long-running shell due to less use of cache.
As an aside, I believe the only things that belong in bin dirs are binaries a user or administrator might ever actually want to run. In this regard, I think Debian packages sometimes go overboard - daemons, in my opinion, should go in/usr/lib/{subdir} or something rather than/usr/sbin, since you should really be invoking them via/etc/init.d/* scripts.
OK, so I use a text console most of the time, easier on the eyes, etc, but when I do use a GUI (one does what one must, when supporting CAD users) I sometimes wish I could zoom windows in or out. You know, use shift-scrollwheel or something to zoom the active window out so it takes up less space, the fonts are smaller, etc, but you can still see it. (Perhaps two modes, one which resizes only the borders as is already possible, the other also zooms the window contents....) This wouldn't replace the 'normal size', 'maximise', and 'minimise' commands, of course - in fact, 'normal size' would be even more useful than it is at present, as it would snap back to normal zoom factor.
Shouldn't be all that hard - scalable fonts were probably the trickiest bit and they've been around a long time now. An application would have the option of scaling or not scaling other elements of a window.
SGI almost did this - many of their IRIX desktop apps let you zoom stuff in and out by dragging a graphical "volume control" thing on the left side of the window. I believe this was primarily their way of showing off their vector-based icons. But this didn't resize the window itself, only its contents. And those were the days before mouse wheels.
Slashdot Mirror
Since when? Do you have an RFC cite for this? DNS is quite unopinionated on the subject - host names and domain names are treated the same.
I remember back in '93 hmc.edu used this technique, but not for a web site. It had an MX record, but some broken mail clients of the day did not consult MX records, so it also had an A record for the appropriate IP address.
I believe this was a widespread technique to work around these broken mail clients long before the web became popular, although I don't have any evidence to back this up.
Yeah, that's what I was thinking. The device would not allow whatever blood chemicals it consumed (probably the glucose) to fall below a specific level.
Sure. (:
Of course, there is the nontrivial barrier of inventing an artificial form of cellular respiration (or other means of extracting energy from glucose) that will fit in whatever physical constraints this device needs to have.
Here's one I didn't notice in the article. How about sucking chemical energy from blood chemicals? Basically we're talking about a dialysis-like blood filter that pulls out stuff like glucose and fatty acids and does its own cellular respiration.
Good for controlling your weight ... diabetes ... arteriosclerosis ... but bad for maintaining high energy and preventing chronic fatigue ... hmmm, maybe it isn't such a good idea. (:
134.173.*.*, yeah baby. I remember sittin' at Mudd back in '93 sort of feelin' sorry for all those latecomer colleges that had to make do with multiple class C's. (:
It's called motion capture, and animation houses definitely use it. Not to the extent that you're talking about (where every significant movement is captured) but it's used for things like gestures.
I agree with you that mocap is only going to increase in animation production.
Not only that, but NetBIOS names are not even analogous to DNS names. A DNS name is presumed to be for a single server (in practice, of course, it is often round-robin, but that's the theory anyway) whereas a NetBIOS name is per-service on a given server.
Sure, on an average Win95 box or NT workstation you don't see much difference, but do a NetBIOS name status query ('nbtstat -a' on Windows, 'nmblookup -S' on Unix with Samba) on a domain controller, Exchange server and/or IIS server some time. All three add funky names to the namespace advertising their services.
Which isn't to say DNS-lookup-via-NetBIOS-names doesn't work (it does) but it's conceptually wrong.
No doubt you are right, but by WINS lookup I meant NetBIOS name lookup (you know, the "other" Microsoft definition of WINS), not necessarily via a WINS server. NetBIOS names are more or less plug-n-play on a simple network topology.
<lie>I hate to be pedantic</lie>, but NetBIOS is SMB file sharing (and printing, and MSRPC). The M$ hack you are thinking of is NBT, or NetBIOS-over-TCP/IP. NBT includes NBNS, the NetBIOS name service, which Microsoft calls WINS. The other confusing bit is that Microsoft sometimes uses "WINS" to refer to "NBT name resolution by any mechanism", and sometimes to mean "NBT name resolution by consulting an NBNS server".
And ... while ordinarily WINS has nothing to do with email delivery, in Microsoft land this is not always true - the TCP/IP stack will use NetBIOS to look up what should be DNS names - sometimes, at least - before falling back to DNS. I'm not sure whether to consider this a bug or a feature, because it would help in a case where you run an internal web server ("intranet" in LRMT, the Lexicon of Redundant and Misleading Terms) but are too clueless to run your own DNS.
(Whether such people should be encouraged to manage a web server at all is an open question.)
Allegedly. I guess some bonehead at Microsoft accidentally shipped a service pack without stripping the symbols (meaning: all the names of global variables and functions that aren't usually exported were visible). And someone was looking through the symbols and found a variable in the crypto module called NSAKEY, whose value turned out to be a valid key (distinct from the usual Microsoft key) for things like code signing for upgrades. The immediate peanut gallery theory emerged that this key was held in escrow by the NSA in case they ever needed to send anyone a spyware trojan.
Microsoft came up with an alternate explanation, of course, which I don't remember off hand, but it sounded at least semi-plausible. I imagine we'll never know.
Really? I've never heard that. I've always thought HTTP did everything in-band.
Point taken. I guess the difficulty is that nobody has thought to build an interactive HTTP client that assumes "nothing on the page is really useful HTML, just snarf the links and assume they are files in a directory". Not insurmountable, by any means.
Speaking of "useful HTML", note that HTTP has one feature over FTP that I forgot about until now. Content-type! The server can be configured to know what its own content types are. With FTP, the client has to guess if the files are binary or ascii, which blows chunks, and doesn't allow for finer-grained content types - you end up relying on "well-known" filename extensions, which is confining.
What? You've never tried to go to a page and been presented with a pop-up box asking you for user and password for such-and-such an authentication domain?
HTTP defines the "Auth-Type" header, with the two commonly supported methods "Basic" and "Digest" (the latter does not send cleartext passwords). The web server can trigger an auth request for any page it wants to, and popular web servers have ways to tie this in to your system user list, a custom list, a user database query, etc.
Of course you also have cookie-based authentication, which you just now used to post to Slashdot. And URL-based "poor man's cookies".
Several command-line http clients implement "reget" functionality using the "Range" or "Byte-Range" (whatever it's called) HTTP header, which I think (but am not sure) even /1.0 supports.
Again, command-line clients like GNU wget usually support "suck mode" where they recursively follow links from pages downloaded as long as the links stay within a base URL. You can easily pull down a whole web site that way if you wish, assuming none of it is server-parsed. No reason a more interactive client couldn't do the same.
Hmmm, there's one I truly hadn't thought of. Again, the HTTP protocol support is there, using the "Auth-Type" header.
There's the problem, and there is where you've convinced me that FTP is not dead yet. Nobody has written a proper interactive HTTP download client that doesn't look and act like a web browser.
For uploads, FTP is still probably better, if only because nobody seems to use the HTTP PUT command.
For downloads, though ...
What are the advantages to FTP for downloads (especially anonymous, but also authenticated)? I honestly can't think of any ATM.
Excuse me, I think my screen must have gone blurry or something. Did you just say "DivX AVI's" and "perfect digital quality" in the same context?
Look up the term "lossy compression" some time. (:
Score: -1, Offtopic
Yeah, yeah, I know this was just a joke, but it sort of pisses me off whenever I hear this particular cheap shot. Because it seems some people actually believed the FUD spread around a couple years ago by panic-stricken ... well, I'm not sure whom. Someone who felt threatened, I guess. For the record (*sigh*, one more time), the Kansas Board of Education did not
or even
All they did was remove the subject from the list of mandatory topics to be covered in a high school science curriculum. Local school boards were free to re-mandate it if desired. Individual schools, or teachers, could likewise teach what they wanted - so long as they include all the state-mandated topics. (Which did not and do not include any "anti-evolution" topics.)
In other words, they referred the question down to the local level. That's all.
I'm not sure why people felt so threatened as to spread FUD about this. It seems that some people feel vehemently that some great calamity befalls children who are told that evolution by natural selection is anything other than a proven fact ... as opposed to a theory with some major difficulties, accepted on faith by atheists mainly because no other current theory is compatible with strict atheism (where strict atheism != agnosticism).
Yeah! I think for SGI it was mostly to show off their vector-based icons, but this can be useful. Something like:
...or something. Would this not rock?
Sure, it would require quite a bit of application support (or some rather expensive 2-D scale transforms in GDI/Gtk+/Qt/Xlib)... but hey, scalable fonts are old news so how hard can it be? (:
See 2.5.1-pre1. The patch is not identical to the v2.4 version, but that shouldn't surprise anyone who follows kernel development - sometimes the "conceptually correct" fix to a problem is not the same as the "most obvious and bug-free" fix.
Pedantically speaking, the patch is 17330 bytes long. It compresses to under 6KB.
Actually that would be 1.0.9, at 2678 uncompressed bytes.
(Not counting pre-1.0 releases, or -pre* releases, or 2.3.0 or 2.5.0 which are just version number changes.)
You mean VMWare doesn't work with 2.4.14 yet. Not the other way around. Since VMWare is closed-source (yes there is an open-source shim layer but it is just a shim layer) it is their responsibility to make it work with Linux.
If a regular application breaks with a new kernel release, it is the responsibility of the kernel maintainers. (Oh, except that Java thing from 2.2.18 or so - the JRE was relying on undocumented behavior so too bad.) But VMWare is not a regular application, it is more of a kernel mod.
(:
That doesn't explain 2.4.9 versus 2.4.10. I had such a bad experience with 2.4.10 that it scared me away from using the new VM until 2.4.15 (luckily I didn't upgrade to that either yet, but I will try 2.4.16 probably today).
Which patch? The iput bug (aka "fs corruption on unmount") is fixed in both branches.
Actually 2.0.39. 2.2.39 won't happen for a long time, methinks.
Two major problems Windows has because of this (well, major IMO): one, it doesn't have an analogue for LD_LIBRARY_PATH - loading a DLL searches the same path locations as loading an EXE. Therefore %SYSTEMROOT%\System32 is bloated with DLLs and other hangers-on rather than just EXEs.
(Thus, I would argue that the /usr/bin layout is in fact superior to the System32 layout, because we also have /usr/lib and /usr/share to syphon off some of the clutter.)
Second, Microsoft seems to espouse the position that "non-8.3 filenames are not reliable enough to depend on for system DLLs" - thus, the namespace is really cramped and it's hard to version the shared libraries ... leading to DLL Hell. FWIW, the "Long Filenames Considered Flaky" assumption is IMO correct, at least on FAT partitions. And I guess they still have to support installing to FAT..
Sometimes I feel sorry for MS OS developers. I really do. The mess is of their own making, but it still can't be much fun to deal with.
True. The usual workaround (or "fix" if you want to term it such) is to apply the Debian diff to your source tree (which if it's a different version may or may not apply cleanly, but often works fine), then use 'dpkg-buildpackage' to make a binary .deb from it, then install that.
Can't customise the build? This depends on the packaging job, but often you can run the './configure' step or whatever, then have dpkg-buildpackage take over from there, using the '-nc' ("do not clean") option. YMMV. There are other ways to trick 'dpkg-buildpackage' too, again depending on how the package was packaged.
Note that you also have to make sure 'apt' doesn't try to overwrite your custom-compiled package with an "upgrade" - normally done by marking the package "on hold".
[[ First of all, note that it's not just the shell - the C library also makes use of $PATH in its execlp() and execvp() functions, so that would have to be updated as well. Not a problem, if you have the ear of a glibc developer or are willing to subject yourself to LD_PRELOAD hacks.... ]]
It might be instructive to note that XEmacs dealt with precisely this issue. The original GNU Emacs has lots of bundled LISP packages, and they used to come in one colossal directory. The XEmacs people started splitting things into their own dirs, but Emacs has a variable 'load-path' that works like $PATH for elisp files. Eventually they came up with a function that scanned the lisp dirs and made a list of subdirs - then used that function to build 'load-path' at runtime, when you start XEmacs.
Kind of clunky, but the same could be done with /etc/PATH or whatever the script might be called for your shell and your OS.
Just a thought....
True, but it doesn't help in the situation where you have a short shell script running - the shell that runs the script has to hash all those directories.
It just adds to overhead of running a shell script, and that is something I am opposed to on principle. (It's also why I use ash for /bin/sh rather than bash.)
Now, I believe the truly intelligent shells do not pre-emptively cache your whole path, they just add entries to the cache as needed. Either way, though, having a long path is harmful to performance - and a short-running shell (running a short script, say) is penalised more than a long-running shell due to less use of cache.
As an aside, I believe the only things that belong in bin dirs are binaries a user or administrator might ever actually want to run. In this regard, I think Debian packages sometimes go overboard - daemons, in my opinion, should go in /usr/lib/{subdir} or something rather than /usr/sbin, since you should really be invoking them via /etc/init.d/* scripts.
The XBox! Microsoft is going to put 650,000 XBoxes into classrooms. You know, for all those educational games that run on it.
(:
OK, so I use a text console most of the time, easier on the eyes, etc, but when I do use a GUI (one does what one must, when supporting CAD users) I sometimes wish I could zoom windows in or out. You know, use shift-scrollwheel or something to zoom the active window out so it takes up less space, the fonts are smaller, etc, but you can still see it. (Perhaps two modes, one which resizes only the borders as is already possible, the other also zooms the window contents....) This wouldn't replace the 'normal size', 'maximise', and 'minimise' commands, of course - in fact, 'normal size' would be even more useful than it is at present, as it would snap back to normal zoom factor.
Shouldn't be all that hard - scalable fonts were probably the trickiest bit and they've been around a long time now. An application would have the option of scaling or not scaling other elements of a window.
SGI almost did this - many of their IRIX desktop apps let you zoom stuff in and out by dragging a graphical "volume control" thing on the left side of the window. I believe this was primarily their way of showing off their vector-based icons. But this didn't resize the window itself, only its contents. And those were the days before mouse wheels.