As I remember it from college physics, an order of magnitude is approximately ten times. We were taught to think of orders of magnitude and changes within given ranges: The first order of magnitude was any value between 0.3 and 3.0, second order between 3.0 and 30.0, third order between 30.0 and 300.0, fourth order between 300.0 and 3000.0, and so on. (why did we put boundries at decade multiples of three? I don't quire remember, but it had something to do with logarithms)
Given this definition of an order of magnitude, we can see that CRTs are priced in the third order of magnitude, while LCDs are, except for the very best bargains, in the fourth order: one order of magnitude difference.
P.S., a cartoon I once saw in a lab at university, shows two scientists standing in front of a chalk board, one talking to the other, the caption reads: "It's within an order of magnitude, in other words it's completely wrong."
How can anyone claim to have a meaningful Linux timeline that doesn't even include the dates of the major kernel releases or the publication of CatB (or the Halloween documents)? Are we really supposed to believe that nothing important happened to the Linux community for over a year and a half between April 1995 and January 1997?
Thanks for the very informative post - it's certainly been worthwhile for me.
Just a quick question though - I'm looking into buying an iBook within the next two months or so. How would your stated reccomendations fit in with that? (apart from the obvious differences)
For laptops of all stripes, not just Apple products, I think it is better to get everything from one source. It is much more difficult to do third party upgrades on laptops than on desktop machines and the upgrades don't tend to be as competitively priced.
That said, the current crop of Apple laptops seem to use standard memory components (both the current iBooks and PowerBook G4s use standard SO-DIMMs) and the hard drives have been 2.5" IDE drives ever since 1996 or so, so you can probably upgrade either the memory or hard drive from third parties for a much better price than Apple would offer.
As for how easy it is to work on the Apple laptops: they have been much easier to deal with than most PC laptops ever since the days of the PB1400 (back in '96 or '97) when Apple stated putting all the upgradable components directly under the flip-out keyboard. Things are still a bit cramped, but you don't need to dismantle the entire machine just to add memory.
My favorite with the current iBook is the smaller 12" model, just because it is a bit more compact than the 14" model. The 12", however, doesn't have as long a battery life as the 14", so you need to decide which is more important to you, size of battery life.
If I were in the market, I'd get the bottom of the line iBook with minimum memory. Then I'd immediately add extra memory from a third-party, but I would wait on the hard drive upgrade until I really needed it.
In general, the trick with buying Apple products isn't how to get the lowest price at the outset, but how to minimize total expenditure over the life of the system. This tends to mean buying a system that just meets your current needs and then upgrading piecemeal over the next 3 to 5 years.
Apple machines tend to last much longer than their PC counterparts, not because they are better built (though some are) but because they are better designed for expansion: The maximum memory limits on Apple devices tend to be higher than similar PCs and you can often upgrade the CPU without requiring a complete motherboard swap. This means that my 7 year old PowerMac 8500 is still a decent machine, with 768MB of RAM (and still room to expand), a $200 G3 CPU upgrade, a RAGE-128 video card, and a couple of SCSI hard disks.
Are modern G4 towers quieter and/or cooler than comparable x86 workstations?
Yes.
Is it wiser to spend money on memory or megahertz?
Niether. Buy a middle of the line machine to get the 'sweet spot' in MHz/$. Get your extra memory from a third party (I would suggest SmallDog, Other World Computing, or Multiwave Direct) since Apple routinely overcharges for memory.
Is it best to buy everything directly from Apple, or just a minimum to be fleshed out with cheaper, after-market add-ons?
In general, yes, but it depends. You might as well get the stock optical drive and hard disk, since you have to get something anyway. Never buy more memory than is absolutely necessary from Apple, for the reason stated above. Almost anything else is a toss-up and depends on the exact item and current third-party pricing.
Shop around before you buy. With Apples current attitude toward industry standard parts, you can, generally, use all sorts of commodity, over-the-counter parts that are labled for PCs (NOTE: video cards don't follow this rule. Niether do modems. For most other types of cards you can either find Mac drivers online, or you can download programs from the manuacturers to flash that card's ROM for Mac use. It is best to do some research before you buy)
What's the best video option for dual-head on Jaguar?
Best by what measure? The ATI 7500 is a nice enough card (I use a RADEON 7000 PCI at home in B&W G3) but I'd prefer an 8500. It's a shame that Apple doesn't offer it. OTOH, the NVidia card does sound very nice.
Does OS X make SMP worth the investment?
I don't know, what are you planning to use the machine for? Most applications, IMO, don't benefit too much from SMP, and the premium kills and 'sweet spot' opportunity. Still, it depends on your application.
Is the SCSI performance gain great enough to be worth the investment over IDE?
On a server, sure, but not for most desktop applications. Besides, you can always add a third-party SCSI card at a later date.
Overall, my advice is to buy a middle of the line machine, skimp on memory directly from Apple (upgrade though a third party), possibly skimp on the hard drive as well (upgrade through a third party), get the best optical drive and video card Apple offers (software support is vital for both, so get them from Apple), and everything else is a toss-up. Buying middle of the line saves you some money, which is good since this is your first Mac: if you discover you don't like Apple products (not that I think that's likely to happen) you won't feel so bad about the money you spent. Once you are comfortable with Apple hardware, you can decide home much (or little) you want to spend on your next machine.
In general, unless there are compelling reasons to go for the top of the line, buying middle of the line is a good policy. When your machine is, inevitably, made obsolete, you won't feel so bad, since you weren't cutting edge to begin with. With Macs, you have the added advantage of, generally, being able to upgrade the system (new CPU, memory, disks, etc.) without needing an entirely new motherboard, so the middle of the line system will last longer than similar systems on the PC side.
I agree that having deltas that span multiple files is a good thing. But this is just an improvement on the version control theme: managing changes in groups of files, not individual files. If this is "the whole point of CM", then CM is clearly just version control.
I know (everyone knows) that CVS has many shortcomings. But the shortcomings (at least the ones I've heard about, eg lack of atomic changesets, poor branching/merging, centralized) are still about version control.
ClearCase has some disconnected functionality (snapshot views), though it has many flaws (like, due to the fascist license regime, you can't run any clearcase commands while disconnected!). But what is the point of your question? ClearCase is commonly termed a CM tool, but as a user, all I see is version control. What part of ClearCase is CM, as opposed to version control?
Again, my challenge is to evince some important function of "configuration management" tools that is fundamentally different from version control.
First, CM has nothing to do with file deltas. You may assert it as many times as you like, but still, CM is not about version control.
Second, the shortcomings of CVS are not the issue. CVS is a version control tool, not a CM tool.
Third, I've never used ClearCase, so I don't know what features it has that may (or may not) be relevant to CM. However, unless you are the CM guy, it is likely that you never use any of the CM features of ClearCase. As a programmer, you don't really need to do anything other than version control, but that doesn't mean that version control is the only task that is important or that the tool supports.
One final time: CM is all about keeping track of exactly what versions of what files went into a specific build of a system (you may be shipping different builds of the system to different clients, for example), where those files are stored in a specific build, what was done to install the build on the client hardware and what environment variables/registry entries/symbols/logical names/etc. were set to what values for any specific installation. Much of this information can be (and often is) stored in the form of installation and configuration scripts that are kept under revision control. You may also want to associate user documentation, discrepency reports, enhancement requrests, work orders, and even client specifications or contracts with a specific build for a specific client. On top of all this you would like to have the information in a form that can be readily digested by humans (assorted install/configure scripts do not meet this requirement) so that new recruits and non-coders can understand what goes into the system and its installation.
To say that just becuase you have the installtion and configuration scripts in revision control, you are effectively managing the system configuration is like saying that just because you have been given the compiled executables, you have all the documentation you need to maintain and enhance the software! CM is not about the source code, but about the meta-data of the built and installed system. It tells you not only what you can tweak in the system, but also how that tweaking was done for a specific installation.
In summary, CM records the following facets of the system:
what versions of the OS, compilers, development tools, OS utilities, libraries, etc. were used to build the system.
where are the compiled executables and configuration files stored during installation.
what environment variables, registry entries, logical names, symbols, etc. need to be defined for the system to operate, and what does each value do.
anything else that needs to be done to build and install the system, including: file system structures (do we need to create specific directories with specific permissions?) network connections and hosts (do we need to have specific hosts that the system will try to talk to?), peripheral devices (do we need a printer/tape library/spot-welding robot attached to the machine?), etc.
what 'bill of materials' was included in a specific release to the customer (or should have been), including: database structures, static database entries, data files, executables, documentation, etc.
what client requirements were met by a specific build, including: contracts, specifications, enhancement requests, bug fixes, etc.
Ok, if configuration management is this big thing that is fundamentally more than version control, answer these challenges:
1. Why does the OpenCM home page call itself a "replacement for CVS", which you say is a version control tool, not a configuration management system. Why does the site (at least the overview and features sections) list only version control features? Where are the CM features in OpenCM?
Well, I wasn't addressing the question of whether or not OpenCM was a valid CM tool (which it may or may not be, I have no direct experience with it) but whether or not there existed a discipline of CM separate from that of simple source code version control. Similarly, your assertion was not that OpenCM wasn't really a CM tool, but that the term CM itself had no use or meaning separate from the concept of version control.
2. If CM is needed for programming "in the large", how have most large free software projects gotten away without it? Or, if they are using CM in some form, where is it?
Probably the same way that many large commercial projects have gotten away without any real version control: badly. Free software projects are actually at something of an advantage in this respect. There are fewer time and budget constraints on free software than on commercial projects, so free software can afford more wasted effort making up for the lack of CM. As well, free software often has a freeer hand in designing the system so that CM might be less of an issue. Finally, most free software projects are simply not large enough to need CM: those that are large enough, probably have some form of documentation that covers CM issues outside of the version control arena (FAQs, HOWTOs, ReadMes, etc.)
3. I've used ClearCase for several medium-sized (5-10 full-time programmers) projects. As far as I can tell, all of our use of ClearCase falls under what I would consider version control. What parts of ClearCase are configuration management? (Of course, you can skip this if you haven't used ClearCase.)
5-10 programmers is a pretty small project compared to the kinds of things I've encountered that required active CM: think of something like 20-30 programmers and 3-5 subsystem architects (remember, BTW, complexity increases exponentially to team size, not linearly) As far as ClearCase is concerned, I've never used it so I wouldn't know.
I know about programming "in the large" (or at least medium-sized). I've used tools more powerful than CVS. These tools are powerful because they do version control better than CVS, not because they offer something fundamentally different.
See above. 'nuff said.
And your argument that CM is about what files go where seems like nonsense to me. First, even if that is important, it hardly requires a sophisticated tool. You might as well use (a subset of) RPM for that. Or a 100 line Perl script (that reads the file locations, etc, from a config file). Second, code should generally be buildable and runnable right in the source control system, for quick testing. So if you need some fancy layer just to get the code into a runnable state, you're probably doing something wrong.
The only reason that you think it is nonesense is that you've never worked on a large production system. CM isn't about a technical fix for a technical problem, it is about managing the complexity of large systems, their installation and configuration, and allowing humans to keep track of all the fiddling details. A tool can help with some of this, but the real heart of the matter is a managerial issue.
As for doing something wrong if it takes so much effort to get the code into a runnable state: you are probably correct. The sad fact is, however, that most large software projects are doing something wrong in exactly this way (many somethings, in fact), but there is little hope of being able to turn the tide.
Really large software projects are too big for even a large team of people to tackle every aspect of the system. Therefore, large projects must be built on top of smaller pieces, often pieces that have been built by other people. Each of these component pieces has its own fiobles and requirements, all of which combine to present the system architect with one giant mess of fiobles and requirements. The job of CM is to manage this mess of foibles and requirements in such a way that the system can be installed and operated without bankrupting the company in the process.
Face it: the primary purpose of any of these systems is to manage the various versions in some body of content. So I reassert that "version control" or "revision control" or "change control" is the best name.
No, as the previous poster correctly stated, that is the job of a version control system like RCS, SCCS or CVS. A CM tool keeps track of a bunch of information that is not part of the source code in any way. CM allows you to capture how to install a program (or system of programs): what files need to go where, what directories need to be created, what environment variables (or symbols, logical names, etc.) need to be defined and what their values should be, and a whole host of other things that are not directly captured in the program's source.
You can use a version control tool to keep track of this information, but it is a lot of work and is pretty hard to keep straight (keeping the install scripts in CVS is often confused for a CM solution, but it doesn't help when your old CM guy leaves and you need to bring the new CM guy up to speed on what goes where and why). The real purpose of CM is not simply to make it easy to install and configure the system, but to make it easy for humans to understand what that process entails and detect when something has been changed or overlooked.
Some folks might be forgiven for thinking that CM and version control are the same thing: if you have never worked on a real production system before (one with many programs and a complex set of directories and configuration files, as opposed to some little toy program for a class project) you have probably never encountered the need for CM. Unfortunately, there is almost no way to demonstrate the need for CM in the small: unless the size of the system is larger than what one person can comfortably think about at one time, the need for CM just doesn't arise.
Any protection scheme that relies on a single test point is child's play to circumvent. If you have code sequence like so:
get user's authentication credentials
<do some magic on the credentials>
if the magic didn't work, exit
can be trivially defeated by simply adding one jump:
goto location A
get user's authentication credentials
<do some magic on the credentials>
if the magic didn't work, exit
(location A is here)
now, insert your Z80 interpreter where the above code reads "<do some magic on the credentials>" and see how hard it is to defeat. Even liberally sprinkling your program with calls to the magic won't help, it just increases the number of times that cracker has to insert jumps into the machine code.
The biggest single problem is C, with its casual attitude towards arrays and pointers
While C pointers are the bane of undergrads and junior programmers world wide, the resulting bugs are squashed quickly in production environments. Most of the big, hairy, bugs are both more mundane and more subtle: complex and misunderstood 'business logic', inadequately tested reporting and summarization routines, databases without any consitency checking, and incorrectly implemented multi-threaded systems.
Some of these problems can be laid at the feet of the implementation languages, but most of them are the fault of hasty, clumsy programming, regardless of language. Some can also be laid at the foot of the client/contractor interface: the client only has a vague idea of what they want, and the contractors are more interested in not antagonizing the client with too many questions than producing usable specs. Lets not even consider the problem of who to bill for properly maintaind developer documentation.
The second big problem is weak interprocess communication...The basic problem is that what you usually want is a subroutine call, but what the OS gives you is an I/O operation.
Weak inter-process communication isn't a problem, it's a feature! The best way to build reliable, maintainable systems is with loosely coupled processes that exchange data through simple file-like streams. Then, when something fails, you can remove the misbehaving part, without disrupting the rest of the system, and examine the intermediate files to diagnose the problem.
In fact, one of the worst culprits in the modern software rogues gallery is the database, precisely because it strengthens the coupling between all parts of the system. Sophisticated IPC tools, that make IPC look just like a function call, result in brittle, opaque systems that can't be easily maintained or diagnosed.
The third big problem is DMA... With channelized I/O, drivers aren't as privileged. They can only mess up their own peripheral, not the whole system.
DMA and device drivers are only the concern of a very small fraction of programmers. Most of those programmers who do have to deal with such things, however, are well able to manage any of the resulting complexities.
I/O channels are nice, I admit, but their lack is not a fatal flaw. Perfectly stable systems can be built on simple interrupt or DMA driven architectures.
Fourth, Microsoft likes a complicated OS. Ballmer has said so publicly. If PCs came with channelized hardware and a microkernel in ROM, the OS would have far less to do, and would be more of a commodity. There'd be alternatives, like KDE and Gnome on Linux, all of which ran the same applications. Standardized interprogram communication, enforced by the kernel and hardware, would make components more pluggable. All this would dent the Microsoft monopoly severely.
The lack of channelized hardware or an in-ROM micro-kernel is not why we don't have a comoditized OS on Intel PCs. In fact, we do have comoditized OS's: Linux, the BSDs, Solaris etc. are all adequate counter examples. However, Microsoft has managed to manipulate the market in order to marginalize any significant competition. The fault is entirely a political/economic one which cannot be addressed technologically.
In the entire 4 years that I spent in the CS department at a well respected state university I never saw an exam that required more than 100 lines of actual code to answer a question. All of the heavy lifting was done in the projects, and only snippets or toy programs were used for exam questions.
If your school is making you write hundreds of lines of code, on an exam, and requiring that the code be ready to both compile and run flawlessly, I'd advise you to look for another school: first, the fact that the department seems to fixated on generating code in a particular language is a very bad sign. Computer science is not about coding, but about the theory and structure of programs and computation, none of which needs to be expressed in the kind of strict syntax required of real-world programming languages. Second, the fact that the department even thinks that anyone could write hundreds of lines of code in a couple hours and have any hope the code compiling correctly, much less working, is ridiculous and suggests that the department itself is less than top quality.
All of that said, when I was required to write real code on an exam, there was always some leeway for 'typos' (or whatever the equivalent is when you are writing with a pen, rather than typing at a keyboard). Most of the time, however, only psuedo-code was required. Even my computer architecture course, where we discussed scheduling of machine instructions, allowed the use of entirely hypothetical assembly languages on the exams.
Even though it uses Java (conversion to C++ should be a breeze) as the implementation language, you might want to take a look at Great Ideas in Computer Science with Java by Biermann and Ramm from MIT Press (ISBN 0-2620-2497-7). It covers a wide range of ideas in a manner that is quite approachable for non-CS folk.
It cost me at least $20,000 to get the boolean value result of the function do_you_take_this_man().
Let's remember, not all bits are created equal. Each bit of information is, potentially, the answer to a single yes-or-no question, and some questions are far more important than others. Hence, some bits are worth far more than others.
Let's also remember, economists (at least free-market capitalists) will tell you that a thing is worth whatever you can get someone to pay for it. This means, of course, that value and worth are nonsensical terms and you can't ask any reasonable questions about them.
If, however, you are not a free-market capitalist, you might subscribe to the Marxist definition of value: that a thing aquires its value based on how much human effort was put into the thing. In that case, the value of access to a well used MMORPG account could be quite substantial (how much is your time worth, mine is worth quite a bit).
Finally, we must consider that even for a single bit, the two possible values (yes or no) do not always have equal worth: I would have been willing to pay far more for the yes result of the above function than for the no result. Something very similar is true for the MMORPG accounts (base on how well the account has been used).
wake me up when someone does a usefull benchmark on these systems
Why? The Clawhammer is a consumer chip aimed at replacing the Athlon XP. Many consumers run games like Quake3.
Well, that's find for them, but it's of no help to me (who doesn't run Quake). Besides, what makes anyone think that frame-rates in Quake are primarily dependant on CPU speed? Maybe they are, but I suspect that AGP bandwidth and the polygon drawing rate of your video card are more important.
For what I use my x86 boxen for, SPECint and stream are pretty close to perfect benchmarks, and, I would think, for most users, the same benchmarks would be pretty good measures of the fitness of one CPU verses another. My real complaint isn't that Quake III isn't a usefull benchmark for some user's, but that it doesn't really measure CPU performance. You might as well tell me which machine rolls downhill faster or better survives a drop from the third floor.
The folks doing Quake III fps benchmarking aren't using it becuase it measures the anything important, but because it is the only tool they have: they are driving screws with a hammer. That wouldn't be such a bad thing, except for the fact that better benchmarks are readilly available. Why should I listen to someone who is clearly too ignorant to even choose appropriate tools?
<YAWN> wake me up when someone does a usefull benchmark on these systems. I don't trust proprietary micro-benchmarks and I have no use for Quake III fps numbers. I'd prefer a SPECint/fp score set, but will settle for kernel/gcc/ddd compile times and a stream run. (I don't do enough FP work to propose a poor-man's substitute for SPECfp and the entire question of DB/transaction benchmarking is a tougher nut than I'm willing to crack).
Still, I'm eagerly awaiting the ClawHammer release. Every x86 box I've built for the last 5 years has been pure AMD, and I've been quite happy with them.
University of Maryland has both the WAM and GLUE systems. The WAM labs are computer labs for any student on campus, regardless of major and include a wide range of platforms both in open labs and via dialup. The unix systems arekerberized and share user directories via AFS (Andrew File System). The GLUE labs are a similar architecture but mainly for the use of engineering students. Both projects are production systems but are partially run as research projects in the Comp. Sci. or Engineering departments.
I used to work in the WAM and GLUE labs when I was an undergrad at UMCP, and the folks that managed the systems were pretty friendly, if you can get contact info for the current WAM sysadmins, they can probably give you better pointers. In the mean time, there is a page giving useage statistics for the WAM/GLUE cluster.
If I make a copy of something (music, TV shows, movies) for my own use in another medium (MP3 rather than audio CD, or playing DVD on Linux rather than some other OS) then I am stealing. To simplify: wathing the content is stealing
if I don't watch some content (advertising, FBI warnings, what-have-you) then I am also stealing. To simplify not watching content is stealing
So, I'm a thief no matter what I do. Worse yet, I'm a thief even if I don't do anything. Nughty me for breathing their air! Next thing you know, it will be illegal to own a TV with an off switch. (que Mac Headroom)
Most every sysadmin I know got into the field through contacts made during their undergrad education. The process is simple:
attend your local Humungous State University in whatever major you like
get a job as an assistant in one of the campus computer labs
cultivate relationships with some of the faculty and staff
jump from the lab assistant position to a sysadmin position based on recommendations from faculty or staff
upon graduation either get hired directly by the department for which you were a student worker, or use your experience on you resume (or use your faculty contacts to find a job outside the universiy: many faculty have their own private sector contacts that they can tap for you, if you ask nicely).
You won't find that any of the available degree programs relate directly to system administraction, but the experience you can get at a good university, in terms of exposure to a wide range of computing platforms and familiarity with office politics, is invaluable.
You will also find that, after a certain point, you can't learn any more about the craft from books: you need to have mentors. Working as an assistant sysadmin in a university is an ideal way to get exposure to large pool of experienced sysadmins, many of who are more than willing to share their experience.
(Of course, the moral of the story is: It's not what you know, but who you know, that counts)
you could easily have a username generator that could either keep track of previously generated usernames (an ungainly solution) or construct the username based on some other key (employee ID, for example). the username segments would be selected from a dictionary constructed for the purpose (say a list of canimal and plant names).
My solution might look something like this (assuming that the employee ID is 6 digits long):
construct nine lists of plant and animal names, 10 names in each list, total of 90 names lists
select one plant list and one animal list using the first two digits of the ID
select a plant name using digit 3 of the ID
select an animal name using digit 4 of the ID
digit 5 is used directly in the username
use the final digit of the ID to determine how to combine the two names and the digit to form the username.
The resulting usernames (looking something like rose5dog or 3cowdaisy) will be reasonably memorable, guaranteed unique and moderately hard to guess by a dictionary attack.
If security is not a concern, however, I would go for the path of least user anoyance and let user's select their names with some feedback from the admin staff (in case the name is already in use or is, somehow, obviously offensive). I don't see any good reason why I shouldn't be able to have dutky or, at worst, jsdutky as my username (I can guarentee that I am the only J.S.Dutky on the planet, so what's the problem?)
I think you misspelled the word adequate. Even the best x86 PC hardware is far from decent: it doesn't have a real bootloader/monitor in ROM, it can't handle booting to anything but a small handful of archaic video modes (much less boot to a serial console) and it has all kinds of wierd kludgery in the essential hardware (gate A20 cruft, default unidriectional parallel ports, no standard on-board sound or ethernet, etc.). It is no suprise that you can get your PC stuff at a significant discount.
I will easily admit that you can't get the highest MHz CPU, or the flashiest video chipset, in a Mac, but you get better quality hardware at a comparable price to other name brand computers (if you are comparing an Apple to a machine you threw together from parts or bought from a parts-shop hole-in-the-wall, you probably haven't considered the warrantee price).
All of this said, I run a few x86 PCs at home, along side my Macs (the house is evenly split: 3 PCs, 3 PowerMacs, 1 Compaq LTE and 1 PowerBook) mostly because an x86 box was the best choice fo Linux until a few years ago (LinuxPPC is damn nice these days, though it lacks some support for some browser plug-ins). Still, I've always been frustrated by the things I can't do on a stock x86 PC that take no effort at all on a Mac.
The biggest downside of the Standard Template Library is that it isn't very standard. The support for templating, across a range of compilers, just isn't very consistant, which makes using the STL in a portable manner almost impossible. Aside from that, the STL is, to my mind, just another giant complex wart on top the mind-numbing complexity that is ANSI C++ itself.
As with OOP itself, generic programming is a Really Good Idea but its implementation in C++ leave something to be desired for simplicity and accessability. Due to C++'s dominance in the marketplace, the STL will likely be with us for many years, but this is far from a desirable circumstance.
Re:Actually, the UNIX market share is going down..
on
Unix Isn't Dead
·
· Score: 2
Unless you include the second hand systems being bought at auction from defunct dot-coms (or telecoms or energy trading firms, etc.). Honestly, why do pointy-haired folk think that short term statistics have any meaning whatsoever, especially when taken without any kind of context?
I'll worry about Sun and IBM if they can't increase their market share over a five year span. Pardon me if I don't get upset when their market share falls during a recession. (I'm perfectly happy, however, to proclaim the doom of SGI, whose market share has been falling for over half a decade)
a plethora of silent mouse buttons
on
No-click Mouse?
·
· Score: 3, Informative
one poster has pointed out the older Sun mice whose buttons make no sound. These are sun part number 370-1169-01 (for the type-3 version with a modified RJ-11 connector) or 370-1170-01 (for the type-4 with an 8-pin min-DIN connector), and were manufactured by MouseSystems. (Mouse Systems Corp. referred to these as part numbers 401162-529/A and 401162-035/D) Nice little three button optical (old style, requiring a reflective gridded mousing surface) mice. Unless you are using a Sun workstation with a type-3 or type-4 keyboard, you will have damn little hope of using these mice.
I seem to recall that Mouse Systems made simlar mice for other systems as well, including Macs and PCs, so you may have some luck finding an old Mouse Systems mouse with clickless buttons that will work with a relativly modern computer.
There are also a couple of PS/2 style mice from IBM that have silent buttons: both the standard wedge shaped PS/2 mouse (Model 6450350) and the Psersonal System/2® Mini-Mouse (Part No. 95F5443) have silent buttons, and can easily be used on any modern PC with a PS/2 mouse port. Both of these mice are simple opto-mechanical two button jobs, so anyone needing a multi-button or scroll-wheel fix is SOL.
Finally we have the early Microsoft Serial Mouse (FCC ID: C3K7PN 9939) with a 25-pin serial connector and buttons that curved over the front edge of the mouse. This mouse also had clickless buttons. Upon disassembly one finds that the buttons are simple dome microswitches, which must mean that you can get such microswitches in both clickfull and clickless versions. Again, this is a simple opto-mechanical two-button mouse.
The reason they are concerned about it being pirated, is because it is not the only board that will run OS4. The AmigaOne is a specification (known as 'Zico'). They have no monopoly on these boards, any company may make an "AmigaOne" board or machine if they like, and it will run AmigaOS 4 if it meets Zico specifications. Other companies might ship these boards without the OS.
Whether or not the board is designed to an open standard, the facts of the matter are that, at the moment, noone other than Eyetech seems to be producing the board. Further, since Eyetech doesn't own AmigaOS in the first place, they are hardly the best party to be safeguarding it from 'piracy'. I still think that their attempt to limit the audience for the A1G3se is myopic and pointless.
Apple can get away with this type of silliness only because they control both the hardware and operating system, giving them a monopoly in their niche. Eyetech has no similar advantage. By hobbling the A1G3se motherboard so it will only run AmigaOne's OS they are putting themselves at a grave disadvantage. Rather, Eyetech should keep the board as attractive as possible to the widest range of users while still meeting the 'Zico Specification'.
To all the folk whining about using this to build a non-Apple Mac: get over it and just buy a used iMac or B&W PowerMac G3!
Once you have put together an entire system based on this board, you will have spen nearly enough to buy a brand new iMac straight from Apple. Let's look at a parts-list:
eyetech motherboard & CPU (600 MHz G3) $500
compatible video card ~$125
256MB PC133 SDRAM ~$50
hard disk drive ~$125
keyboard & mouse ~$25
ATX case & power supply ~$40
DVD-ROM drive ~$50
monitor ~$150
speakers ~$15
total price ~$1100
While these numbers are approximate, I think I've been quite generous and estimated on the low side for most parts. You might be able to shave a bit more off the monitor or hard drive, but I'd bet that I'm within $50 either way on the total.
You can buy a used iMac for around $500 at any number of recycled computer shops, so even if you can reuse a bunch of stuff you have lying around, you aren't really ahead of the game, especially if you really want to get OS X running on the beast.
All that said, I think that it would be really nice to have a mass market PPC motherboard (and Eyetech's board looks pretty nice, as far as on-board peripherals and expansion options go) that you could run Linux on. It's too bad that they want to tie it to their proprietary OS (why are they concerned about people pirating the OS if it will only run on this PPC motherboard, anyway?). A nice, integrated, low-power system is just what I need to replace the aging 486 I use as a firewall.
Slashdot Mirror
Given this definition of an order of magnitude, we can see that CRTs are priced in the third order of magnitude, while LCDs are, except for the very best bargains, in the fourth order: one order of magnitude difference.
P.S., a cartoon I once saw in a lab at university, shows two scientists standing in front of a chalk board, one talking to the other, the caption reads: "It's within an order of magnitude, in other words it's completely wrong."
What a load of self-serving garbage.
For laptops of all stripes, not just Apple products, I think it is better to get everything from one source. It is much more difficult to do third party upgrades on laptops than on desktop machines and the upgrades don't tend to be as competitively priced.
That said, the current crop of Apple laptops seem to use standard memory components (both the current iBooks and PowerBook G4s use standard SO-DIMMs) and the hard drives have been 2.5" IDE drives ever since 1996 or so, so you can probably upgrade either the memory or hard drive from third parties for a much better price than Apple would offer.
As for how easy it is to work on the Apple laptops: they have been much easier to deal with than most PC laptops ever since the days of the PB1400 (back in '96 or '97) when Apple stated putting all the upgradable components directly under the flip-out keyboard. Things are still a bit cramped, but you don't need to dismantle the entire machine just to add memory.
My favorite with the current iBook is the smaller 12" model, just because it is a bit more compact than the 14" model. The 12", however, doesn't have as long a battery life as the 14", so you need to decide which is more important to you, size of battery life.
If I were in the market, I'd get the bottom of the line iBook with minimum memory. Then I'd immediately add extra memory from a third-party, but I would wait on the hard drive upgrade until I really needed it.
In general, the trick with buying Apple products isn't how to get the lowest price at the outset, but how to minimize total expenditure over the life of the system. This tends to mean buying a system that just meets your current needs and then upgrading piecemeal over the next 3 to 5 years.
Apple machines tend to last much longer than their PC counterparts, not because they are better built (though some are) but because they are better designed for expansion: The maximum memory limits on Apple devices tend to be higher than similar PCs and you can often upgrade the CPU without requiring a complete motherboard swap. This means that my 7 year old PowerMac 8500 is still a decent machine, with 768MB of RAM (and still room to expand), a $200 G3 CPU upgrade, a RAGE-128 video card, and a couple of SCSI hard disks.
Shop around before you buy. With Apples current attitude toward industry standard parts, you can, generally, use all sorts of commodity, over-the-counter parts that are labled for PCs (NOTE: video cards don't follow this rule. Niether do modems. For most other types of cards you can either find Mac drivers online, or you can download programs from the manuacturers to flash that card's ROM for Mac use. It is best to do some research before you buy)
Best by what measure? The ATI 7500 is a nice enough card (I use a RADEON 7000 PCI at home in B&W G3) but I'd prefer an 8500. It's a shame that Apple doesn't offer it. OTOH, the NVidia card does sound very nice. I don't know, what are you planning to use the machine for? Most applications, IMO, don't benefit too much from SMP, and the premium kills and 'sweet spot' opportunity. Still, it depends on your application. On a server, sure, but not for most desktop applications. Besides, you can always add a third-party SCSI card at a later date.Overall, my advice is to buy a middle of the line machine, skimp on memory directly from Apple (upgrade though a third party), possibly skimp on the hard drive as well (upgrade through a third party), get the best optical drive and video card Apple offers (software support is vital for both, so get them from Apple), and everything else is a toss-up. Buying middle of the line saves you some money, which is good since this is your first Mac: if you discover you don't like Apple products (not that I think that's likely to happen) you won't feel so bad about the money you spent. Once you are comfortable with Apple hardware, you can decide home much (or little) you want to spend on your next machine.
In general, unless there are compelling reasons to go for the top of the line, buying middle of the line is a good policy. When your machine is, inevitably, made obsolete, you won't feel so bad, since you weren't cutting edge to begin with. With Macs, you have the added advantage of, generally, being able to upgrade the system (new CPU, memory, disks, etc.) without needing an entirely new motherboard, so the middle of the line system will last longer than similar systems on the PC side.
Second, the shortcomings of CVS are not the issue. CVS is a version control tool, not a CM tool.
Third, I've never used ClearCase, so I don't know what features it has that may (or may not) be relevant to CM. However, unless you are the CM guy, it is likely that you never use any of the CM features of ClearCase. As a programmer, you don't really need to do anything other than version control, but that doesn't mean that version control is the only task that is important or that the tool supports.
One final time: CM is all about keeping track of exactly what versions of what files went into a specific build of a system (you may be shipping different builds of the system to different clients, for example), where those files are stored in a specific build, what was done to install the build on the client hardware and what environment variables/registry entries/symbols/logical names/etc. were set to what values for any specific installation. Much of this information can be (and often is) stored in the form of installation and configuration scripts that are kept under revision control. You may also want to associate user documentation, discrepency reports, enhancement requrests, work orders, and even client specifications or contracts with a specific build for a specific client. On top of all this you would like to have the information in a form that can be readily digested by humans (assorted install/configure scripts do not meet this requirement) so that new recruits and non-coders can understand what goes into the system and its installation.
To say that just becuase you have the installtion and configuration scripts in revision control, you are effectively managing the system configuration is like saying that just because you have been given the compiled executables, you have all the documentation you need to maintain and enhance the software! CM is not about the source code, but about the meta-data of the built and installed system. It tells you not only what you can tweak in the system, but also how that tweaking was done for a specific installation.
In summary, CM records the following facets of the system:
As for doing something wrong if it takes so much effort to get the code into a runnable state: you are probably correct. The sad fact is, however, that most large software projects are doing something wrong in exactly this way (many somethings, in fact), but there is little hope of being able to turn the tide.
Really large software projects are too big for even a large team of people to tackle every aspect of the system. Therefore, large projects must be built on top of smaller pieces, often pieces that have been built by other people. Each of these component pieces has its own fiobles and requirements, all of which combine to present the system architect with one giant mess of fiobles and requirements. The job of CM is to manage this mess of foibles and requirements in such a way that the system can be installed and operated without bankrupting the company in the process.
You can use a version control tool to keep track of this information, but it is a lot of work and is pretty hard to keep straight (keeping the install scripts in CVS is often confused for a CM solution, but it doesn't help when your old CM guy leaves and you need to bring the new CM guy up to speed on what goes where and why). The real purpose of CM is not simply to make it easy to install and configure the system, but to make it easy for humans to understand what that process entails and detect when something has been changed or overlooked.
Some folks might be forgiven for thinking that CM and version control are the same thing: if you have never worked on a real production system before (one with many programs and a complex set of directories and configuration files, as opposed to some little toy program for a class project) you have probably never encountered the need for CM. Unfortunately, there is almost no way to demonstrate the need for CM in the small: unless the size of the system is larger than what one person can comfortably think about at one time, the need for CM just doesn't arise.
Any protection scheme that relies on a single test point is child's play to circumvent. If you have code sequence like so:
can be trivially defeated by simply adding one jump:
now, insert your Z80 interpreter where the above code reads "<do some magic on the credentials>" and see how hard it is to defeat. Even liberally sprinkling your program with calls to the magic won't help, it just increases the number of times that cracker has to insert jumps into the machine code.
While C pointers are the bane of undergrads and junior programmers world wide, the resulting bugs are squashed quickly in production environments. Most of the big, hairy, bugs are both more mundane and more subtle: complex and misunderstood 'business logic', inadequately tested reporting and summarization routines, databases without any consitency checking, and incorrectly implemented multi-threaded systems.
Some of these problems can be laid at the feet of the implementation languages, but most of them are the fault of hasty, clumsy programming, regardless of language. Some can also be laid at the foot of the client/contractor interface: the client only has a vague idea of what they want, and the contractors are more interested in not antagonizing the client with too many questions than producing usable specs. Lets not even consider the problem of who to bill for properly maintaind developer documentation.
Weak inter-process communication isn't a problem, it's a feature! The best way to build reliable, maintainable systems is with loosely coupled processes that exchange data through simple file-like streams. Then, when something fails, you can remove the misbehaving part, without disrupting the rest of the system, and examine the intermediate files to diagnose the problem.
In fact, one of the worst culprits in the modern software rogues gallery is the database, precisely because it strengthens the coupling between all parts of the system. Sophisticated IPC tools, that make IPC look just like a function call, result in brittle, opaque systems that can't be easily maintained or diagnosed.
DMA and device drivers are only the concern of a very small fraction of programmers. Most of those programmers who do have to deal with such things, however, are well able to manage any of the resulting complexities.
I/O channels are nice, I admit, but their lack is not a fatal flaw. Perfectly stable systems can be built on simple interrupt or DMA driven architectures.
The lack of channelized hardware or an in-ROM micro-kernel is not why we don't have a comoditized OS on Intel PCs. In fact, we do have comoditized OS's: Linux, the BSDs, Solaris etc. are all adequate counter examples. However, Microsoft has managed to manipulate the market in order to marginalize any significant competition. The fault is entirely a political/economic one which cannot be addressed technologically.
If your school is making you write hundreds of lines of code, on an exam, and requiring that the code be ready to both compile and run flawlessly, I'd advise you to look for another school: first, the fact that the department seems to fixated on generating code in a particular language is a very bad sign. Computer science is not about coding, but about the theory and structure of programs and computation, none of which needs to be expressed in the kind of strict syntax required of real-world programming languages. Second, the fact that the department even thinks that anyone could write hundreds of lines of code in a couple hours and have any hope the code compiling correctly, much less working, is ridiculous and suggests that the department itself is less than top quality.
All of that said, when I was required to write real code on an exam, there was always some leeway for 'typos' (or whatever the equivalent is when you are writing with a pen, rather than typing at a keyboard). Most of the time, however, only psuedo-code was required. Even my computer architecture course, where we discussed scheduling of machine instructions, allowed the use of entirely hypothetical assembly languages on the exams.
You might also look at The New Turing Omnibus: 66 Excursions in Computer Science by A. K. Dewdney from W. H. Freeman & Co. (ISBN 0-8050-7166-0) which is a good source for important and interesting CS topics, though it may be more work to construct concrete projects.
Let's remember, not all bits are created equal. Each bit of information is, potentially, the answer to a single yes-or-no question, and some questions are far more important than others. Hence, some bits are worth far more than others.
Let's also remember, economists (at least free-market capitalists) will tell you that a thing is worth whatever you can get someone to pay for it. This means, of course, that value and worth are nonsensical terms and you can't ask any reasonable questions about them.
If, however, you are not a free-market capitalist, you might subscribe to the Marxist definition of value: that a thing aquires its value based on how much human effort was put into the thing. In that case, the value of access to a well used MMORPG account could be quite substantial (how much is your time worth, mine is worth quite a bit).
Finally, we must consider that even for a single bit, the two possible values (yes or no) do not always have equal worth: I would have been willing to pay far more for the yes result of the above function than for the no result. Something very similar is true for the MMORPG accounts (base on how well the account has been used).
Well, that's find for them, but it's of no help to me (who doesn't run Quake). Besides, what makes anyone think that frame-rates in Quake are primarily dependant on CPU speed? Maybe they are, but I suspect that AGP bandwidth and the polygon drawing rate of your video card are more important.
For what I use my x86 boxen for, SPECint and stream are pretty close to perfect benchmarks, and, I would think, for most users, the same benchmarks would be pretty good measures of the fitness of one CPU verses another. My real complaint isn't that Quake III isn't a usefull benchmark for some user's, but that it doesn't really measure CPU performance. You might as well tell me which machine rolls downhill faster or better survives a drop from the third floor.
The folks doing Quake III fps benchmarking aren't using it becuase it measures the anything important, but because it is the only tool they have: they are driving screws with a hammer. That wouldn't be such a bad thing, except for the fact that better benchmarks are readilly available. Why should I listen to someone who is clearly too ignorant to even choose appropriate tools?
Still, I'm eagerly awaiting the ClawHammer release. Every x86 box I've built for the last 5 years has been pure AMD, and I've been quite happy with them.
I used to work in the WAM and GLUE labs when I was an undergrad at UMCP, and the folks that managed the systems were pretty friendly, if you can get contact info for the current WAM sysadmins, they can probably give you better pointers. In the mean time, there is a page giving useage statistics for the WAM/GLUE cluster.
So, I'm a thief no matter what I do. Worse yet, I'm a thief even if I don't do anything. Nughty me for breathing their air! Next thing you know, it will be illegal to own a TV with an off switch. (que Mac Headroom)
- attend your local Humungous State University in whatever major you like
- get a job as an assistant in one of the campus computer labs
- cultivate relationships with some of the faculty and staff
- jump from the lab assistant position to a sysadmin position based on recommendations from faculty or staff
- upon graduation either get hired directly by the department for which you were a student worker, or use your experience on you resume (or use your faculty contacts to find a job outside the universiy: many faculty have their own private sector contacts that they can tap for you, if you ask nicely).
You won't find that any of the available degree programs relate directly to system administraction, but the experience you can get at a good university, in terms of exposure to a wide range of computing platforms and familiarity with office politics, is invaluable.You will also find that, after a certain point, you can't learn any more about the craft from books: you need to have mentors. Working as an assistant sysadmin in a university is an ideal way to get exposure to large pool of experienced sysadmins, many of who are more than willing to share their experience.
(Of course, the moral of the story is: It's not what you know, but who you know, that counts)
My solution might look something like this (assuming that the employee ID is 6 digits long):
- construct nine lists of plant and animal names, 10 names in each list, total of 90 names lists
- select one plant list and one animal list using the first two digits of the ID
- select a plant name using digit 3 of the ID
- select an animal name using digit 4 of the ID
- digit 5 is used directly in the username
- use the final digit of the ID to determine how to combine the two names and the digit to form the username.
The resulting usernames (looking something like rose5dog or 3cowdaisy ) will be reasonably memorable, guaranteed unique and moderately hard to guess by a dictionary attack.If security is not a concern, however, I would go for the path of least user anoyance and let user's select their names with some feedback from the admin staff (in case the name is already in use or is, somehow, obviously offensive). I don't see any good reason why I shouldn't be able to have dutky or, at worst, jsdutky as my username (I can guarentee that I am the only J.S.Dutky on the planet, so what's the problem?)
I think you misspelled the word adequate. Even the best x86 PC hardware is far from decent: it doesn't have a real bootloader/monitor in ROM, it can't handle booting to anything but a small handful of archaic video modes (much less boot to a serial console) and it has all kinds of wierd kludgery in the essential hardware (gate A20 cruft, default unidriectional parallel ports, no standard on-board sound or ethernet, etc.). It is no suprise that you can get your PC stuff at a significant discount.
I will easily admit that you can't get the highest MHz CPU, or the flashiest video chipset, in a Mac, but you get better quality hardware at a comparable price to other name brand computers (if you are comparing an Apple to a machine you threw together from parts or bought from a parts-shop hole-in-the-wall, you probably haven't considered the warrantee price).
All of this said, I run a few x86 PCs at home, along side my Macs (the house is evenly split: 3 PCs, 3 PowerMacs, 1 Compaq LTE and 1 PowerBook) mostly because an x86 box was the best choice fo Linux until a few years ago (LinuxPPC is damn nice these days, though it lacks some support for some browser plug-ins). Still, I've always been frustrated by the things I can't do on a stock x86 PC that take no effort at all on a Mac.
As with OOP itself, generic programming is a Really Good Idea but its implementation in C++ leave something to be desired for simplicity and accessability. Due to C++'s dominance in the marketplace, the STL will likely be with us for many years, but this is far from a desirable circumstance.
Unless you include the second hand systems being bought at auction from defunct dot-coms (or telecoms or energy trading firms, etc.). Honestly, why do pointy-haired folk think that short term statistics have any meaning whatsoever, especially when taken without any kind of context?
I'll worry about Sun and IBM if they can't increase their market share over a five year span. Pardon me if I don't get upset when their market share falls during a recession. (I'm perfectly happy, however, to proclaim the doom of SGI, whose market share has been falling for over half a decade)
I seem to recall that Mouse Systems made simlar mice for other systems as well, including Macs and PCs, so you may have some luck finding an old Mouse Systems mouse with clickless buttons that will work with a relativly modern computer.
There are also a couple of PS/2 style mice from IBM that have silent buttons: both the standard wedge shaped PS/2 mouse (Model 6450350) and the Psersonal System/2® Mini-Mouse (Part No. 95F5443) have silent buttons, and can easily be used on any modern PC with a PS/2 mouse port. Both of these mice are simple opto-mechanical two button jobs, so anyone needing a multi-button or scroll-wheel fix is SOL.
Finally we have the early Microsoft Serial Mouse (FCC ID: C3K7PN 9939) with a 25-pin serial connector and buttons that curved over the front edge of the mouse. This mouse also had clickless buttons. Upon disassembly one finds that the buttons are simple dome microswitches, which must mean that you can get such microswitches in both clickfull and clickless versions. Again, this is a simple opto-mechanical two-button mouse.
Damn, I wish I had your job! What kind of job title comes with those responsabilities (compiling a kernel and playing Civ3), anyhow?
Whether or not the board is designed to an open standard, the facts of the matter are that, at the moment, noone other than Eyetech seems to be producing the board. Further, since Eyetech doesn't own AmigaOS in the first place, they are hardly the best party to be safeguarding it from 'piracy'. I still think that their attempt to limit the audience for the A1G3se is myopic and pointless.
Apple can get away with this type of silliness only because they control both the hardware and operating system, giving them a monopoly in their niche. Eyetech has no similar advantage. By hobbling the A1G3se motherboard so it will only run AmigaOne's OS they are putting themselves at a grave disadvantage. Rather, Eyetech should keep the board as attractive as possible to the widest range of users while still meeting the 'Zico Specification'.
Once you have put together an entire system based on this board, you will have spen nearly enough to buy a brand new iMac straight from Apple. Let's look at a parts-list:
While these numbers are approximate, I think I've been quite generous and estimated on the low side for most parts. You might be able to shave a bit more off the monitor or hard drive, but I'd bet that I'm within $50 either way on the total.
You can buy a used iMac for around $500 at any number of recycled computer shops, so even if you can reuse a bunch of stuff you have lying around, you aren't really ahead of the game, especially if you really want to get OS X running on the beast.
All that said, I think that it would be really nice to have a mass market PPC motherboard (and Eyetech's board looks pretty nice, as far as on-board peripherals and expansion options go) that you could run Linux on. It's too bad that they want to tie it to their proprietary OS (why are they concerned about people pirating the OS if it will only run on this PPC motherboard, anyway?). A nice, integrated, low-power system is just what I need to replace the aging 486 I use as a firewall.