DHCP authentication as you described is a Microsoft extension to the standard and is not a part of any RFC that I am aware of. In point of fact, no non-Microsoft DHCP server implements this protocol and as a result, any other device that wants to broadcast DHCP packets can do so. The DHCP server on Mac OS X is really just a slightly modified version of the ISC reference implementation of bootpd. By design, you can set up the DHCP server on Mac OS X to respond to directory services request packets but not other types, such as IP address allocation requests, so that Mac OS X machines can pick up directory services information via DHCP and still interoperate with existing DHCP servers.
And, as you pointed out, any other device plugged into the network that can broadcast DHCP can cause the same chaos. Mac OS X makes it so that regular users without admin privileges cannot turn on DHCP, either on Mac OS X or Mac OS X Server. Keep non-technical users as non-admin users and you will never have the problem of DHCP interference.
I guess what I want is Linux or OS X to act like an Active Directory DC....to do all the things that Microsoft's AD-DC's do.
This gets to the core of your problems -- you have a VERY Microsoft-centric view of the world. Forcing authentication against a Microsoft-specific non-standard server protocol just because that's the way Microsoft does it is a really poor way of getting interoperability. Other systems have other ways of handling directory services and security -- look at them in their native environments and work with them, don't treat every problem as a nail just because all you have right now is a hammer.
This list consists of items that are irrelevant or unnecessary:
Can you add users to OS X and have them appear in Active directory?
The point of a central directory service is that you create the user records in one place (using the native tools) and all systems can authenticate against them. Adding users to your Mac OS X machine doesn't make sense under centralized directory services. With the correct administrative user login, it is possible for Workgroup Manager to edit user records in an LDAP server using LDAP v3 mechanisms.
Can you get your DHCP server (on OS X) to authenticate itself in Active Directory?
DHCP does not by nature authenticate. DHCP servers can send out additional vendor-specific DCHP packets -- Apple's implementation does this to tell Mac OS X clients where to look for directory services -- but they do not authenticate directly to DHCP. These additional records are ignored by systems that don't understand them. Look into the Mac OS X Server documentation and the/Applications/Utilities/Directory Access application to see the options.
Can you get user lists and permissions to replicate into OS X's user list?
The point of central directory services is to NOT have everything replicate into client systems!:-O When a Mac OS X system that utilizes LDAP directory services for group information it asks the LDAP server, not its own local NetInfo database or BSD-style config files.
Lastly...can you get a user to log into OS X and have OS X process login scripts replicated to domain controllers? Doubtful...most of the windows login scripts don't apply to the Unix world.
You've answered your own question here -- the Windows-based login scripts do not make sense and would not run under Mac OS X. Mac OS X has its own ways of setting up scripts to be run on boot and on login, as well as automatically mounting share points.
Scripts can be run from the/etc/rc scripts or from the/Library/StartupItems folder. On login, there are a variety of options detailed in Apple's docs.
Well, this really is a time warp -- Apple was looking at this before as well. This sort of experience was the intent of the OpenDoc system, which was a document-oriented way of running apps. You could embed documents within documents, based on a file structure called Bento, named after the Japanese-style stacking boxes. It was cross-platform (Mac and Windows) and you could even embed ActiveX content inside an OpenDoc container.
A definitely cool piece of technology, but it ended up on the cutting room floor when Apple was in dire financial straits. It was also too heavy-weight a technology for the personal computers of the day, since everything was basically a CORBA object, which are relatively slow even on honking big servers.
With MacOS X and the underlying Mach microkernel for message passing, OpenDoc or something like it starts to look more feasible for the desktop from a technological perspective. However, from a marketing standpoint, the companies that put together office software suites have a distinct incentive to make their products NOT interoperate in this fashion, since it helps to lock the user into a single suite.
I found Ann Landers to be OK, but the Washington Post (my local paper) replaced her with Dear Abby (Iguess they had to), whom I've found to be vapid and flat. Thank heavens for a local (but also syndicated and more power to her!) alternative. Carolyn Hax writes the Tell Me About It advice column. It's advice with a hip, edgy attitude, along with some kewl comics to go with it.
Apple provides for-fee technical training that covers this and other very useful topics. The courses are generally a week long and involve instructor-led, hands-on training in setting up a network with Mac OS X and Mac OS X Server. IMNSH (and quite biased 'cause I helped write it!:-) O, the training is good stuff, meaty and chock full of technical information. Almost everyone who goes through these courses says something like, "Wow, that's a lot of good, useful information."
We're working on the revisions for Jaguar right now, and expect to go live with the first course deliveries in a month or so. Go to the Apple Training website for more information.
--Paul
Paul Suh Curriculum Developer Apple Technical Training (Help me keep my job! Buy training from Apple!:-)
AppleScript is great, but the app that you are testing must be scriptable. Many are today, but some are not. Furthermore, in this situation you want to test the GUI, not just the underlying object model which is what AppleScript talks to.
However, AppleScript is not the only scripting environment for the Mac. Underlying all of the native scripting languages on the Mac is something called the Open Scripting Architecture. This allows any OSA component (i.e. scripting language) to talk to any other OSA component.
One OSA component is QuicKeys, a great product that actually does simulate mouse clicks, keystrokes, etc., and is completely scriptable. It integrates completely with AppleScript and via the power of the OSA, with shell scripts and Perl as well.
On top of this, Apple provides a powerful GUI building tool for AppleScript called AppleScript Studio, which is free. Plus, AppleScripts can talk across a network to do RPC. Imagine, you can have an AppleScript Studio front end that drives scripts on a set of machines over the network (so that you can assess performance under load). The individual scripts rely on AppleScript to drive the logic while using QuicKeys sequences to drive the GUI.
The only issue here is how easily you can assess results. There's no general way to check what the GUI is showing other than a pair of Mark I mod 0 eyeballs, since grabbing data out of the app being tested (even simulating a copy-paste) only talks to the underlying data structures and does not address GUI bugs. A possible way is to arrange the windows in a known manner, turn off the menu bar clock, take a screen shot, and use a graphical comparison tool to XOR the bitmap with a known good screen shot to highlight differences, but this won't work if you're working with variable or randomly generated data.
Disclaimer: I work for Apple, but these are my opinions only and do not represent any sort of official endorsement.
Whatever systems you look at, keep an eye on maintenance costs and costs of down time. It looks like you're going to load your own custom OS -- Linux variant, *BSD, maybe something else. However, your time is valuable -- make sure that the the boxen that you buy support a rapid way of loading the OS. E.g., stick in a CD and everything happens automatically.
Down the road, look at the expected costs if one of these puppies fails. Depending on your expected costs (e.g., one element of a computing farm fails just before a 30 hour computation finishes, making all of the others freeze and loose their results in turn), you may want to go for a more expensive commercial 1U or blade server that uses better quality components or has redundant components.
Lastly, look to see how these can be mounted for easy access. At some point the whole mess of them will need to be upgraded or have their OS updated, and having them in easy access racks will be much less costly.
I'm partial to Apple's XServe, but then again I work for Apple;-)
Good luck and let us know what you choose in the end.
Take it from some folks who've been there and done that -- in a much smaller way and have nevertheless gone through a lot of pain.
For the transition from WebObjects 4.5 to WebObjects 5.0, the developers at Apple created a converter that transforms Objective-C source code to Java source code. This was done by parsing the Objective-C source, creating a parse tree, and then running scripts against the parse tree. Simple pattern matching was found to be inadequate.
This was a much smaller project than the one that you seem to be involved in. Why? First off, as computer languages go Objective-C and Java are very, very close in terms of structure and design. Second, even with the talent involved in this project -- whom I am completely in awe of -- they only created an 80% solution. The goal was to produce something that could get a developer well down the road on the way to a conversion, not do the entire conversion.
Then, the Apple engineers tested this tool in the harshest environment possible -- their own code. It was used to convert the entire WebObjects source code from Objective-C to Java; they made it work before releasing it to customers.
Management needs to take a step back and ask, "what the heck are we trying to do here, anyway?" Unfortunately, it sounds a lot like your management has their heads 'way up in the wrong place. A useful piece that I read recently is the Happy Valley Tax Authority case study. <HINT>Consider yourself lucky that your resume is relatively current.</HINT>
--Paul
The Unix Guide to Defenestration
on
Buying Unix?
·
· Score: 2
Definitely check this book out at its author's site. Plus the links to other articles that Murph has written for LinuxWorld on how to swap out costly and unproductive Windows setups for Unix-driven systems. I don't agree with him 100%, but he's got a lot of useful insights.
Use common uid's for the laptop local users vs. the network directory services users. I do this myself across three domains: Apple's NetInfo network, my own NetInfo network at home, and my TiBook's local NetInfo domain.
This response is dead on. The original asker needs a file server that speaks multiple protocols. Once you have a server, it is much easier to create the necessary ssh or ssl tunnels that you need for total security.
Trying to maintain coherency of data via replication across multiple machines is begging for trouble -- this is a hard problem that to my knowledge has not been solved in a clean, cheap way.
If you want to use NetInfo for Mac OS X, create a new port from the Open Darwin sources. There's a port of an old NetInfo server module for Linux floating around, but it's not what I'd call up to date.
A better choice would be to use OpenLDAP, as Mac OS X is designed to pull directory service info from an LDAP data source. Windows systems can also pull from a LDAP, as can Linux and *BSD and Solaris and so on.
First, my credentials: I'm a Curriculum Developer with Apple's WorldWide Training and Communications group. I am the author of the Network Security chapter in Apple's Network Administration course. I gave a talk at the last MacWorld on Mac OS X firewalling, and I must have done something right since they asked me to do it again in July in New York. In this post, unlike most of my other postings, I am speaking in my Apple voice.
That said, Mac OS X has a root user, but root does not have a valid password on installation. The first user that is created via the setup assistant is what is known as an admin user. These are users who are members of the group "admin", a predefined group. Apple provides an API whereby a GUI application can ask for an admin user's password, and thus gain sudo-style privileges for actions such as installing software (which might need to put things in places that can only be touched by root). Also, the/Applications directory also is writable by admin users, so apps where the install is just drag and drop (such as OmniWeb or MSOffice) can also be installed by an admin user and do not require root privileges.
In addition, admin users have access to the/Library directory, which is where resources specific to a particular machine should be stored. There are four Library locations that Mac OS X searches for resources such as fonts and frameworks:
~/Library - for user-specific items
/Network/Library - for resources made available to an entire NetInfo network
/Library - for resources specific to a particular machine
/System/Library - the base system installation; this area is in general reserved for Apple use, and most people have no need to change anything inside here.
Note that the/Library tree in general has ownership root:admin with privileges 775. This means that any admin user can add or remove resources from his or her own machine without resorting to using root directly. In fact, if you wanted to add a set of resources that would affect only a particular user (say, give only the graphic artist access to the full set of 300 fonts, and leave everyone else with just the usual system set of fonts), you could install them under the user's ~/Library directory. Because of the default search order, resources in ~/Library and/Library take precedence over those in/System/Library, so you can simply install a framework in/Library and override the OS's default behavior.
If a user were to log in as root, he or she would immediately gain write access to the/System/Library area, which contains the really sensitive bits of the operating system. As it were on the warning labels, "No user serviceable parts inside!" Logging in as root is the equivalent of unscrewing the cover of a piece of equipment with that warning label. If you know what you're doing and you're careful, you may be able to do something in there, but if you're not careful or don't know what you're doing, you are likely to get hurt. I know of several users who had the bad habit of looking at a bunch of files in their System Folders and thinking, "I don't know what this does, I can just throw it out to gain more disk space," in older versions of the Mac OS. Turning one of these guys loose as root on Mac OS X is likely to cause major headaches.
From the command line side of the house, admin users are allowed to do anything via the sudo command, which is preinstalled on Mac OS X. If you need root access, you can use sudo to do just about anything from the command line. If you really, really need a root shell, you can always do "sudo -s" and get one.
In summary: Mac OS X has the tools that you need to perform system administration tasks form either the GUI side or the command line side without needing to log in as root. Logging in as root is the equivalent of opening up a piece of machinery with the warning label, "No user serviceable parts inside", and you should not be surprised if you get hurt when you do this.
Paul Suh psuh@apple.dontbotherspammingmeigetwaytoomuch alrea dy.com
Note: on Mac OS X Server, root is enabled by default. This is considered less of an issue since it is expected that servers will be run by people who have a better understanding of the issues involved and are more likely to be doing things that need root access, even from the GUI level.
MacCentral has run a bunch of Forward Migration Kits for different industries. They ran one about medical management software about two years ago -- kinda dated, but it should give you a starting point:
Re:Flash + Right Mouse Button + Kid = Frustrated K
on
How Kids Use the Web
·
· Score: 1
One mouse button? Macintosh! Ever wonder why the Mac is so successful in K-12?
--Paul
Check out the Ars Technica article
on
AltiVec Unwrapped
·
· Score: 2, Informative
Ars Technica did an article comparing the AltiVec and SSE/MMX2/3DNow! architectures. Written a while back, but still valid as the architectures have not changed.
Most of the climate control units -- and you really need to think in terms of humidity as well as temperature -- are very noisy. Don't put someone at the desk on any kind of extended basis (>1 day) or he or she is likely to go postal. Noise cancelling headphones may help, but these sorts of rooms are not in general fit for extended human habitation.
A regular telephone with a speakerphone and a l-o-o-ng cord and possibly a headset is also a good idea for calls to various tech support lines.
You really need to check out the Enterprise Objects Framework layer of WebObjects. You can use this in a web app or in a Cocoa app. It's an object persistence framework that talks to a variety of databases -- support for Oracle, MS SQL Server 7, and and MySQL is built in, FrontBase and OpenBase are excellent Mac OS X native relational databases, and it basically should work with any database that has as JDBC 2 type 4 driver available. EOF has been around since the NeXT days and is a rock-solid, mature database access technology. ADO by comparison is a complete wannabe.
Also, check out the recently released dual 1 GHZ G4 2U rackmount server from yellow dog linux's developer, Terra Soft Solutions.
--Paul
Quote: Apple has an easy to use data access framework a la ADO.net (with Postgres support): Rack mounted OS X application & database servers
OK, I have moderator prvis, but I just browsed all 141 comments at 1 or above and didn't find the following stated anywhere. I have a an ABD in Economics (just missed finishing a Ph.D.) so I know of what I speak.
This sort of attitude towards labor -- that the demand for labor is a zero-sum game and that an increase in productivity will inevitably lead to people being thrown out of work and/or the vast majority of laborers having their wages reduced since less labor is needed -- is prevalent in a leftist fringe of economists, predominantly based in Europe (Note that Beck is based in Munich, Germany). It is widely rejected in North America, the United Kingdom, the Far East, and South Asia.
It also ignores basic equilibrium analysis from Econ 101. You can approach it from two angles:
1) Companies will rather fire people than reduce wages. You are left with a pool of unemployed people who are otherwise idle and earning zero. If even one of those people has a little bit of savings and an iota of entrepreneurial bent, a new business can be started up, utilizing the otherwise idle labor (who will be willing to work for any wage above zero, since that's what they're getting now and starving). This pool of idle resources allows the economy as a whole to grow and evolve.
2) Wages are reduced, but employment is held constant. The analysis here is a bit more complex, but not too difficult. A company will undertake a project if the profit is higher than the cost of the project. Since wages have just fallen, there are now more projects that can be profitably undertaken, and companies will attempt to hire labor in order to staff these projects. In the process, wages will be bid back up again to equilibrium levels, only now the amount of output is higher than before. Unless you can posit that this output is consumed solely to company owners, workers are also better off in the final equilibrium.
So what actually happens? The total output of the economy rises. Workers and company owners are better off -- remember, it's consumption that counts in the end, not wages -- since there is more stuff to consume in the end. (Also remember that savings/investment/borrowing/lending is simply a transfer of consumption to or from the future.)
This is not to trivialize the pain and uncertainty that people are feeling due to the loss of jobs or job security, but the fact is that these kinds of dislocations are what make economies grow. Read up on Schumpeter's "creative destruction" in any basic macroeconomics text for a more mainstream view on the situation. Also note that any attempt at differentiating between low- and high-skilled workers or applying an international trade angle does not invalidate the basic analysis, it just hangs bells and whistles on it.
Lastly, this European-biased analysis completely ignores an important fact of life in the United States today. The unasked question is, "who owns the companies?" In Europe, stock ownership tends to be highly concentrated, with many companies controlled by a small number of people. Information disclosure requirements are also very lax compared to the U.S. or U.K. exchanges. In contrast, in the U.S. the majority of people own some common stock, either directly or via a mutual fund or retirement plan. Any increase in corporate profits directly benefits the majority of people.
SOAPBOX
The problem lies not in the U.S.-style open, flexible economic structure, but in the European-style stagnant, inflexible structure as influenced by Beck's brand of economic drivel. Note that in continental Europe, unemployment rates of 10% or more are common, and economic growth has been much lower than in the U.S. for the past two decades. The French have legislated a 35 hour workweek in an attempt to raise wages, thus shooting themselves in the foot -- how are things supposed to get better if the quantity of productive resources within the country are reduced? This whole line of left-leaning pseudo-analysis is discredited by not only theoretical analysis but also by the observed results.
/SOAPBOX
* A lot of interaction with the customer
* A good feel for what competitors in that market can offer
* A good feel for the corporate culture & existing systems in the company your selling too
These things are very hard to achieve if the design team is half a world away - the cycle times are just too long and to make a good product/system you need a lot of interaction with your customer.
It's a lot harder to deal with than just separating the design vs. coding teams. I've architected and coded several enterprise-class custom web applications, and the biggest problem is always that the customer doesn't really know what they want. This is what leads to part of the Extreme Programming paradigm, that part about very rapid (1 to 3 week) design and review cycles. You talk to the customer, you build a first prototype, get feedback, code some more, etc. Eventually, you home in on what the customer really needs.
Taking this offshore is a very difficult proposition. Working with a customer over a phone line or at best a videoconference link is an order of magnitude harder than getting everyone in a conference room, test driving your latest product, then brainstorming on a white board as to what's good and what's bad.
The only possible way this can work with an overseas coding shop is if you just have the architect or designer show up at the customer, and rely on him or her to write the spec for the coders. Even so, there's a lot in terms of the customer's intent that gets lost in the transmission even if the point guy is a phenomenal communicator.
Furthermore, it's hard for the architect to know exactly what questions the coders have for the customer. I make it a point to bring along the junior coders to project reviews if the customer is local. (And for me, a lot of them are. YMMV) This serves two very useful purposes -- it lets them ask questions and especially followup questions to the customer directly, and it starts to introduce them to how you handle customer relations as part of their professional development. If the customer is remote, I still make an effort to bring along at least one of the other coders to some of the project meetings.
All of this assumes that the overseas shop is willing to work with a XP-style development process. I can't claim any extensive familiarity with the general mass of overseas development shops, but the two that I have dealt with were very big on having a detailed spec up front, so that they could estimate their own costs. They were willing to hold weekly project reviews, but these were aimed at how well they were writing to the spec, not changes to the spec to fit new discoveries.
Repetitive tasks with fixed APIs, and exact ports of existing projects to new programming language/platform/etc -- these I can see being done effectively using an overseas programming shop. Writing a new application or adding new functionality to an existing one? No way. There are less painful ways to run a death march project.
Most people seem to be talking about OO and engineering in the abstract, so I thought I'd add some facts from a real-world case study. (* ducks out of the way as screaming./'ers flee for the exits;-) *)
When I was a Senior Economist with the Law and Economics Consulting Group, I worked on an electricity deregulation project. We had to model the electricity market, including the flows from sellers to buyers and constraints on the flows. Individual generating plants had run rate upper and lower bounds, and there were varying loads depending on time of day and time of year.
This was modelled by using the following main classes: electricity generating plants, utility companies, and transmission lines, plus some minor helpers. Each electricity generating plant had its own capacity and marginal cost of operation, and there were various sub-classes of generating plant for the different types: coal-fired, gas-fired, gas turbine, hydro, each of which had different characteristics; e.g. hydro plants had lower capacities in autumn than in the spring. Transactions between utilities were modelled as another sub-class of generating plant, whose capacity was the amount of the transaction and whose cost to run was the price of the electricity sale. All of this was subject to the transmission constraints between nodes.
Utility companies had loads that they needed to supply, either using their own generation capacity or by purchased power. They would attempt to reduce the cost of supplying their loads by purchasing electricity on the open market instead of running their own plants. They would also attempt to generate additional profits by selling electricity to other utilities whose costs were higher. The market was run via multiple rounds of bidding, until the cost of electricity in all of the different areas had stabilized. There was a special case (although in the programming world no sub-class was needed) of energy marketing companies, e.g. Enron, which had no native loads that must be supplied but which did own generating plants.
So you say, OK, why is this an engineering problem? Isn't it an economics problem? Well, it is in fact a superset of the engineering problem. In fact, there were several software packages that we investigated that -- given the operating characteristics of the plants, the transmission constraints, and the loads to be supplied -- would calculate the most cost-efficient combination of generators that could supply that load. However, none of these would have given us any insight into the necessary market interactions that would happen under deregulation. Writing our own model in C++ using OO methods enabled us not only to solve the engineering problem of supplying electricity to the region, but also to study the way that the companies would behave in a deregulated environment.
Why bother with fans at all? There are two fully-functional desktop personal computers out there today that you can go out and plunk down cash, credit card, or check with two forms of ID and take home right away. You can install Linux or *BSD on them, or use the vendor's pre-installed OS. In two months, the vendor is going to release a new, Unix-based BSD 4.4-compatible operating system that will be pre-installed on all of the machines come the summer.
What am I talking about? The iMac and the Cube, both by Apple. Both are completely convection cooled, and the only sound you hear is the clicking of the hard drive (and the sound of the other poor bozos getting fragged in Q3A;-) Check it out at Apple's iMac page and Apple's Cube page.
OK, so I work for Apple, but c'mon folks, do the design right and you don't need a fan!
...but the people who have been promoting electricity deregulation have been treating it as such.
Some background here: I am A.B.D. in Economics from the University of Pennsylvania, and worked for several years as a consulting economist as a part of a team providing expert witness testimony on a variety of cases. One of the things that I researched was the market for electricity in Texas.
We eventually wrote a large simulation model to handle how the market would clear in Texas, to determine if there would be times when a single utility company or power marketer might be able to corner the market and behave as a monopolist. Although there are excellent engineering models of how generating plants should be allocated to produce the lowest-cost combination that will supply a set of reginal demands, these are not necessarily applicable in a deregulated environment.
There is a fundamental theorem in economics that states that if you can find an efficient allocation of resources in a system through a command-style solution (such as an engineering model), you can de-centralize the system and still achieve the same result by choosing an appropriate set of initial allocations and initial prices. In other words, any efficient solution can be achieved by a free market. But, this is all subject to several technical conditions; if one of the conditions is violated, then the theorem can no longer be applied. In the U.S. economy today, those conditions are satisfied by most industries, which is why the free market works in general.
However, the electric industry is not one of them. The particular violation is in the requirement for smooth, continuous supply curves. If there are gaps in the supply curve or there are places where the supply curve has a sharp kink in it, the theorem does not apply, and there is a real danger that the market may not achieve a stable equilibrium. For electricity, the problem lies in the way that generating plants run: you can't just turn them on or off. Many plants have a narrow range of outputs -- e.g. a particular plant may be able to function between 40% and 100% of capacity or it can operate at 0% of capacity, but it physically cannot operate between 1% and 39% of capacity. Thus, a 500 MW plant might be able to supply between 200 MW and 500 MW of power, but it cannot supply only 100 MW of power.
This leads to kinks (and non-convexities) in the supply curve, which create opportunities for electric utility companies to act as monopolists and jack up prices -- and the usual constraining effects of the market may not apply. For example, suppose one company has a large 500 MW generator as described above which can supply electricity cheaply, and another company has a smaller generator that can supply between 0 MW and 300 MW of electricity, but at a more expensive price. If there is a demand for an additional 100 MW of electricity, the market will not be able to steer the demand to the low-cost generator, but must instead send the demand to the more expensive second utility, which can jack up the price as high as it wants without fear of competition. In contrast, an engineering model would allow the system operator to tell some other generating plant to cut back its output by 100 MW, so that the cheaper plant could run at its 200 MW minimum capacity and reduce the cost overall.
I have read some of the testimony concerning electric power deregulation, including that which was presented in California, and this key point has been ignored, as it is an inconvenience to the utility companies who paid for most of the testimony. While I have attempted to keep my explanation here simple, the above is in fact based on solid, academic-level theoretical economic research, and I will happily send out my working paper on this on request. It's still pretty rough, but I hopes of sending it in to a peer-reviewed journal some day. Anyway, back to doing WebObjects.
OK, I have moderator privs right now, but this thread is just too tempting to not jump into!
1) Given the architecture of X Windows, you must have a an X server running on your machine. Even local X Windows apps run by connecting to a local X server. Just compiling an Xlib will not give you much in the way of speed gains -- loopback calls under the OS X's network architecture are very cheap (heck, this is true for most OS's).
The relatively expensive part of the X Windows architecture (in terms of speed and resources) is the context switch that is necessary in this whole set-up: server process picks up mouse click and sends to client, client processes mouse click and sends display commands back to server, server processes display commands and puts them back onto the screen. Any mouse click requires at least two context switches (server to client, client to server), which are expensive under some OS's (MS WinNT/2K, Classic Mac OS). However, under the Mac OS X kernel, and indeed on most Unices, context switches are fast and cheap, so this is not much of a performance hit. (This is why Apache on Unix runs multiple processes, but is a single multi-threaded process on WinNT/2K.)
Pushing the server-side functions into the client-side Xlib would only really save the cost of the loopback overhead plus the context switches, both of which are cheap in Mac OS X (and other Unices). Only on a Windows- or Classic MacOS-based system does it make sense to try and cut out the context switches.
2) The X Windows server does in fact translate X calls into native Mac OS X calls. The implementation referenced above does it through the VNC application, which is extremely slow due to the massive number of layers involved -- one or two context switches are not so bad, but it looks to me that they're going through four or five. If you look at the Mac OS X graphics architecture, there is a lightweight graphics server underneath it all called Core Graphics Services, which is responsible for all drawing on the screen. Aqua, QuickTime, OpenGL, and QuickDraw all hook into this layer to do their actual drawing to the screen. It is possible (I don't claim it's easy, but it shouldn't be that hard) to write an X server that hooks in directly above the Core Graphics Services layer to translate X Windows calls to native, low-level CGS calls. This would make X Windows just as fast as the native libraries (aside from bottlenecks that might be inherent to X Windows) and allow for interleaved X and native windows on the screen. This is the Right Way To Do It (tm).:-)
Disclaimer: I am an Apple employee, but these views are my own and not based on anything that is Apple Confidential. I work with WebObjects as part of Apple iServices, which is a bit away from the core Mac OS X dev teams.
Having worked on a number of large-scale software projects, I will unequivocally state that not having written requirements is just begging for trouble. Or, what is worse, having a written requirements document that is vague in one or more critical areas -- which gives you a false sense of security.
I would divide software projects into three categories:
Mass-market software
Custom software developed for a specific customer
Tweak-ware
Software aimed at a mass market of many customers faces the problem that each of them has his or her own specific needs. The software engineering tradeoff here is development time and money versus how many customers really want/need feature X. Secondary factors are how much this contributes to code bloat, slow speed, and more bugs. Open source software faces these questions, but the answers are a little bit different relative to a commercial environment. Many users of the software may want/need feature X, but if none of them are coders and thus can't contribute directly to the work on the feature, it won't get done. (I admit that the more people want something, the more likely it is that one of them can/will contribute code to the project, but this is a second order effect.) As a result, if the core team does not set up at least a semi-formal requirements process, feature X will never make it into the project and down the road, users may stop using the software due to the lack of such a feature, leaving the project to slowly wither away. Alternatively, without a written rquirements process which the user base may respond to, the core team may spend a lot of time and effort on a feature that is relatively unimportant to the vast majority of users.
Software written for a specific customer also needs a requirements process, as in my experience three-fourths of the problem is that the customer doesn't really know what is really needed. As a case in point, I spent about three weeks working with a client on a web-based log-in process. I spent a week or so reviewing the current state of things, which was that they had gone ahead and done six months worth of development without a real requirements document. Guess what I found? A critical part of the log-in process was gathering user information so that they could decide which sales rep should follow up on this customer contact, but they had not yet decided whether this should be handled on a geographic basis or a product-line basis, and depending on which way things went, they wanted to ask different survey questions and have the user information sent to different people. After another two weeks of feeding-time-at-the-zoo meetings, we pulled the plug on our involvement with this until they straightened out the requirements. Open source software doesn't face this as much, but even so, there can be considerable friction within a OSS project's core team if the requirements are not written down so that they are clear. The result can be acrimonious exchanges and even splits among the development team, creating bad blood that didn't need to be.
Tweak-ware is possibly the only place that might not need a written requirements set, IMHO. This is a piece of software written by a programmer for his or her own use, with little expectation that it will become something used by many people. In this case, what's in the coder's head will suffice, as you know what you want. However, I would argue that the formal process of writing it down in English (or other non-computer language of your choice) is a great aid to clarifying your thinking on the subject. (My background is in Economics, and the worst professional insult you can say about an economist is, "Oh, him? He's a hand-waver," meaning that he doesn't write down his work in a formal paper that can be properly peer-reviewed and analyzed, but just stands at the front of a seminar room and waves his hands before a blackboard. You can get away with a great deal of vagueness waving your hands in front of blackboard that just won't fly when you write it down on paper.)
There's a huge difference between an Associate (2 year) degree from a community college and someone with a Master's-level or Doctoral-level education. It has to do with how well these people are trained with respect to formal analysis of problems. At the undergraduate level, the courses are focussed on transferring specific knowledge already accumulated by others to the student, who is then able to use the knowledge to solve problems. At the graduate level, the emphasis is on learning how to formalize new knowledge so that it can be passed on to others.
This difference shows up when you hire a someone to work on a problem. People with an Associate's degree (or no degree) and several years of work experience on average will tend to focus more on solving the immediate problem, rather than looking for the larger patterns that may be present. This translates in poorer application designs and a poorer understanding of what existing libraries can do for you. Note that I said on average -- there are always standouts who will succeed because of their natural inclinations and abilities, with or without a degree. However, I don't think that any of us can make the assumption that we are among those standouts at the tender age of 17 or 18.
Another way to look at this is signalling theory, a branch of economics. People signal to employers about their abilities and talents by choosing the amount of education that they undertake. For a naturally dumb person, school is difficult (i.e. costly) compared to the rewards that she will gain down the road; as a result, she opts for less formal schooling and goes directly into the work force. For a naturally smart person, school is relatively easy (i.e. cheap) compared to the rewards that come from the advanced degree, so she goes to college and grad school, rather than going directly into the work force. Employers recognize this, and are willing to pay more for a college grad than a high school grad with four years' work experience. This scenario holds true even if you make the assumption that the amount of knowledge gained in the four years working is the equivalent of the four years in college, as the degree is a visible signal as to the type of person being hired (dumb or smart). (As an aside, I seriously doubt that four years of work experience in an entry-level job are even close to the equivalent of four years of college -- at that level there's just too much grunt work to really learn much.)
The same dynamic is at work here as in other industries -- don't think that computing is all that special. Really smart people whose minds can analyze a problem in depth are much more valuable to an employer. The easiest way to get those people is to observe the signal from the formal education. It does not matter that a specific individual without a college degree is better-suited to the job that another individual with a college degree -- if on average the people with degrees are more productive than the those without to a significant degree, this is a useful screening tool for an employer.
In fact, in this industry there are some degrees that I feel are negative indicators: such things as an MCSE without a college degree to back it up, or an Associates degree in Computer Science from a community college. These degrees are much too easy to earn and sound good to people whose sole purpose is to "get into the field". To me, they are not what a real professional will emphasize as educational background, and are only useful for resume padding.
Beyond this, another factor that most people coming straight out of high school miss when thinking about college is the importance of alumni and school networks. Of the four jobs that I have had since I got my Bachelor's, two were the direct result of alumni contacts and one was the result of a professor recommending me to a colleague. It is one whole helluva lot easier to find a job this way that randomly sending out resumes to want ads, and the jobs are generally better, too. By not going to college, you miss out on this tremendously valuable support structure.
Slashdot Mirror
DHCP authentication as you described is a Microsoft extension to the standard and is not a part of any RFC that I am aware of. In point of fact, no non-Microsoft DHCP server implements this protocol and as a result, any other device that wants to broadcast DHCP packets can do so. The DHCP server on Mac OS X is really just a slightly modified version of the ISC reference implementation of bootpd. By design, you can set up the DHCP server on Mac OS X to respond to directory services request packets but not other types, such as IP address allocation requests, so that Mac OS X machines can pick up directory services information via DHCP and still interoperate with existing DHCP servers.
And, as you pointed out, any other device plugged into the network that can broadcast DHCP can cause the same chaos. Mac OS X makes it so that regular users without admin privileges cannot turn on DHCP, either on Mac OS X or Mac OS X Server. Keep non-technical users as non-admin users and you will never have the problem of DHCP interference.
I guess what I want is Linux or OS X to act like an Active Directory DC....to do all the things that Microsoft's AD-DC's do.
This gets to the core of your problems -- you have a VERY Microsoft-centric view of the world. Forcing authentication against a Microsoft-specific non-standard server protocol just because that's the way Microsoft does it is a really poor way of getting interoperability. Other systems have other ways of handling directory services and security -- look at them in their native environments and work with them, don't treat every problem as a nail just because all you have right now is a hammer.
--Paul
This list consists of items that are irrelevant or unnecessary:
/Applications/Utilities/Directory Access application to see the options.
:-O When a Mac OS X system that utilizes LDAP directory services for group information it asks the LDAP server, not its own local NetInfo database or BSD-style config files.
/etc/rc scripts or from the /Library/StartupItems folder. On login, there are a variety of options detailed in Apple's docs.
Can you add users to OS X and have them appear in Active directory?
The point of a central directory service is that you create the user records in one place (using the native tools) and all systems can authenticate against them. Adding users to your Mac OS X machine doesn't make sense under centralized directory services. With the correct administrative user login, it is possible for Workgroup Manager to edit user records in an LDAP server using LDAP v3 mechanisms.
Can you get your DHCP server (on OS X) to authenticate itself in Active Directory?
DHCP does not by nature authenticate. DHCP servers can send out additional vendor-specific DCHP packets -- Apple's implementation does this to tell Mac OS X clients where to look for directory services -- but they do not authenticate directly to DHCP. These additional records are ignored by systems that don't understand them. Look into the Mac OS X Server documentation and the
Can you get user lists and permissions to replicate into OS X's user list?
The point of central directory services is to NOT have everything replicate into client systems!
Lastly...can you get a user to log into OS X and have OS X process login scripts replicated to domain controllers? Doubtful...most of the windows login scripts don't apply to the Unix world.
You've answered your own question here -- the Windows-based login scripts do not make sense and would not run under Mac OS X. Mac OS X has its own ways of setting up scripts to be run on boot and on login, as well as automatically mounting share points.
Scripts can be run from the
Well, this really is a time warp -- Apple was looking at this before as well. This sort of experience was the intent of the OpenDoc system, which was a document-oriented way of running apps. You could embed documents within documents, based on a file structure called Bento, named after the Japanese-style stacking boxes. It was cross-platform (Mac and Windows) and you could even embed ActiveX content inside an OpenDoc container.
A definitely cool piece of technology, but it ended up on the cutting room floor when Apple was in dire financial straits. It was also too heavy-weight a technology for the personal computers of the day, since everything was basically a CORBA object, which are relatively slow even on honking big servers.
With MacOS X and the underlying Mach microkernel for message passing, OpenDoc or something like it starts to look more feasible for the desktop from a technological perspective. However, from a marketing standpoint, the companies that put together office software suites have a distinct incentive to make their products NOT interoperate in this fashion, since it helps to lock the user into a single suite.
--Paul
I found Ann Landers to be OK, but the Washington Post (my local paper) replaced her with Dear Abby (Iguess they had to), whom I've found to be vapid and flat. Thank heavens for a local (but also syndicated and more power to her!) alternative. Carolyn Hax writes the Tell Me About It advice column. It's advice with a hip, edgy attitude, along with some kewl comics to go with it.
Warning: Shameless Plug! :-)
:-) O, the training is good stuff, meaty and chock full of technical information. Almost everyone who goes through these courses says something like, "Wow, that's a lot of good, useful information."
:-)
Apple provides for-fee technical training that covers this and other very useful topics. The courses are generally a week long and involve instructor-led, hands-on training in setting up a network with Mac OS X and Mac OS X Server. IMNSH (and quite biased 'cause I helped write it!
We're working on the revisions for Jaguar right now, and expect to go live with the first course deliveries in a month or so. Go to the Apple Training website for more information.
--Paul
Paul Suh
Curriculum Developer
Apple Technical Training
(Help me keep my job! Buy training from Apple!
AppleScript is great, but the app that you are testing must be scriptable. Many are today, but some are not. Furthermore, in this situation you want to test the GUI, not just the underlying object model which is what AppleScript talks to.
However, AppleScript is not the only scripting environment for the Mac. Underlying all of the native scripting languages on the Mac is something called the Open Scripting Architecture. This allows any OSA component (i.e. scripting language) to talk to any other OSA component.
One OSA component is QuicKeys, a great product that actually does simulate mouse clicks, keystrokes, etc., and is completely scriptable. It integrates completely with AppleScript and via the power of the OSA, with shell scripts and Perl as well.
On top of this, Apple provides a powerful GUI building tool for AppleScript called AppleScript Studio, which is free. Plus, AppleScripts can talk across a network to do RPC. Imagine, you can have an AppleScript Studio front end that drives scripts on a set of machines over the network (so that you can assess performance under load). The individual scripts rely on AppleScript to drive the logic while using QuicKeys sequences to drive the GUI.
The only issue here is how easily you can assess results. There's no general way to check what the GUI is showing other than a pair of Mark I mod 0 eyeballs, since grabbing data out of the app being tested (even simulating a copy-paste) only talks to the underlying data structures and does not address GUI bugs. A possible way is to arrange the windows in a known manner, turn off the menu bar clock, take a screen shot, and use a graphical comparison tool to XOR the bitmap with a known good screen shot to highlight differences, but this won't work if you're working with variable or randomly generated data.
Disclaimer: I work for Apple, but these are my opinions only and do not represent any sort of official endorsement.
--Paul
Whatever systems you look at, keep an eye on maintenance costs and costs of down time. It looks like you're going to load your own custom OS -- Linux variant, *BSD, maybe something else. However, your time is valuable -- make sure that the the boxen that you buy support a rapid way of loading the OS. E.g., stick in a CD and everything happens automatically.
;-)
Down the road, look at the expected costs if one of these puppies fails. Depending on your expected costs (e.g., one element of a computing farm fails just before a 30 hour computation finishes, making all of the others freeze and loose their results in turn), you may want to go for a more expensive commercial 1U or blade server that uses better quality components or has redundant components.
Lastly, look to see how these can be mounted for easy access. At some point the whole mess of them will need to be upgraded or have their OS updated, and having them in easy access racks will be much less costly.
I'm partial to Apple's XServe, but then again I work for Apple
Good luck and let us know what you choose in the end.
--Paul
Take it from some folks who've been there and done that -- in a much smaller way and have nevertheless gone through a lot of pain.
For the transition from WebObjects 4.5 to WebObjects 5.0, the developers at Apple created a converter that transforms Objective-C source code to Java source code. This was done by parsing the Objective-C source, creating a parse tree, and then running scripts against the parse tree. Simple pattern matching was found to be inadequate.
This was a much smaller project than the one that you seem to be involved in. Why? First off, as computer languages go Objective-C and Java are very, very close in terms of structure and design. Second, even with the talent involved in this project -- whom I am completely in awe of -- they only created an 80% solution. The goal was to produce something that could get a developer well down the road on the way to a conversion, not do the entire conversion.
Then, the Apple engineers tested this tool in the harshest environment possible -- their own code. It was used to convert the entire WebObjects source code from Objective-C to Java; they made it work before releasing it to customers.
Management needs to take a step back and ask, "what the heck are we trying to do here, anyway?" Unfortunately, it sounds a lot like your management has their heads 'way up in the wrong place. A useful piece that I read recently is the Happy Valley Tax Authority case study. <HINT>Consider yourself lucky that your resume is relatively current.</HINT>
--Paul
Definitely check this book out at its author's site. Plus the links to other articles that Murph has written for LinuxWorld on how to swap out costly and unproductive Windows setups for Unix-driven systems. I don't agree with him 100%, but he's got a lot of useful insights.
--Paul
Use common uid's for the laptop local users vs. the network directory services users. I do this myself across three domains: Apple's NetInfo network, my own NetInfo network at home, and my TiBook's local NetInfo domain.
--Paul
This response is dead on. The original asker needs a file server that speaks multiple protocols. Once you have a server, it is much easier to create the necessary ssh or ssl tunnels that you need for total security.
Trying to maintain coherency of data via replication across multiple machines is begging for trouble -- this is a hard problem that to my knowledge has not been solved in a clean, cheap way.
If you want to use NetInfo for Mac OS X, create a new port from the Open Darwin sources. There's a port of an old NetInfo server module for Linux floating around, but it's not what I'd call up to date.
A better choice would be to use OpenLDAP, as Mac OS X is designed to pull directory service info from an LDAP data source. Windows systems can also pull from a LDAP, as can Linux and *BSD and Solaris and so on.
--Paul
That said, Mac OS X has a root user, but root does not have a valid password on installation. The first user that is created via the setup assistant is what is known as an admin user. These are users who are members of the group "admin", a predefined group. Apple provides an API whereby a GUI application can ask for an admin user's password, and thus gain sudo-style privileges for actions such as installing software (which might need to put things in places that can only be touched by root). Also, the
In addition, admin users have access to the
Note that the
If a user were to log in as root, he or she would immediately gain write access to the
From the command line side of the house, admin users are allowed to do anything via the sudo command, which is preinstalled on Mac OS X. If you need root access, you can use sudo to do just about anything from the command line. If you really, really need a root shell, you can always do "sudo -s" and get one.
In summary: Mac OS X has the tools that you need to perform system administration tasks form either the GUI side or the command line side without needing to log in as root. Logging in as root is the equivalent of opening up a piece of machinery with the warning label, "No user serviceable parts inside", and you should not be surprised if you get hurt when you do this.
Paul Suh
psuh@apple.dontbotherspammingmeigetwaytoomuc
Note: on Mac OS X Server, root is enabled by default. This is considered less of an issue since it is expected that servers will be run by people who have a better understanding of the issues involved and are more likely to be doing things that need root access, even from the GUI level.
MacCentral has run a bunch of Forward Migration Kits for different industries. They ran one about medical management software about two years ago -- kinda dated, but it should give you a starting point:
Part 1
Part 2
Part 3
Part 4
Part 5
--Paul
One mouse button? Macintosh! Ever wonder why the Mac is so successful in K-12?
--Paul
Ars Technica did an article comparing the AltiVec and SSE/MMX2/3DNow! architectures. Written a while back, but still valid as the architectures have not changed.
--Paul
Most of the climate control units -- and you really need to think in terms of humidity as well as temperature -- are very noisy. Don't put someone at the desk on any kind of extended basis (>1 day) or he or she is likely to go postal. Noise cancelling headphones may help, but these sorts of rooms are not in general fit for extended human habitation.
A regular telephone with a speakerphone and a l-o-o-ng cord and possibly a headset is also a good idea for calls to various tech support lines.
--Paul
You really need to check out the Enterprise Objects Framework layer of WebObjects. You can use this in a web app or in a Cocoa app. It's an object persistence framework that talks to a variety of databases -- support for Oracle, MS SQL Server 7, and and MySQL is built in, FrontBase and OpenBase are excellent Mac OS X native relational databases, and it basically should work with any database that has as JDBC 2 type 4 driver available. EOF has been around since the NeXT days and is a rock-solid, mature database access technology. ADO by comparison is a complete wannabe.
Also, check out the recently released dual 1 GHZ G4 2U rackmount server from yellow dog linux's developer, Terra Soft Solutions.
--Paul
Quote:
Apple has an easy to use data access framework a la ADO.net (with Postgres support): Rack mounted OS X application & database servers
This sort of attitude towards labor -- that the demand for labor is a zero-sum game and that an increase in productivity will inevitably lead to people being thrown out of work and/or the vast majority of laborers having their wages reduced since less labor is needed -- is prevalent in a leftist fringe of economists, predominantly based in Europe (Note that Beck is based in Munich, Germany). It is widely rejected in North America, the United Kingdom, the Far East, and South Asia.
It also ignores basic equilibrium analysis from Econ 101. You can approach it from two angles:
So what actually happens? The total output of the economy rises. Workers and company owners are better off -- remember, it's consumption that counts in the end, not wages -- since there is more stuff to consume in the end. (Also remember that savings/investment/borrowing/lending is simply a transfer of consumption to or from the future.)
This is not to trivialize the pain and uncertainty that people are feeling due to the loss of jobs or job security, but the fact is that these kinds of dislocations are what make economies grow. Read up on Schumpeter's "creative destruction" in any basic macroeconomics text for a more mainstream view on the situation. Also note that any attempt at differentiating between low- and high-skilled workers or applying an international trade angle does not invalidate the basic analysis, it just hangs bells and whistles on it.
Lastly, this European-biased analysis completely ignores an important fact of life in the United States today. The unasked question is, "who owns the companies?" In Europe, stock ownership tends to be highly concentrated, with many companies controlled by a small number of people. Information disclosure requirements are also very lax compared to the U.S. or U.K. exchanges. In contrast, in the U.S. the majority of people own some common stock, either directly or via a mutual fund or retirement plan. Any increase in corporate profits directly benefits the majority of people.
SOAPBOX
The problem lies not in the U.S.-style open, flexible economic structure, but in the European-style stagnant, inflexible structure as influenced by Beck's brand of economic drivel. Note that in continental Europe, unemployment rates of 10% or more are common, and economic growth has been much lower than in the U.S. for the past two decades. The French have legislated a 35 hour workweek in an attempt to raise wages, thus shooting themselves in the foot -- how are things supposed to get better if the quantity of productive resources within the country are reduced? This whole line of left-leaning pseudo-analysis is discredited by not only theoretical analysis but also by the observed results.
/SOAPBOX
--Paul
* A lot of interaction with the customer
* A good feel for what competitors in that market can offer
* A good feel for the corporate culture & existing systems in the company your selling too
These things are very hard to achieve if the design team is half a world away - the cycle times are just too long and to make a good product/system you need a lot of interaction with your customer.
It's a lot harder to deal with than just separating the design vs. coding teams. I've architected and coded several enterprise-class custom web applications, and the biggest problem is always that the customer doesn't really know what they want. This is what leads to part of the Extreme Programming paradigm, that part about very rapid (1 to 3 week) design and review cycles. You talk to the customer, you build a first prototype, get feedback, code some more, etc. Eventually, you home in on what the customer really needs.
Taking this offshore is a very difficult proposition. Working with a customer over a phone line or at best a videoconference link is an order of magnitude harder than getting everyone in a conference room, test driving your latest product, then brainstorming on a white board as to what's good and what's bad.
The only possible way this can work with an overseas coding shop is if you just have the architect or designer show up at the customer, and rely on him or her to write the spec for the coders. Even so, there's a lot in terms of the customer's intent that gets lost in the transmission even if the point guy is a phenomenal communicator.
Furthermore, it's hard for the architect to know exactly what questions the coders have for the customer. I make it a point to bring along the junior coders to project reviews if the customer is local. (And for me, a lot of them are. YMMV) This serves two very useful purposes -- it lets them ask questions and especially followup questions to the customer directly, and it starts to introduce them to how you handle customer relations as part of their professional development. If the customer is remote, I still make an effort to bring along at least one of the other coders to some of the project meetings.
All of this assumes that the overseas shop is willing to work with a XP-style development process. I can't claim any extensive familiarity with the general mass of overseas development shops, but the two that I have dealt with were very big on having a detailed spec up front, so that they could estimate their own costs. They were willing to hold weekly project reviews, but these were aimed at how well they were writing to the spec, not changes to the spec to fit new discoveries.
Repetitive tasks with fixed APIs, and exact ports of existing projects to new programming language/platform/etc -- these I can see being done effectively using an overseas programming shop. Writing a new application or adding new functionality to an existing one? No way. There are less painful ways to run a death march project.
--Paul
Most people seem to be talking about OO and engineering in the abstract, so I thought I'd add some facts from a real-world case study. (* ducks out of the way as screaming ./'ers flee for the exits ;-) *)
When I was a Senior Economist with the Law and Economics Consulting Group, I worked on an electricity deregulation project. We had to model the electricity market, including the flows from sellers to buyers and constraints on the flows. Individual generating plants had run rate upper and lower bounds, and there were varying loads depending on time of day and time of year.
This was modelled by using the following main classes: electricity generating plants, utility companies, and transmission lines, plus some minor helpers. Each electricity generating plant had its own capacity and marginal cost of operation, and there were various sub-classes of generating plant for the different types: coal-fired, gas-fired, gas turbine, hydro, each of which had different characteristics; e.g. hydro plants had lower capacities in autumn than in the spring. Transactions between utilities were modelled as another sub-class of generating plant, whose capacity was the amount of the transaction and whose cost to run was the price of the electricity sale. All of this was subject to the transmission constraints between nodes.
Utility companies had loads that they needed to supply, either using their own generation capacity or by purchased power. They would attempt to reduce the cost of supplying their loads by purchasing electricity on the open market instead of running their own plants. They would also attempt to generate additional profits by selling electricity to other utilities whose costs were higher. The market was run via multiple rounds of bidding, until the cost of electricity in all of the different areas had stabilized. There was a special case (although in the programming world no sub-class was needed) of energy marketing companies, e.g. Enron, which had no native loads that must be supplied but which did own generating plants.
So you say, OK, why is this an engineering problem? Isn't it an economics problem? Well, it is in fact a superset of the engineering problem. In fact, there were several software packages that we investigated that -- given the operating characteristics of the plants, the transmission constraints, and the loads to be supplied -- would calculate the most cost-efficient combination of generators that could supply that load. However, none of these would have given us any insight into the necessary market interactions that would happen under deregulation. Writing our own model in C++ using OO methods enabled us not only to solve the engineering problem of supplying electricity to the region, but also to study the way that the companies would behave in a deregulated environment.
--Paul
Why bother with fans at all? There are two fully-functional desktop personal computers out there today that you can go out and plunk down cash, credit card, or check with two forms of ID and take home right away. You can install Linux or *BSD on them, or use the vendor's pre-installed OS. In two months, the vendor is going to release a new, Unix-based BSD 4.4-compatible operating system that will be pre-installed on all of the machines come the summer.
;-) Check it out at Apple's iMac page and Apple's Cube page.
What am I talking about? The iMac and the Cube, both by Apple. Both are completely convection cooled, and the only sound you hear is the clicking of the hard drive (and the sound of the other poor bozos getting fragged in Q3A
OK, so I work for Apple, but c'mon folks, do the design right and you don't need a fan!
--Paul
...but the people who have been promoting electricity deregulation have been treating it as such.
Some background here: I am A.B.D. in Economics from the University of Pennsylvania, and worked for several years as a consulting economist as a part of a team providing expert witness testimony on a variety of cases. One of the things that I researched was the market for electricity in Texas.
We eventually wrote a large simulation model to handle how the market would clear in Texas, to determine if there would be times when a single utility company or power marketer might be able to corner the market and behave as a monopolist. Although there are excellent engineering models of how generating plants should be allocated to produce the lowest-cost combination that will supply a set of reginal demands, these are not necessarily applicable in a deregulated environment.
There is a fundamental theorem in economics that states that if you can find an efficient allocation of resources in a system through a command-style solution (such as an engineering model), you can de-centralize the system and still achieve the same result by choosing an appropriate set of initial allocations and initial prices. In other words, any efficient solution can be achieved by a free market. But, this is all subject to several technical conditions; if one of the conditions is violated, then the theorem can no longer be applied. In the U.S. economy today, those conditions are satisfied by most industries, which is why the free market works in general.
However, the electric industry is not one of them. The particular violation is in the requirement for smooth, continuous supply curves. If there are gaps in the supply curve or there are places where the supply curve has a sharp kink in it, the theorem does not apply, and there is a real danger that the market may not achieve a stable equilibrium. For electricity, the problem lies in the way that generating plants run: you can't just turn them on or off. Many plants have a narrow range of outputs -- e.g. a particular plant may be able to function between 40% and 100% of capacity or it can operate at 0% of capacity, but it physically cannot operate between 1% and 39% of capacity. Thus, a 500 MW plant might be able to supply between 200 MW and 500 MW of power, but it cannot supply only 100 MW of power.
This leads to kinks (and non-convexities) in the supply curve, which create opportunities for electric utility companies to act as monopolists and jack up prices -- and the usual constraining effects of the market may not apply. For example, suppose one company has a large 500 MW generator as described above which can supply electricity cheaply, and another company has a smaller generator that can supply between 0 MW and 300 MW of electricity, but at a more expensive price. If there is a demand for an additional 100 MW of electricity, the market will not be able to steer the demand to the low-cost generator, but must instead send the demand to the more expensive second utility, which can jack up the price as high as it wants without fear of competition. In contrast, an engineering model would allow the system operator to tell some other generating plant to cut back its output by 100 MW, so that the cheaper plant could run at its 200 MW minimum capacity and reduce the cost overall.
I have read some of the testimony concerning electric power deregulation, including that which was presented in California, and this key point has been ignored, as it is an inconvenience to the utility companies who paid for most of the testimony. While I have attempted to keep my explanation here simple, the above is in fact based on solid, academic-level theoretical economic research, and I will happily send out my working paper on this on request. It's still pretty rough, but I hopes of sending it in to a peer-reviewed journal some day. Anyway, back to doing WebObjects.
--Paul
OK, I have moderator privs right now, but this thread is just too tempting to not jump into!
:-)
1) Given the architecture of X Windows, you must have a an X server running on your machine. Even local X Windows apps run by connecting to a local X server. Just compiling an Xlib will not give you much in the way of speed gains -- loopback calls under the OS X's network architecture are very cheap (heck, this is true for most OS's).
The relatively expensive part of the X Windows architecture (in terms of speed and resources) is the context switch that is necessary in this whole set-up: server process picks up mouse click and sends to client, client processes mouse click and sends display commands back to server, server processes display commands and puts them back onto the screen. Any mouse click requires at least two context switches (server to client, client to server), which are expensive under some OS's (MS WinNT/2K, Classic Mac OS). However, under the Mac OS X kernel, and indeed on most Unices, context switches are fast and cheap, so this is not much of a performance hit. (This is why Apache on Unix runs multiple processes, but is a single multi-threaded process on WinNT/2K.)
Pushing the server-side functions into the client-side Xlib would only really save the cost of the loopback overhead plus the context switches, both of which are cheap in Mac OS X (and other Unices). Only on a Windows- or Classic MacOS-based system does it make sense to try and cut out the context switches.
2) The X Windows server does in fact translate X calls into native Mac OS X calls. The implementation referenced above does it through the VNC application, which is extremely slow due to the massive number of layers involved -- one or two context switches are not so bad, but it looks to me that they're going through four or five. If you look at the Mac OS X graphics architecture, there is a lightweight graphics server underneath it all called Core Graphics Services, which is responsible for all drawing on the screen. Aqua, QuickTime, OpenGL, and QuickDraw all hook into this layer to do their actual drawing to the screen. It is possible (I don't claim it's easy, but it shouldn't be that hard) to write an X server that hooks in directly above the Core Graphics Services layer to translate X Windows calls to native, low-level CGS calls. This would make X Windows just as fast as the native libraries (aside from bottlenecks that might be inherent to X Windows) and allow for interleaved X and native windows on the screen. This is the Right Way To Do It (tm).
Disclaimer: I am an Apple employee, but these views are my own and not based on anything that is Apple Confidential. I work with WebObjects as part of Apple iServices, which is a bit away from the core Mac OS X dev teams.
--Paul
I would divide software projects into three categories:
- Mass-market software
Software aimed at a mass market of many customers faces the problem that each of them has his or her own specific needs. The software engineering tradeoff here is development time and money versus how many customers really want/need feature X. Secondary factors are how much this contributes to code bloat, slow speed, and more bugs. Open source software faces these questions, but the answers are a little bit different relative to a commercial environment. Many users of the software may want/need feature X, but if none of them are coders and thus can't contribute directly to the work on the feature, it won't get done. (I admit that the more people want something, the more likely it is that one of them can/will contribute code to the project, but this is a second order effect.) As a result, if the core team does not set up at least a semi-formal requirements process, feature X will never make it into the project and down the road, users may stop using the software due to the lack of such a feature, leaving the project to slowly wither away. Alternatively, without a written rquirements process which the user base may respond to, the core team may spend a lot of time and effort on a feature that is relatively unimportant to the vast majority of users.Custom software developed for a specific customer
Tweak-ware
Software written for a specific customer also needs a requirements process, as in my experience three-fourths of the problem is that the customer doesn't really know what is really needed. As a case in point, I spent about three weeks working with a client on a web-based log-in process. I spent a week or so reviewing the current state of things, which was that they had gone ahead and done six months worth of development without a real requirements document. Guess what I found? A critical part of the log-in process was gathering user information so that they could decide which sales rep should follow up on this customer contact, but they had not yet decided whether this should be handled on a geographic basis or a product-line basis, and depending on which way things went, they wanted to ask different survey questions and have the user information sent to different people. After another two weeks of feeding-time-at-the-zoo meetings, we pulled the plug on our involvement with this until they straightened out the requirements. Open source software doesn't face this as much, but even so, there can be considerable friction within a OSS project's core team if the requirements are not written down so that they are clear. The result can be acrimonious exchanges and even splits among the development team, creating bad blood that didn't need to be.
Tweak-ware is possibly the only place that might not need a written requirements set, IMHO. This is a piece of software written by a programmer for his or her own use, with little expectation that it will become something used by many people. In this case, what's in the coder's head will suffice, as you know what you want. However, I would argue that the formal process of writing it down in English (or other non-computer language of your choice) is a great aid to clarifying your thinking on the subject. (My background is in Economics, and the worst professional insult you can say about an economist is, "Oh, him? He's a hand-waver," meaning that he doesn't write down his work in a formal paper that can be properly peer-reviewed and analyzed, but just stands at the front of a seminar room and waves his hands before a blackboard. You can get away with a great deal of vagueness waving your hands in front of blackboard that just won't fly when you write it down on paper.)
--Paul
There's a huge difference between an Associate (2 year) degree from a community college and someone with a Master's-level or Doctoral-level education. It has to do with how well these people are trained with respect to formal analysis of problems. At the undergraduate level, the courses are focussed on transferring specific knowledge already accumulated by others to the student, who is then able to use the knowledge to solve problems. At the graduate level, the emphasis is on learning how to formalize new knowledge so that it can be passed on to others.
This difference shows up when you hire a someone to work on a problem. People with an Associate's degree (or no degree) and several years of work experience on average will tend to focus more on solving the immediate problem, rather than looking for the larger patterns that may be present. This translates in poorer application designs and a poorer understanding of what existing libraries can do for you. Note that I said on average -- there are always standouts who will succeed because of their natural inclinations and abilities, with or without a degree. However, I don't think that any of us can make the assumption that we are among those standouts at the tender age of 17 or 18.
Another way to look at this is signalling theory, a branch of economics. People signal to employers about their abilities and talents by choosing the amount of education that they undertake. For a naturally dumb person, school is difficult (i.e. costly) compared to the rewards that she will gain down the road; as a result, she opts for less formal schooling and goes directly into the work force. For a naturally smart person, school is relatively easy (i.e. cheap) compared to the rewards that come from the advanced degree, so she goes to college and grad school, rather than going directly into the work force. Employers recognize this, and are willing to pay more for a college grad than a high school grad with four years' work experience. This scenario holds true even if you make the assumption that the amount of knowledge gained in the four years working is the equivalent of the four years in college, as the degree is a visible signal as to the type of person being hired (dumb or smart). (As an aside, I seriously doubt that four years of work experience in an entry-level job are even close to the equivalent of four years of college -- at that level there's just too much grunt work to really learn much.)
The same dynamic is at work here as in other industries -- don't think that computing is all that special. Really smart people whose minds can analyze a problem in depth are much more valuable to an employer. The easiest way to get those people is to observe the signal from the formal education. It does not matter that a specific individual without a college degree is better-suited to the job that another individual with a college degree -- if on average the people with degrees are more productive than the those without to a significant degree, this is a useful screening tool for an employer.
In fact, in this industry there are some degrees that I feel are negative indicators: such things as an MCSE without a college degree to back it up, or an Associates degree in Computer Science from a community college. These degrees are much too easy to earn and sound good to people whose sole purpose is to "get into the field". To me, they are not what a real professional will emphasize as educational background, and are only useful for resume padding.
Beyond this, another factor that most people coming straight out of high school miss when thinking about college is the importance of alumni and school networks. Of the four jobs that I have had since I got my Bachelor's, two were the direct result of alumni contacts and one was the result of a professor recommending me to a colleague. It is one whole helluva lot easier to find a job this way that randomly sending out resumes to want ads, and the jobs are generally better, too. By not going to college, you miss out on this tremendously valuable support structure.
--Paul