There's an Elvengear/dev/girl T-shirt I'd been thinking of giving a girlfriend (who hated being objectified and wasn't a big Linux fan) - but NOW, the perfect excuse! Literally true!... assuming you can run LInux on her.:-)
Well... optically would probably could make it focussing at a far distance while looking at a converging at a nearer distance (flipped from above), but the point is that no accomodation (focus change) is required for for 3D screens, and that could impact kids' brains learning how to integrate focus into the set of cues used for depth perception.
Othewise said, Anses is an idiot in this area and has no idea what the real issue is, though there might be one: "three-dimensional effect requires the eyes to look at images in two different places at the same time before the brain translates it as one image" is flawed in almost every respect except for "three-dimensional" and "eyes". He shouldn't be involved in policy in this area.
The key point is whether the end user can install a signature for his *own* operating system in his own hardware, and then secure boot linux. Nothing in the document suggests this is possible (and MS slams linux as an older operating system for "enthusiasts", but that isn't really the point)
Newflash^2: Lag is explicitly network lag for any online game unless otherwise specified, since online lag completely overshadows almost all other types of local-to-host delays. If you're talking about a solo, unnetworked game, sure, "lag" might mean something else.
Now, of course, if you're talking to complete duffers, who will complain that their computer's slow when a remote webserver is slow to respond, and that the Internet is slow while their disk drive I/O light is solid on, and in almost all other ways have no idea what causes delays, then sure, "lag" could mean anything.
I've been on the Internet a long time, so I remember sri-nic.arpa, nic.ddn.mil, rs.internic.net, and even downloading the Internet host address file, with about 8000+ IPs in it. The early organization was very clear about preserving the namespace of domain names for future generations, with base policies (I believe these are all correct, but it might just be 3 out of 4) of:
* The domain name must relate to the purpose of your organization.
*.net is reserved for network infrastructure,.org for only non-profits,.com for commercial (.mil and.edu are still fairly pristine), etc.
* You must establish two nameservers, that must not be on the same subnet, and must already be providing DNS for the requested domain.
* Each requester gets a single domain, the idea being that the requester's entire organization would then be fully served.
Although they weren't really thinking about the upcoming explosion in web use, their thinking certainly allowed for an explosion in *sub* domain names. So instead of lots of ridiculous domains like www.iatemygrandmamovie.com, we might have later seen something like iatemygrandma.movie.com, with some group running a movie.com site, and an easy way to find a bunch of them, instead of the crapshoot we have now.
So where did the corruption set in? Once the idea of charging for a domain name popped up, some bright boy got a gleam in his eye when a company - I think it might have been Proctor and Gamble - violated registration policy by requesting scores of domain names based on ailments (and possibly some body parts). There was a similar polydomain request by some other group around the same time. Both generated a flurry of controversy. And our illustrious registrar suddenly demonstrated its modern, capitalist colors, dumping the past, conservative policies and making its new mission one of simply selling off every possible domain name, in every possible TLD, as fast as possible.
Effectively, they sold out on future generations' needs in an exercise of total, corrupt greed. The registrar flipped on every policy, encouraging multiple registration of domains, flagrantly pushing registration in every possible TLD, dropping the domain server requirement, dropping the relevancy concept, and now even pushing for more TLDs, in order to sell even more completely unnecessary extra domains.
The idea of allowing some company to register thousands of obviously unrelated domains for cybersquatting would have been anathema in the pre-profit days, but Network Solutions just doesn't care. And that ridiculous article completely misses *all* of this.
I'm glad he's going to be okay! And this is so much better than putting him in a completely isolated box and thinking, with uncertainty, "well, he's probably...".
The issue's been beaten into the ground, of course, but a layer of separation between the physical host and the use(s) to which it is put is advisable.
Base hostnames:
Making the base names use themed names, like type of fruit, extension of the seven dwarves, etc. is fine as long as you're in one site. Once a company covers multiple sites, embedding those sites in the name is often helpful, although best for hosts that will *never* be moved, and good luck if you're bought out and the whole server farm moved.
Pick those themes carefully, though. Few will realize "apache", "osprey", and "fokker" are all types of aircraft, since the aircraft themselves were often named after unrelated *other* themes.
Tying such names to the underlying network infrastructure is a poor idea for gear other than routers, switches, etc. It would be a shame to have to do a grand renaming of a bunch of servers just because the network topology was tweaked.
Virtual Hosts:
Base-naming virtual machine instances inside the namespace of the containing host (or cluster within which they migrate) isn't a terrible choice - unless you expect to convert "real" hosts back and forth between that and being virtual hosts. If so, go by the prior section.
Functional Names:
CNAMEs are your friend, and this is the primary use for them, to make aliases, often several of them, to map services to the hosts (or VMs) that are providing the services.
Burying Arbitrary Info in a Hostname:
DNS has TXT records for completely arbitrary information - whenever possible, I'd recommend using those instead of complicating the hostname itself. However, it's still a crying shame that BIND doesn't allow host RR types to be filtered based on the querent, a key reason many sites are reluctant to use TXT RRs to their fullest.
In order for a text color scheme to work well for folks using glasses, especially higher diopter corrections, there are some things to know about how color behaves when viewed through glasses in any way but straight on. To test these, note in particular the effects seen near the edge of the lens, and when moving the head. Wearers of contacts may not see these effects. All notes regarding red-and-blue text also apply to red-vs-green to a lesser extent.
- Violet colors are split into red and blue layers. - Red and blue text appear to move at different angular speeds as the head turns. - Violet text loses its violetness when shown over blue or red backgrounds (true to some extent even for those with perfect vision) - Red and blue text in a line are easily perceived as not sharing the same vertical alignment.
For any color scheme, trying to avoid impact by the most common varieties of color blindness is recommended, by complementing the color coding with some other visible cue such as font weight, italics, underlining, etc.
Actually we have blatantly added the dimension of color to previous computer interfaces where once monochrome the rule. Color is -definitely- a dimension.
The article asserts "Your eye has a lot of depth of field. Everything you see is sharp and in focus. the laws of physics make it impossible for a camera to do this".
Well, actually most of what one sees is out of focus, since the eyes constantly adjust to favor a specific depth of field at any one time, leaving everything else fuzzy. If you compare this to an autofocussing camera, they are actually quite similar, and well within the "laws of physics". The future's flexible lenses will bring cameras even closer to the model used by the eyes.
Parallel boot issues, infeasibility of make, ~1998
on
Booting Linux Faster
·
· Score: 1
A new init and accompanying rc script system, whould be better parallelizing boot system for Unix than a system based on make and the current scripts.
As has been pointed out already, make can only elegantly handle the following issues:
Dependency-based ordering of service startup.
Unlimited, named abstract boot targets.
Allow the use of abstract names in building dependency trees.
Now, even providing just these two abilities would be nice, to be sure. Dependencies allow parallelization of boot, and thus the obvious speed benefit on system startup - yet beware, because make does not handle all issues here. Just as make -j can break updates of shared targets (like libraries), using it for system startup can scramble your boot logs. But make is a notional source for simply-named abstract targets like "make clean", except that here we want to be replace phrases like "boot everything up to Samba", or "prep the system for remote ssh for users with NFS-based home directories", or "shutdown Oracle and everthing that needs it", with commands like "initlevel -target samba", "initlevel -target ssh-logins", and "initlevel -stop-propagate oracle" (the last of which might leave us in an init level without a defined name, but that's alright). Make can't easily do the last one.
But there are other key scenarios that a make-based system fails to address, that a rewrite of init and its accompanying scripts could:
Shutdown all services not needed by a given target.
Reboot a given service, and all services which depend on it and require the reboot to be valid..
Determine if service X can be shutdown without affecting service Y.
Track and report the status of running services.
React to the abrupt crash of a service.
Based on the last point in particular, that of tracking the status of running services, I had abandoned the idea of solving the problem through simple scripting in '99, but these needs could all be addressed by rewriting init itself from scratch with new requirements in mind, and without the antiquated, numbered runlevels. Certainly most of the system would still be script-based, but init, in its role as the grand reaper, the dark ring to which all dying processes are bound, is the tool for watching the services on an ongoing basis,
and killing or spawning services as needed to keep the current init target valid.
For all of its flaws however,/etc/rc and/etc/init.d provided concepts sadly lacking back in the time where/etc/rc and/etc/rc.local were king - namely, the concept of standardized methods for each service script. Having "start", "stop", and so on available has not only made the current system useful for perhaps longer than it should have been, but provided a basis for conveniences like chkconfig(8) and service(8). Heh, if only "start" started all its needed parent services in parallel first, right - you could just have "service xlogin start" start everything it needed recursively, oh, wait, don't try it, you'll get 100 init processes or something if you're not careful, don't run that...*akk*
Be aware that there are some library checks left out of the configure.ac that will prevent./configure from finding all the library dependencies. To fix this, add the following lines in configure.ac in the library check section, to wit:
The LSB does not beat POSIX on all counts, however. Take this section, in particular:
458 3.3.1 Pathname of $0
459 When the shell searches for a command name in the PATH and finds a shell
460 script, ISO/IEC 9945 specifies that it shall pass the command name as
461 argv[0] and in the child shell script, $0 shall be set from argv[0].
462 (Note there is a defect report pending on this issue)
463 However, for an LSB shell, the system may implement either this behavior
464 or $0 may be set to an absolute pathname of the shell script.
Consider that only passing the actual
command used as $0 (POSIX) allows the user's
relative command to be seen literally.
If the objective is to find the full pathname of
the script, this behavior is annoying, since
the PATH must be perused iteratively.
However, at least $0 has been be initialized from
given, finite data.
In constrast, if an implementation follows the
LSB's "may be set to an absolute pathname",
what happens when the PATH contained "."
(don't whine, now, it's still perfectly valid
despite security concerns),
and the current directory is a couple of
thousand levels deep in subdirectories?
Now a time consuming search for the root has
to proceed, particularly since most shells can't
maintain a PWD variable under these conditions.
A buffer for the result can't be preallocated,
since it will probably be longer than then
commonly used PATHLEN or whatever it was
(usually about 1024 bytes, I think about 4K in
Linux, POSIX might have been shorter), so we're
looking at a likely recursive function with the
associated impact on the stack (although said
impact is a relatively minor problem nowadays).
If all of these factors aren't handled, than
the theoretically simple act of digging up a
$0 could crash the script before it executes
a single line. If this seems unlikely, note
that this same kind of blindness used to crash
some versions of Unix (specifically IRIX), due
to symlink-handling code in the kernel and a
buffer problem - which they wouldn't fix until
it was pointed out that creating a USENET
newsgroup of sufficiently long name would crash
every SGI newsserver on USENET, which would then
crash again during the boot fsck's.
But suppose all that's addressed, and
our LSB-option using script mechanism handles
the buffer overrun issues and we accept the
performance penalty. Only the raw technical
issues have been addressed so far.
Naturally, in searching for the "absolute path",
we have to ask which one: the logical path via
whatever symlinks might have occured, or the
physical path - a classic problem of subjective
opinion. Well, if no PWD was maintained,
the first may be pretty much unobtainable, but
either way, we still have to wonder if
someone will complain of the shell's current
logical/physical setting for "cd.." should be
adhered to. Hardly a recipe for consistancy
from the script's perspective, since it wouldn't
have yet had an opportunity to set its own preference first.
So, how could this absolute pathname "option"
for $0 possibly be
considered an improvement over the
POSIX default?
Makes me wonder if the lack of this questionable
feature was what was posted as a "defect report"
against the POSIX guide.
Hehe.
All of this just goes to show that standards
writing is a trick business. It's hard to
get this kind of thing right in -all- cases.
We used SCO's Unix in 1990 or so to teach Unix students for a while, but after noticing that we'd had to plug in GNU software for almost everything to make it work, we finally switched to SunOS, and later to Linux. But that's not the interesting part. What is, is that Iremember the SCO's original Unix booting with the horrifying sight of Microsoft's copyrights on the Unix flavor underneath.
You might say, "What? Microsoft did Unix in the 80s? No! That's insane!".
Apparently Microsoft had been working on Unix in some respect for a while, until Bill had decided it had no future (or perhaps, just not a proprietary enough one), and (or so I infer) sold it or licensed it to the Santa Cruz Operation.
This would make for much irony if SCO won their little suit, but then Microsoft bought them to try to reassert control over what Bill once thought was irrelevant, and now clearly -is- the future.
The comments in the suit about IBMs AIX and its claimed collision with the Unix patents is pretty funny, since apparently one of the miseries of doing AIX design was going before a little review board that would judge the odds of your perfectly good code intersecting known non-IBM patents, and then making you break it until it didn't - or so goes one unfortunate's tale.
All of this is, of course, hearsay, so if you were there, just tell us what really happened, yes?:-)
any Star Wars (although JarJar on IMAX is, ummm...)
any Lord of the Rings
Men in Black - especially the end sequence
Crouching Tiger, Hidden Dragon
Perfect Storm - you thought those waves were big on a normal screen, eh...
And just about any movie with serious panaromas, including lots of art films, some of the shorts out of the animation festivals, films with large battles scenes or including view from aircraft or space, and so on.
Having an IMAX screen for a computer monitor - now that's even better than the IBM T221, neh? The perfect display system for the as-yet-unfinished bedroom Beowulf cluster:-)
You can look at the
online version of the patent on the
US Patent Office's website. Note that the patent process for this one was started 16 years ago in 1986 (stuff 4698672 into the Patent Number Search box on
the search page to see this), which would certainly limit how much longer it could be pursued.
To me, the patent seems to largely be focussed around runlength encoding in digital video - not that this always has any real bearing on how a specific patent can suddenly become profitable.
That patent itself states:
The present invention relates to methods and apparatus for processing signals to remove redundant information thereby making the signals more suitable for transfer through a limited-bandwidth medium. The present invention specifically relates to methods and apparatus useful in video compression systems.
[...]
The patent describes a single-pass digital video compression system which implements a two-dimensional cosine transform with intraframe block-to-block comparisons of transform coefficients without need for preliminary statistical matching or preprocessing.
It'll be interesting, and rather sad, to see if this actually get applied against JPEGs....
First, mapping is only one possible application, But even within that constraint, the 2D map approach doesn't work well for everyone (yes, some folks still have trouble reading maps), especially considering that a map has to be oriented to match the surroundings (north on the map to north in reality) by the user either in the head or by the physical rotation of the phone. Given the trouble some folks have with this, wouldn't a 1st-person view with fat 3D arrows be more useful as a guide system for those people? I suppose I should distinguish this from mapping, since it isn't exactly the same idea.
Until your eyes have a HUD, a cellphone might be a perfect way to get a 3D view of what you can see PLUS annotations about what's nearby, an arrow for where to turn next (from your own perspective, which can be faster to grok at times than the overhead view), topographic contour overlay, star finder, etc. As long as the phone can sense its orientation as well as position, it could double as an cheap HUD. Saying your eyes can do this on their own disregards the advantage of the computer interlink the cellphone has.
On your comment about wanting four extra keys - I have a
Kinesis ergonomic keyboard at home, and the layout gives you about 19 extra keys to use - eight in an extra row below the convention bottom row, and a full, useful keypad for each thumb with six each.
This keyboard is sweet-looking, comfortable, and great for any game with key remapping and heavy mouse use, since you can actually get more commands under one hand than you can on a standard keyboard.
You could probably find most of the same features in another keyboard called the
Maltron, but I wasn't exactly inspired by either its industrial british look, or the $350 price - I can get another Kinesis for about $180.
It definitely has a
nice look deployed in a geek environment.
My roommate has had one for years as well, and he's also quite pleased with it.
The 2 CPU for $249 is for a server, while the 4 CPU at $199 is for just a desktop. Nice desktop, methinks.
Now the question is whether Sun still doing the old 2-user Right-To-Use license from the old days or not, although, unlike some vendors, I don't recall them ever having enforced it at the software level.
[I bought mine through Office Organix or direct, see http://www.officeorganix.com/kenisis1.htm for the former]
The Kinesis keyboards feel almost perfect, much nicer than the halfway-measures of the MS Natural line in terms of key action in particular (a subjective issue, of course), and have the advantage of being beautifully shaped on the underside for lap use as well.
Furthermore, they suit gaming quite well, with the extra row of keys under 'zxcvb' and "nm,./" and plethora of thumb keys making it far easier to keep one's hand in place during intense gaming while the other hand manipulates the mouse.
The MS Natural (or MS melted) fails to even out the keys between hands, leaving the weird excess punctuation to the right hand in the manner of conventional keyboards, so gaming on them is a bit rougher for people who use the mouse right-handed.
The Kinesis also has the advantages of discarding the useless far-left to front-right keyslant, a legacy of mechanical typewriters, and has a marvelous concavity to each hand's keyset, better following arc through which fingers tend to move. The thumb keypads are particularly nice, although it takes a new user a little while (a few hours, typically) to get used to having space, backspace, return, delete, control, alt, page up/down etc., all perfect for thumb access. The shift and caps lock are in the normal places, however, so don't panic:-)
Basically, it's a great keyboard, does wonders for reducing RSI, great for any game that lets you remap the keys, and I and my roommate both have them. It also has a provision for attaching a pedal that can be mapped to almost anything but most typically either shift or the numeric-keypad lock (for the embedded keypad in the right-hand keys) The only critical statement I have to make is that escape and the function keys are smaller chiclet keys rather than full keys (see the Maltron for a near equivalent with full function keys), but since Unix doesn't use F1 and so forth much, it's hardly ever been significant.
Slashdot Mirror
There's an Elvengear /dev/girl T-shirt I'd been thinking of giving a girlfriend (who hated being objectified and wasn't a big Linux fan) - but NOW, the perfect excuse! Literally true! ... assuming you can run LInux on her. :-)
"Welcometo the future. A pity you are too late to stop it. No one can stop me now!"
Well... optically would probably could make it focussing at a far distance while looking at a converging at a nearer distance (flipped from above), but the point is that no accomodation (focus change) is required for for 3D screens, and that could impact kids' brains learning how to integrate focus into the set of cues used for depth perception.
Othewise said, Anses is an idiot in this area and has no idea what the real issue is, though there might be one: "three-dimensional effect requires the eyes to look at images in two different places at the same time before the brain translates it as one image" is flawed in almost every respect except for "three-dimensional" and "eyes". He shouldn't be involved in policy in this area.
The key point is whether the end user can install a signature for his *own* operating system in his own hardware, and then secure boot linux. Nothing in the document suggests this is possible (and MS slams linux as an older operating system for "enthusiasts", but that isn't really the point)
Geez, use metric already:
labrat@yggdrasil:~$ units
2411 units, 71 prefixes, 33 nonlinear units
You have: 498438559990 kilograms
You want: petagrams
* 0.49843856
/ 2.0062653
1/2 petagram. Easy.
Newflash^2: Lag is explicitly network lag for any online game unless otherwise specified, since online lag completely overshadows almost all other types of local-to-host delays. If you're talking about a solo, unnetworked game, sure, "lag" might mean something else.
Now, of course, if you're talking to complete duffers, who will complain that their computer's slow when a remote webserver is slow to respond, and that the Internet is slow while their disk drive I/O light is solid on, and in almost all other ways have no idea what causes delays, then sure, "lag" could mean anything.
I've been on the Internet a long time, so I remember sri-nic.arpa, nic.ddn.mil, rs.internic.net, and even downloading the Internet host address file, with about 8000+ IPs in it. The early organization was very clear about preserving the namespace of domain names for future generations, with base policies (I believe these are all correct, but it might just be 3 out of 4) of:
* The domain name must relate to the purpose of your organization.
* .net is reserved for network infrastructure, .org for only non-profits, .com for commercial (.mil and .edu are still fairly pristine), etc.
* You must establish two nameservers, that must not be on the same subnet, and must already be providing DNS for the requested domain.
* Each requester gets a single domain, the idea being that the requester's entire organization would then be fully served.
Although they weren't really thinking about the upcoming explosion in web use, their thinking certainly allowed for an explosion in *sub* domain names. So instead of lots of ridiculous domains like www.iatemygrandmamovie.com, we might have later seen something like iatemygrandma.movie.com, with some group running a movie.com site, and an easy way to find a bunch of them, instead of the crapshoot we have now.
So where did the corruption set in? Once the idea of charging for a domain name popped up, some bright boy got a gleam in his eye when a company - I think it might have been Proctor and Gamble - violated registration policy by requesting scores of domain names based on ailments (and possibly some body parts). There was a similar polydomain request by some other group around the same time. Both generated a flurry of controversy. And our illustrious registrar suddenly demonstrated its modern, capitalist colors, dumping the past, conservative policies and making its new mission one of simply selling off every possible domain name, in every possible TLD, as fast as possible.
Effectively, they sold out on future generations' needs in an exercise of total, corrupt greed. The registrar flipped on every policy, encouraging multiple registration of domains, flagrantly pushing registration in every possible TLD, dropping the domain server requirement, dropping the relevancy concept, and now even pushing for more TLDs, in order to sell even more completely unnecessary extra domains.
The idea of allowing some company to register thousands of obviously unrelated domains for cybersquatting would have been anathema in the pre-profit days, but Network Solutions just doesn't care. And that ridiculous article completely misses *all* of this.
I'm glad he's going to be okay! And this is so much better than putting him in a completely isolated box and thinking, with uncertainty, "well, he's probably...".
The issue's been beaten into the ground, of course, but a layer of separation between the physical host and the use(s) to which it is put is advisable.
Base hostnames:
Making the base names use themed names, like type of fruit, extension of the seven dwarves, etc. is fine as long as you're in one site. Once a company covers multiple sites, embedding those sites in the name is often helpful, although best for hosts that will *never* be moved, and good luck if you're bought out and the whole server farm moved.
Pick those themes carefully, though. Few will realize "apache", "osprey", and "fokker" are all types of aircraft, since the aircraft themselves were often named after unrelated *other* themes.
Tying such names to the underlying network infrastructure is a poor idea for gear other than routers, switches, etc. It would be a shame to have to do a grand renaming of a bunch of servers just because the network topology was tweaked.
Virtual Hosts:
Base-naming virtual machine instances inside the namespace of the containing host (or cluster within which they migrate) isn't a terrible choice - unless you expect to convert "real" hosts back and forth between that and being virtual hosts. If so, go by the prior section.
Functional Names:
CNAMEs are your friend, and this is the primary use for them, to make aliases, often several of them, to map services to the hosts (or VMs) that are providing the services.
Burying Arbitrary Info in a Hostname:
DNS has TXT records for completely arbitrary information - whenever possible, I'd recommend using those instead of complicating the hostname itself. However, it's still a crying shame that BIND doesn't allow host RR types to be filtered based on the querent, a key reason many sites are reluctant to use TXT RRs to their fullest.
So there you go. Edit at will, and good luck :-)
In order for a text color scheme to work well for folks using glasses, especially higher diopter corrections, there are some things to know about how color behaves when viewed through glasses in any way but straight on. To test these, note in particular the effects seen near the edge of the lens, and when moving the head. Wearers of contacts may not see these effects. All notes regarding red-and-blue text also apply to red-vs-green to a lesser extent.
- Violet colors are split into red and blue layers.
- Red and blue text appear to move at different angular speeds as the head turns.
- Violet text loses its violetness when shown over blue or red backgrounds (true to some extent even for those with perfect vision)
- Red and blue text in a line are easily perceived as not sharing the same vertical alignment.
For any color scheme, trying to avoid impact by the most common varieties of color blindness is recommended, by complementing the color coding with some other visible cue such as font weight, italics, underlining, etc.
Actually we have blatantly added the dimension of color to previous computer interfaces where once monochrome the rule. Color is -definitely- a dimension.
The article asserts "Your eye has a lot of depth of field. Everything you see is sharp and in focus. the laws of physics make it impossible for a camera to do this".
Well, actually most of what one sees is out of focus, since the eyes constantly adjust to favor a specific depth of field at any one time, leaving everything else fuzzy. If you compare this to an autofocussing camera, they are actually quite similar, and well within the "laws of physics". The future's flexible lenses will bring cameras even closer to the model used by the eyes.
A new init and accompanying rc script system, whould be better parallelizing boot system for Unix than a system based on make and the current scripts. As has been pointed out already, make can only elegantly handle the following issues:
Now, even providing just these two abilities would be nice, to be sure. Dependencies allow parallelization of boot, and thus the obvious speed benefit on system startup - yet beware, because make does not handle all issues here. Just as make -j can break updates of shared targets (like libraries), using it for system startup can scramble your boot logs. But make is a notional source for simply-named abstract targets like "make clean", except that here we want to be replace phrases like "boot everything up to Samba", or "prep the system for remote ssh for users with NFS-based home directories", or "shutdown Oracle and everthing that needs it", with commands like "initlevel -target samba", "initlevel -target ssh-logins", and "initlevel -stop-propagate oracle" (the last of which might leave us in an init level without a defined name, but that's alright). Make can't easily do the last one.
But there are other key scenarios that a make-based system fails to address, that a rewrite of init and its accompanying scripts could:
Based on the last point in particular, that of tracking the status of running services, I had abandoned the idea of solving the problem through simple scripting in '99, but these needs could all be addressed by rewriting init itself from scratch with new requirements in mind, and without the antiquated, numbered runlevels. Certainly most of the system would still be script-based, but init, in its role as the grand reaper, the dark ring to which all dying processes are bound, is the tool for watching the services on an ongoing basis, and killing or spawning services as needed to keep the current init target valid.
For all of its flaws however, /etc/rc and /etc/init.d provided concepts sadly lacking back in the time where /etc/rc and /etc/rc.local were king - namely, the concept of standardized methods for each service script. Having "start", "stop", and so on available has not only made the current system useful for perhaps longer than it should have been, but provided a basis for conveniences like chkconfig(8) and service(8). Heh, if only "start" started all its needed parent services in parallel first, right - you could just have "service xlogin start" start everything it needed recursively, oh, wait, don't try it, you'll get 100 init processes or something if you're not careful, don't run that...*akk*
You can download the source code from http://gd.tuwien.ac.at/opsys/linux/sf/subcat/in/in nolab/3dfm-1.0.tar.gz
Be aware that there are some library checks left out of the configure.ac that will prevent ./configure from finding all the library dependencies. To fix this, add the following lines in configure.ac in the library check section, to wit:
Then run "autoconf" to update the ./configure, and proceed as usual.
The LSB does not beat POSIX on all counts, however. Take this section, in particular:
Consider that only passing the actual command used as $0 (POSIX) allows the user's relative command to be seen literally. If the objective is to find the full pathname of the script, this behavior is annoying, since the PATH must be perused iteratively. However, at least $0 has been be initialized from given, finite data. In constrast, if an implementation follows the LSB's "may be set to an absolute pathname", what happens when the PATH contained "." (don't whine, now, it's still perfectly valid despite security concerns), and the current directory is a couple of thousand levels deep in subdirectories? Now a time consuming search for the root has to proceed, particularly since most shells can't maintain a PWD variable under these conditions. A buffer for the result can't be preallocated, since it will probably be longer than then commonly used PATHLEN or whatever it was (usually about 1024 bytes, I think about 4K in Linux, POSIX might have been shorter), so we're looking at a likely recursive function with the associated impact on the stack (although said impact is a relatively minor problem nowadays).
If all of these factors aren't handled, than the theoretically simple act of digging up a $0 could crash the script before it executes a single line. If this seems unlikely, note that this same kind of blindness used to crash some versions of Unix (specifically IRIX), due to symlink-handling code in the kernel and a buffer problem - which they wouldn't fix until it was pointed out that creating a USENET newsgroup of sufficiently long name would crash every SGI newsserver on USENET, which would then crash again during the boot fsck's.
But suppose all that's addressed, and our LSB-option using script mechanism handles the buffer overrun issues and we accept the performance penalty. Only the raw technical issues have been addressed so far.
Naturally, in searching for the "absolute path", we have to ask which one: the logical path via whatever symlinks might have occured, or the physical path - a classic problem of subjective opinion. Well, if no PWD was maintained, the first may be pretty much unobtainable, but either way, we still have to wonder if someone will complain of the shell's current logical/physical setting for "cd .." should be
adhered to. Hardly a recipe for consistancy
from the script's perspective, since it wouldn't
have yet had an opportunity to set its own preference first.
So, how could this absolute pathname "option" for $0 possibly be considered an improvement over the POSIX default? Makes me wonder if the lack of this questionable feature was what was posted as a "defect report" against the POSIX guide.
Hehe. All of this just goes to show that standards writing is a trick business. It's hard to get this kind of thing right in -all- cases.
We used SCO's Unix in 1990 or so to teach Unix students for a while, but after noticing that we'd had to plug in GNU software for almost everything to make it work, we finally switched to SunOS, and later to Linux. But that's not the interesting part. What is, is that Iremember the SCO's original Unix booting with the horrifying sight of Microsoft's copyrights on the Unix flavor underneath.
:-)
You might say, "What? Microsoft did Unix in the 80s? No! That's insane!".
Apparently Microsoft had been working on Unix in some respect for a while, until Bill had decided it had no future (or perhaps, just not a proprietary enough one), and (or so I infer) sold it or licensed it to the Santa Cruz Operation.
This would make for much irony if SCO won their little suit, but then Microsoft bought them to try to reassert control over what Bill once thought was irrelevant, and now clearly -is- the future.
The comments in the suit about IBMs AIX and its claimed collision with the Unix patents is pretty funny, since apparently one of the miseries of doing AIX design was going before a little review board that would judge the odds of your perfectly good code intersecting known non-IBM patents, and then making you break it until it didn't - or so goes one unfortunate's tale.
All of this is, of course, hearsay, so if you were there, just tell us what really happened, yes?
On this flashy japanese page you can look at the C700 from different angles in both the input and viewing modes, as well as see the english specs.
OS: Linux Embedix
CPU: Intel XScaleTM(PXA250 400MHz)
RAM: Flash 64MB (user area about 30MB) and SDRAM 32MB (workarea)
Screen: 640x480 ("dots") 64K colors
Cardslots: SD, CF type II.
?: 4 hours, 50 minutes
Dimensions: 120mm W x 83 mm D x 18.6 mm H
Mass: 225g
The front page to get to this was from http://sl.ezaurus.com/ , from http://www.sharp.co.jp/
- Akira
- Tron
- any Star Wars (although JarJar on IMAX is, ummm...)
- any Lord of the Rings
- Men in Black - especially the end sequence
- Crouching Tiger, Hidden Dragon
- Perfect Storm - you thought those waves were big on a normal screen, eh...
And just about any movie with serious panaromas, including lots of art films, some of the shorts out of the animation festivals, films with large battles scenes or including view from aircraft or space, and so on.Having an IMAX screen for a computer monitor - now that's even better than the IBM T221, neh? The perfect display system for the as-yet-unfinished bedroom Beowulf cluster :-)
You can look at the online version of the patent on the US Patent Office's website. Note that the patent process for this one was started 16 years ago in 1986 (stuff 4698672 into the Patent Number Search box on the search page to see this), which would certainly limit how much longer it could be pursued.
To me, the patent seems to largely be focussed around runlength encoding in digital video - not that this always has any real bearing on how a specific patent can suddenly become profitable. That patent itself states:
[...]It'll be interesting, and rather sad, to see if this actually get applied against JPEGs....
First, mapping is only one possible application, But even within that constraint, the 2D map approach doesn't work well for everyone (yes, some folks still have trouble reading maps), especially considering that a map has to be oriented to match the surroundings (north on the map to north in reality) by the user either in the head or by the physical rotation of the phone. Given the trouble some folks have with this, wouldn't a 1st-person view with fat 3D arrows be more useful as a guide system for those people? I suppose I should distinguish this from mapping, since it isn't exactly the same idea.
Until your eyes have a HUD, a cellphone might be a perfect way to get a 3D view of what you can see PLUS annotations about what's nearby, an arrow for where to turn next (from your own perspective, which can be faster to grok at times than the overhead view), topographic contour overlay, star finder, etc. As long as the phone can sense its orientation as well as position, it could double as an cheap HUD. Saying your eyes can do this on their own disregards the advantage of the computer interlink the cellphone has.
On your comment about wanting four extra keys - I have a Kinesis ergonomic keyboard at home, and the layout gives you about 19 extra keys to use - eight in an extra row below the convention bottom row, and a full, useful keypad for each thumb with six each.
This keyboard is sweet-looking, comfortable, and great for any game with key remapping and heavy mouse use, since you can actually get more commands under one hand than you can on a standard keyboard.
You could probably find most of the same features in another keyboard called the Maltron, but I wasn't exactly inspired by either its industrial british look, or the $350 price - I can get another Kinesis for about $180.
It definitely has a nice look deployed in a geek environment. My roommate has had one for years as well, and he's also quite pleased with it.
The 2 CPU for $249 is for a server, while the 4 CPU at $199 is for just a desktop. Nice desktop, methinks.
Now the question is whether Sun still doing the old 2-user Right-To-Use license from the old days or not, although, unlike some vendors, I don't recall them ever having enforced it at the software level.
[I bought mine through Office Organix or direct, see http://www.officeorganix.com/kenisis1.htm for the former]
:-)
The Kinesis keyboards feel almost perfect, much nicer than the halfway-measures of the MS Natural line in terms of key action in particular (a subjective issue, of course), and have the advantage of being beautifully shaped on the underside for lap use as well.
Furthermore, they suit gaming quite well, with the extra row of keys under 'zxcvb' and "nm,./" and plethora of thumb keys making it far easier to keep one's hand in place during intense gaming while the other hand manipulates the mouse.
The MS Natural (or MS melted) fails to even out the keys between hands, leaving the weird excess punctuation to the right hand in the manner of conventional keyboards, so gaming on them is a bit rougher for people who use the mouse right-handed.
The Kinesis also has the advantages of discarding the useless far-left to front-right keyslant, a legacy of mechanical typewriters, and has a marvelous concavity to each hand's keyset, better following arc through which fingers tend to move.
The thumb keypads are particularly nice, although it takes a new user a little while (a few hours, typically) to get used to having space, backspace, return, delete, control, alt, page up/down etc., all perfect for thumb access. The shift and caps lock are in the normal places, however, so don't panic
Basically, it's a great keyboard, does wonders for reducing RSI, great for any game that lets you remap the keys, and I and my roommate both have them. It also has a provision for attaching a pedal that can be mapped to almost anything but most typically either shift or the numeric-keypad lock (for the embedded keypad in the right-hand keys) The only critical statement I have to make is that escape and the function keys are smaller chiclet keys rather than full keys (see the Maltron for a near equivalent with full function keys), but since Unix doesn't use F1 and so forth much, it's hardly ever been significant.