I'm terribly sorry for forgetting this. It's been three years since the conference and two years since I've touched JACAL at all (or worked at the university).
I should note that the above details were accurate when the system was created. These details have changed (they are not, for example, still running MS IE 5 or NT w/ SP 5, etc.). NathanE can better expound on what the install looks like today.
Four years ago I worked at the the Taylor University computer science department. We had 70+ dual-booting NT/Linux machines running 80+ DOS/Win3.1/Win95/WinNT applications. To further complicate this, Ghost (ImageCast, etc.) would not work since the hardware was widely varying and we wanted several different installation profiles (including/excluding certain apps).
We came up with a solution which allowed an individual to install and configure 70+ machines in two hours (requiring only about 30-40 minutes of the individual's time). This tool, called JACAL, is still being used and was expanded to work with Win 2K and XP.
Here is our solution:
* A boot disk containing only a DHCP kernel-autoconfig NFS root kernel
* an NFS server with the NT i386 image and a base unattend.txt file. This NFS server doesn't necessarily need to be a Linux box. This could be an NT box running WarNFS or something like that if someone wanted to do that.
* a series of perl scripts which, given the machine name and hardware probe information, customize the unattend.txt file
* a perl script which sucessively launch installation of apps after the initial NT build is complete
* a perl script which installs diffs from Microsoft's SysDiff program (we have really augmented this process if you are rightfully having doubts about the standard SysDiff process)
* a script which does DLL and other file conflict and version resolution
* a SaMBa server which houses the diffs of the applications
* a series of ScriptIt files to install apps that don't SysDiff well (MS IE 5, MS Publisher 2000, MS NT SP 5 (6? not yet baby, not yet), sense a theme. Typically these are things which perform OS upgrades (are apps supposed to do that>??))
* Perl and ActiveState Perl run the system from the Linux and NT sides
Features (for both OSs):
* All applications installed and ready to run
* Drivers installed and working (detection done with Linux)
* Centralized log of hardware from each workstation
Other things that we considered but never implemented:
* Remote network PXE(bootp/dhcp) instead of current floppy/CD kickoff disk
* Multicasting file copies
Keep and eye out for a post by "nathane" as he is a maintainer of the current JACAL system at Taylor University.
There is also a **woefully** out of date website at jacal.sf.net.
Many (most) applications and window managers are not aware of the monitor boundries on multihead virtual displays (Xinerama, PanoramiX, etc.). This can be very frustrating.
Personally, I've found that using a non-virtual multihead environment (each head is a separate X screen, e.g.:0.0,:0.1 and:0.2) is much more productive. The limitation of this style of multihead environment is that you can't drag windows between screens (heads) but I actually find that this alleviates the need to manage windows across my screens.
Basically, I assign roles to each of my three screens. On the left (screen:0.0) I have my misc./resource head. On:0.0 I have a couple of terminals available for random taskts (since I use gentoo, one is a ready emerge terminal) but most of the screen is available to my tab capable browser (MozillaFirebird). On alternate virtual workspaces on:0.0 I have other documentation normally acroread.
The second head (:0.1) I have several virtual workspaces with two xterms side-by-side, a single huge term (debug sessions) or OpenOffice fullscreened. This is the head where I get most of my work done. Naturally it is the middle head.
On the right most head (:0.2) I have my communication/status head. The left half of this head is dominated by my email client (mutt). The right half of the head is split between a shell session on my home machine (top) and my IRC client (irssi). On the far right edge of this head, I'm running gkrellm2 which shows me all the assorted statuses. I don't generally use any virtual workspaces on this head.
This separation of tasks works increadibly well. I never wonder where to do work or where my window got to. If I'm doing work, it's on the center head. If I'm reading reference material or news, etc. or if I'm doing some misc. system maintenence it's on the left head. If I'm communicating (email or chat), or doing something on my home system it's on the right. Also, because I have an obvious place to start a task I don't find that I want to move it to another head later.
This seems like the basis of an interesting Ask Slashdot -- How do *you* manage your multihead environment?
Changing the CPU multiplier will not give you what you are looking for as it will likely change your FSB speed and L1/L2 cache access rates. The most common bottlenecks on systems are heirarchical IO bandwidth related. For example, having scads of RAM for buffer/cache will help you with disk IO woes.
Compiling binaries with optimization for a particular processor help with i-cache and d-cache utilization. The fewer instructions fetched (or the order in which they are fetched) makes a big difference in performance.
Boosting CPU cache size (up to practical cache limits), increasing FSB speed and avoiding disk IO are much more significant than CPU M/GHz.
Compilation, especially optimized (-0X) compilation is _VERY_ CPU intense. If you have enough RAM to avoid the disk thrashing caused by writing numerous intermediate files you will peg your CPU.
Most user activities (aside from games) on computers are not bottlenecked by CPU but by various heirarchical IO constraints and hence the previous poster was correct that the CPU is not a significant bottleneck on modern systems.
I can understand that SCO employees feel defensive. If protesters set up a picket out side of HP (my employer) I'm sure I would feel likewise. What I don't appreciate is the apparent reaction of a proper subset of the SCO employees, the libelous and slanderous posters presented at this website.
Let us consider the following facts:
Linux user cannot be characterized, by and large, as music or software pirates -- there is no precedent to label them as such any more than Microsoft Windows users
Not paying for Linux is not a piracy issue, Linux is, by it intent and modus operandi free of licensed and proprietary code
Presuming that IBM has placed illegitimate, license bearing code into the Linux source tree this does not necessarily reflect poorly on Linus Torvalds, Linux kernel developers, Linux users or the OpenSource community
Linux usage != stupidity. (I can only assume that this was meant to be farsical. In the realm of debate the tactic of argumentum ad hominim, "argument against the man," (In this case: "You're stupid!") is generally abandoned in grade school.
"Ya Vol!"[sic] (Intended, correct me if I'm wrong, to be "Jawoll!" a characterization of Nazi adherence to orders popularized by "Hogan's Heroes".) is a crude characiture of nazism not communism. But hey! To the culturally illiterate, what's the difference? Besides, IBM is an oligarchy.
And... Well I could go on but that would be a full scale rant.
I'm reasonably certain that these posters (A) do not characterize all of the "anti-protesters" and (B) do not characterize most SCO workers. It does reflect poorly on SCO managment who allowed their employees to present the above image at the SCO Lindon facility. In all fairness I have no idea what the "anti-SCO" protesters were carrying. It may have been equivalently malevolent drivel.:-)
There are still a number of good reasons for using DLLs. Here are a few examples:
Many applications often share crypto routines in a dll. In order to add a new algorithm/protocol to all the applications on a system which use crypto (which is an unknown quantity) you really want to have these routines in a a dynamically linked library.
Often (in the proprietary, closed source world) routines are kept in a dll to keep their sources private. This doesn't prevent users of the routines to link them statically, however but it does keep the control of the content in the hands of the creator of the dll. I'm not saying that I think this is a great reason but it is compelling to a lot of proprietary software vendors.
In the opensource world the makers of libraries and the libraries' consumers (e.g. applications) are often different groups in weak syncronization. Because of the rapid development and improvement the applications can benefit from a library upgrade. Having to relink every statically linked application would require keeping a list of applications which is a messy prospect and more overhead than most users (packages/distros) want to deal with. It would require keeping around all of the original object files or compiling from sources. This would probably work best in Gentoo Linux but would still be a major pain and more time than it's worth.
Really most UN*X systems (in particular those which are glibc based) already implement Microsoft's "new" scheme. For example, in/usr/lib/:
Note that this scheme can create a "unique identifier" allowing an application to use a particular function using "libname.particular.version" and the the name of the function.
If an application just wants to use libgtkhtml but doesn't care what version it uses it will use "/usr/lib/libgtkhtml.so" and will get the most current version. If the application has a requirement of a version 19 of libgtkhtml it would use "/usr/lib/libgtkhtml.so.19" and get the latest version of libgtkhtml.so.19.0.1. If an application wanted version 20.1.3 it would merely use "/usr/lib/libgtkhtml.so.20.1.3". At any rate, you get the idea.
It amuses me every time Microsoft comes out with a "new" twenty year old technology (such as say, symlinks). It's a move in the right direction but I think they lack the humility to say that they've been rejecting the right answer all along.
Not exactly. Datsun was not intended as a temporary name. The renaming happend as a course of Nissan Motors growing in the european market and then the markets in North America. The point being that the "cybersquatting" charges brought against Uzi Nissan are in large part based on the Nissan name dilution as of 1991 (Datsun only adopted the name of Nissan in the late 1980's and only partially, at that). Note again this site as well as this link that I just found that presents the timeline pretty clearly.
Nissan Motors has an extremely weak case but have managed to manipulate and strong arm the courts (and apparantly in a different situation, in the state of Missisipi) to suit their interests at the expense of individuals. I, for one, will never patronize Nissan. Of course, if my goal is to avoid greedy, corrupt, heavy handed automotive companies I think that leavs me driving either a Mini, a moped or a vehicle powered by soy. Nix the Mini. Their site uses flash...;-)
Did the Slashdot crew stop screening article summaries for intelligible English?
Did the above summary make sense to you? I struggled with the article summary only to come away with some vague notion of "China, moon rape, bad, space, science, bad, bad, mining, bad..."
scsicontrol -send scsi commands
stacker - jukebox control
SCU has I belive all the functionality of scsicontrol and more.
mtx is the the SCSI changer (jukebox) control of which you are speaking.
Linux tape support is good through the SCSI Tape module (nothing for shared bus SCSI, as I recall, though). IDE (ATA) tape drives (such as OnStream's) are supported by the SCSI utilities and tools you already have through the ide_scsi interface.
Having a family name and/or claims predating the incorporation of a company does not keep you safe. I note in particular the case of nissan.com, formerly the home of Israeli born Uzi Nissan's computer company Nissan Computer Corporation.
Uzi was born with the last name of Nissan and put his computer company's website at the place which made sense nissan.com. Nissan, however was not always Nissan but Datsun. It changed its name to Nissan in 1987.
I think that the issue really comes down to the difference between "scripters" and "programmers" not scripting languages and programming languages.
Scripting languages allow the "coder" ("scripter" or "programmer") a great deal more expressiveness in their coding environment -- they are a more effective way to create ideas in code, often at the expense of some runtime performance. The rigid and non-introspective nature of compiled programs typically yields better execution performance at the cost of time taken to accurately describe the problem in the code.
The terms "Scripters" and "Programmers" seems to hang on the "coder's" understanding of how the code specifically interacts with the problem. Since scripting languages offer higher levels of abstractions, an uninformed coder ("scripter") may not be aware of the complete ramifications of their code. They are distanced from the computer's actual behavior by a great deal of abstraction. This is true for compiled programming languages too (or anything above, say, microcode), the difference is how much is being abstracted.
The ideal situation would be to have a "programmer" writing in a scripting language (mixing in compiled code when performance dictates, which it does sometimes). If your only available coders are "scripters" you may do better to have them write in a compiled programming language so they are aware of more of the execution environment.
Personally, when approaching projects of great scale and criticallity, I belive greater scripting language usage is important to be successful. The key is to have "programmers" writing the code so they can make informed decisions on when and where to use compiled programming languages.
I'm currently resisting the urge to go on and on about why scripting languages are important to scaling and criticallity... introspection... dynamic typing... late binding... evaluation environment... in place rapid development... abstracted stack exception handling... *gasp*! cough.. cough..
I guess I'll be modded down for that lack of self control.
How much more black could it be?
on
Blacker Than Black
·
· Score: 5, Funny
One should note that this is what instigated the whole thread in the first place. Gabucino posted to debian-devel because he couldn't get Christian Marillat to respond to the noted problems with his packages.
I think the key issue is his choice of distribution. If your patience is sapped by struggling to install the application in the first place you will be too pissed to take the time to (A) figure things out and (B) contribute where projects are lacking.
Of course, if he did that the rest of us would have to go without the wonderful entertainment that issues forth when Jamie is hot and bothered. Frankly, I don't want my jwz any other way.
I am currently in year nine of nine for my BA/CS degree. I'm pretty sure that I've done all permutations of the work/schooling thing. Here is my history to date:
Two years full time at Grove City College until I decided that their CS program was weak. (Good academics, otherwise.)
Transferred to Taylor University for a year and promptly ran out of cash.
Worked full time (well 70hrs/week) for Phoenix Contact, GmbH in the MIS group at their North America headquarters.
Still working (as long as I can...;) for HP and about to take my final two courses during nights at local colleges to transfer back to Taylor University.
My advice?
I guess any of the above work... The most important thing is to FINISH WHILE YOU CAN!!!
For those of you who have used Micros~1 sysdiff.exe you know how that company is interested in giving it's users options.;)
The sysdiff program has the "-m" option when reapplying differences to a system. It is required. That's right a required option! What does "-m" stand for? Manditory. "-m" is the manditory option!!!
Only from Micros~1...
This issue with Dell is only another case of Micros~1 presenting an option to the consumer.
I've toyed with this idea myself several times but have never had the time (or resources) to do anything about it.;-)
linuxtelephony.org is likely of interest. It has some good information and, just as importantly, lots of good links.
Asterisk seems to be a strong, fully featured, GPL'ed PBX project which has some hardware associated with the project that seems to be pretty well priced.
I can't seem to find my other links but they're probably linked off of linuxtelephony.org.
Newer CD-ROMs have a much better chance of surviving than original CDs did. There have been several major changes.
Plastics are now more flexible and less prone to shattering.
Thicker plastic places media farther from surface, hence farther from scratches. Scratches can also be filled since the actual media hasn't been damaged.
No new CDs from the "Crash Test Dummies" have been released. The last copy of "Mmmmm...Mmmmmm...Mmmmm...Mmmm..." I saw was the victim of a drill bit, a microwave, a utility knife and, eventually, a concrete wall.
Going back to aluminum foil presses rather than silver -- a couple of companies (one of the larger British CD manufacturers) attempted silver for a while until someone discovered that silver tarnishes over time.
There are a number of things that could have unintentional results.
How accurate is this?
If it is highly accurate we are now installing modular warhead guidance systems into cars for easy smuggling and delivery.
If it is not accurate beyond the usual GPS resolution we have envents where there are two parallel roads of different speends and I'm stuck doing 40Km on the highway... (is that dangerous????) The systems will also need to have up to the minute changes in traffic patterns so that when roads shift for construction the system behaves properly rather than adding trouble.
What is the system failure condition?
When the unit cannot contact the satellite/GPS system does it stop the car or remove restraints? (or I suppose enforce a default speed?)
If the system stops the vehicle we have just added one more possible breakdown to an already overly complex breakdown prone device. Breakdowns can be dangerous as well. This is no good.
If there is no restriction when the system fails we have a totally useless, very expensive device which will allow illegal people or people who are differently moraled install "GPS interferance" devices which allow them to drive at whatever speed they want.
If the system has a default speed for a system failure event it needs to be fairly fast as not to cut someone to a crawl in the middle of the highway. This would tend to lead to the behavior of no speed limit on smaller roads with the aid of a GPS jamming device.
This is going to be a difficult, uphill battle for Hawaii given their recent growth in production of locally sourced, volcanic S(O2)...
- Lowering soldiers' core body temperature might keep them from overheating.
sound like they are discussing the issues surrounding overclocked soldiers.I'm terribly sorry for forgetting this. It's been three years since the conference and two years since I've touched JACAL at all (or worked at the university).
I should note that the above details were accurate when the system was created. These details have changed (they are not, for example, still running MS IE 5 or NT w/ SP 5, etc.). NathanE can better expound on what the install looks like today.
Four years ago I worked at the the Taylor University computer science department. We had 70+ dual-booting NT/Linux machines running 80+ DOS/Win3.1/Win95/WinNT applications. To further complicate this, Ghost (ImageCast, etc.) would not work since the hardware was widely varying and we wanted several different installation profiles (including/excluding certain apps).
We came up with a solution which allowed an individual to install and configure
70+ machines in two hours (requiring only about 30-40 minutes of the
individual's time). This tool, called JACAL, is still being used and was expanded to work with Win 2K and XP.
Here is our solution:
* A boot disk containing only a DHCP kernel-autoconfig NFS root kernel
* an NFS server with the NT i386 image and a base unattend.txt file. This NFS server doesn't necessarily need to be a Linux box. This could be an NT box running WarNFS or something like that if someone wanted to do that.
* a series of perl scripts which, given the machine name and hardware probe information, customize the unattend.txt file
* a perl script which sucessively launch installation of apps after the initial NT build is complete
* a perl script which installs diffs from Microsoft's SysDiff program (we have really augmented this process if you are rightfully having doubts about the standard SysDiff process)
* a script which does DLL and other file conflict and version resolution
* a SaMBa server which houses the diffs of the applications
* a series of ScriptIt files to install apps that don't SysDiff well (MS IE 5, MS Publisher 2000, MS NT SP 5 (6? not yet baby, not yet), sense a theme. Typically these are things which perform OS upgrades (are apps supposed to do that>??))
* Perl and ActiveState Perl run the system from the Linux and NT sides
Features (for both OSs):
* All applications installed and ready to run
* Drivers installed and working (detection done with Linux)
* Centralized log of hardware from each workstation
Other things that we considered but never implemented:
* Remote network PXE(bootp/dhcp) instead of current floppy/CD kickoff disk
* Multicasting file copies
Keep and eye out for a post by "nathane" as he is a maintainer of the current JACAL system at Taylor University.
There is also a **woefully** out of date website at jacal.sf.net.
Many (most) applications and window managers are not aware of the monitor boundries on multihead virtual displays (Xinerama, PanoramiX, etc.). This can be very frustrating.
:0.0, :0.1 and :0.2) is much more productive. The limitation of this style of multihead environment is that you can't drag windows between screens (heads) but I actually find that this alleviates the need to manage windows across my screens.
:0.0) I have my misc./resource head. On :0.0 I have a couple of terminals available for random taskts (since I use gentoo, one is a ready emerge terminal) but most of the screen is available to my tab capable browser (MozillaFirebird). On alternate virtual workspaces on :0.0 I have other documentation normally acroread.
Personally, I've found that using a non-virtual multihead environment (each head is a separate X screen, e.g.
Basically, I assign roles to each of my three screens. On the left (screen
The second head (:0.1) I have several virtual workspaces with two xterms side-by-side, a single huge term (debug sessions) or OpenOffice fullscreened. This is the head where I get most of my work done. Naturally it is the middle head.
On the right most head (:0.2) I have my communication/status head. The left half of this head is dominated by my email client (mutt). The right half of the head is split between a shell session on my home machine (top) and my IRC client (irssi). On the far right edge of this head, I'm running gkrellm2 which shows me all the assorted statuses. I don't generally use any virtual workspaces on this head.
This separation of tasks works increadibly well. I never wonder where to do work or where my window got to. If I'm doing work, it's on the center head. If I'm reading reference material or news, etc. or if I'm doing some misc. system maintenence it's on the left head. If I'm communicating (email or chat), or doing something on my home system it's on the right. Also, because I have an obvious place to start a task I don't find that I want to move it to another head later.
This seems like the basis of an interesting Ask Slashdot -- How do *you* manage your multihead environment?
Changing the CPU multiplier will not give you what you are looking for as it will likely change your FSB speed and L1/L2 cache access rates. The most common bottlenecks on systems are heirarchical IO bandwidth related. For example, having scads of RAM for buffer/cache will help you with disk IO woes.
Compiling binaries with optimization for a particular processor help with i-cache and d-cache utilization. The fewer instructions fetched (or the order in which they are fetched) makes a big difference in performance.
Boosting CPU cache size (up to practical cache limits), increasing FSB speed and avoiding disk IO are much more significant than CPU M/GHz.
Compilation, especially optimized (-0X) compilation is _VERY_ CPU intense. If you have enough RAM to avoid the disk thrashing caused by writing numerous intermediate files you will peg your CPU.
Most user activities (aside from games) on computers are not bottlenecked by CPU but by various heirarchical IO constraints and hence the previous poster was correct that the CPU is not a significant bottleneck on modern systems.
Let us consider the following facts:
- Linux user cannot be characterized, by and large, as music or software pirates -- there is no precedent to label them as such any more than Microsoft Windows users
- Not paying for Linux is not a piracy issue, Linux is, by it intent and modus operandi free of licensed and proprietary code
- Presuming that IBM has placed illegitimate, license bearing code into the Linux source tree this does not necessarily reflect poorly on Linus Torvalds, Linux kernel developers, Linux users or the OpenSource community
- Linux usage != stupidity. (I can only assume that this was meant to be farsical. In the realm of debate the tactic of argumentum ad hominim, "argument against the man," (In this case: "You're stupid!") is generally abandoned in grade school.
- "Ya Vol!"[sic] (Intended, correct me if I'm wrong, to be "Jawoll!" a characterization of Nazi adherence to orders popularized by "Hogan's Heroes".) is a crude characiture of nazism not communism. But hey! To the culturally illiterate, what's the difference? Besides, IBM is an oligarchy.
- And... Well I could go on but that would be a full scale rant.
I'm reasonably certain that these posters (A) do not characterize all of the "anti-protesters" and (B) do not characterize most SCO workers. It does reflect poorly on SCO managment who allowed their employees to present the above image at the SCO Lindon facility. In all fairness I have no idea what the "anti-SCO" protesters were carrying. It may have been equivalently malevolent drivel.No problem. Easy mistake.
Really most UN*X systems (in particular those which are glibc based) already implement Microsoft's "new" scheme. For example, in /usr/lib/:
Note that this scheme can create a "unique identifier" allowing an application to use a particular function using "libname.particular.version" and the the name of the function.If an application just wants to use libgtkhtml but doesn't care what version it uses it will use "/usr/lib/libgtkhtml.so" and will get the most current version. If the application has a requirement of a version 19 of libgtkhtml it would use "/usr/lib/libgtkhtml.so.19" and get the latest version of libgtkhtml.so.19.0.1. If an application wanted version 20.1.3 it would merely use "/usr/lib/libgtkhtml.so.20.1.3". At any rate, you get the idea.
It amuses me every time Microsoft comes out with a "new" twenty year old technology (such as say, symlinks). It's a move in the right direction but I think they lack the humility to say that they've been rejecting the right answer all along.
Nissan Motors has an extremely weak case but have managed to manipulate and strong arm the courts (and apparantly in a different situation, in the state of Missisipi) to suit their interests at the expense of individuals. I, for one, will never patronize Nissan. Of course, if my goal is to avoid greedy, corrupt, heavy handed automotive companies I think that leavs me driving either a Mini, a moped or a vehicle powered by soy. Nix the Mini. Their site uses flash... ;-)
Did the Slashdot crew stop screening article summaries for intelligible English?
Did the above summary make sense to you? I struggled with the article summary only to come away with some vague notion of "China, moon rape, bad, space, science, bad, bad, mining, bad..."
-
scsicontrol -send scsi commands
SCU has I belive all the functionality of scsicontrol and more.stacker - jukebox control
mtx is the the SCSI changer (jukebox) control of which you are speaking.
Linux tape support is good through the SCSI Tape module (nothing for shared bus SCSI, as I recall, though). IDE (ATA) tape drives (such as OnStream's) are supported by the SCSI utilities and tools you already have through the ide_scsi interface.
Uzi was born with the last name of Nissan and put his computer company's website at the place which made sense nissan.com. Nissan, however was not always Nissan but Datsun. It changed its name to Nissan in 1987.
The full sad story is here.
Other articles are here and here.
I think that the issue really comes down to the difference between "scripters" and "programmers" not scripting languages and programming languages.
... introspection ... dynamic typing ... late binding ... evaluation environment ... in place rapid development ... abstracted stack exception handling ... *gasp*! cough.. cough..
Scripting languages allow the "coder" ("scripter" or "programmer") a great deal more expressiveness in their coding environment -- they are a more effective way to create ideas in code, often at the expense of some runtime performance. The rigid and non-introspective nature of compiled programs typically yields better execution performance at the cost of time taken to accurately describe the problem in the code.
The terms "Scripters" and "Programmers" seems to hang on the "coder's" understanding of how the code specifically interacts with the problem. Since scripting languages offer higher levels of abstractions, an uninformed coder ("scripter") may not be aware of the complete ramifications of their code. They are distanced from the computer's actual behavior by a great deal of abstraction. This is true for compiled programming languages too (or anything above, say, microcode), the difference is how much is being abstracted.
The ideal situation would be to have a "programmer" writing in a scripting language (mixing in compiled code when performance dictates, which it does sometimes). If your only available coders are "scripters" you may do better to have them write in a compiled programming language so they are aware of more of the execution environment.
Personally, when approaching projects of great scale and criticallity, I belive greater scripting language usage is important to be successful. The key is to have "programmers" writing the code so they can make informed decisions on when and where to use compiled programming languages.
I'm currently resisting the urge to go on and on about why scripting languages are important to scaling and criticallity
I guess I'll be modded down for that lack of self control.
None.
None more black.
Read the thread here
Jamie's complaints would mostly go away if he did two things:
- Installed Gentoo
- Used --nogui
I think the key issue is his choice of distribution. If your patience is sapped by struggling to install the application in the first place you will be too pissed to take the time to (A) figure things out and (B) contribute where projects are lacking.Of course, if he did that the rest of us would have to go without the wonderful entertainment that issues forth when Jamie is hot and bothered. Frankly, I don't want my jwz any other way.
I am currently in year nine of nine for my BA/CS degree. I'm pretty sure that I've done all permutations of the work/schooling thing. Here is my history to date:
- Two years full time at Grove City College until I decided that their CS program was weak. (Good academics, otherwise.)
- Transferred to Taylor University for a year and promptly ran out of cash.
- Worked full time (well 70hrs/week) for Phoenix Contact, GmbH in the MIS group at their North America headquarters.
- Returned to Taylor University to run the university Computing and Systems Sciences department's network and take a class or to on the side. I worked for the university for three years.
- Hired by HP (nee Compaq) Took two classes correspondance through Taylor University World Wide Campus during the last year.
- Still working (as long as I can...
;) for HP and about to take my final two courses during nights at local colleges to transfer back to Taylor University.
My advice? I guess any of the above work... The most important thing is to FINISH WHILE YOU CAN!!!The sysdiff program has the "-m" option when reapplying differences to a system. It is required. That's right a required option! What does "-m" stand for? Manditory. "-m" is the manditory option !!!
Only from Micros~1...
This issue with Dell is only another case of Micros~1 presenting an option to the consumer.
Just another manditory option...
linuxtelephony.org is likely of interest. It has some good information and, just as importantly, lots of good links.
Asterisk seems to be a strong, fully featured, GPL'ed PBX project which has some hardware associated with the project that seems to be pretty well priced.
I can't seem to find my other links but they're probably linked off of linuxtelephony.org.
+------->
- How accurate is this?
- If it is highly accurate we are now installing modular warhead guidance systems into cars for easy smuggling and delivery.
- What is the system failure condition?
- When the unit cannot contact the satellite/GPS system does it stop the car or remove restraints? (or I suppose enforce a default speed?)
Frankly, this is really no good.If it is not accurate beyond the usual GPS resolution we have envents where there are two parallel roads of different speends and I'm stuck doing 40Km on the highway... (is that dangerous????) The systems will also need to have up to the minute changes in traffic patterns so that when roads shift for construction the system behaves properly rather than adding trouble.
If the system stops the vehicle we have just added one more possible breakdown to an already overly complex breakdown prone device. Breakdowns can be dangerous as well. This is no good.
If there is no restriction when the system fails we have a totally useless, very expensive device which will allow illegal people or people who are differently moraled install "GPS interferance" devices which allow them to drive at whatever speed they want.
If the system has a default speed for a system failure event it needs to be fairly fast as not to cut someone to a crawl in the middle of the highway. This would tend to lead to the behavior of no speed limit on smaller roads with the aid of a GPS jamming device.
+------->