I just looked at all the replies and agree with most of them. I'd like to add one album that really needs to be listened to as a whole. It tells a story from beginning to end and has some really excellent songs.
I'd appreciate the correction if I were wrong. The original poster implies Safari needs more coders to get the product out SOONER. A properly managed project can scale like this (as you mentioned in your post), but this scaling comes at a cost. I think I applied Brooks' Law appropriately.
And please reread your post. When you condescend to other posters you aren't advancing the discussion.
True, but anyone can use the WebCore framework when building their own browser. The Omnigroup guys have done this by releasing OmniWeb 4.5 using WebCore as the HTML engine. The WebCore framework is also comprised of open source code that anyone can examine, embrace, extend, etc.
Throwing more programmers at a project often times makes the project LATER, not earlier. Please take a look at Frederick Brooks' classic Mythical Man Month for a discussion of a real world example showing your claim to be false.
It's like the old "pregnancy" fallacy. You can't make a baby in one month by getting 9 women pregnant. Regardless of how many women you throw at that project, each baby will take 9 months.
IMHO, Apple's progress on Safari has been adequate. Each point release gets better. In its current state it can be used full-time provided you don't mind the occassional botched page render (but I see that in all web browsers).
HAHAHAHA, you've looked at all the data and ignored several pertinent facts in order to draw the exactly wrong conclusion. Congratulations.
There will continue to be competition on the Mac platform (and Windows and Linux) because Safari isn't the only game in town. I use Camino as my main browser. Firebird is looking very good too. Omniweb needs some more work, but it has been competitive since Day One.
Secondly, no hidden APIs are used by Safari. Its internal rendering engine uses the open source WebCore framework which is based off of KHTML. Omniweb 4.5 (just released a few weeks ago) uses that framework too, so it isn't exclusive to Apple. If you are thinking Safari uses super-secret-extra-special Quartz rendering APIs for blitting to the screen, think again. Camino draws to the screen just as quickly as Safari and it's 100% open source.
Competition is alive and well on the Mac platform. Perhaps it doesn't have 10 strong contenders in each category, but neither does the much larger Windows market.
The latency question is a good one. I'd say the answer to this lies in the driver for the NIC. I've written an IOKit ethernet driver and experienced pretty decent performance at 100 Mb. The system is processing packets as incoming data causes interrupts in the system.
However, I think the interrupt overhead for a 1000Mb link would be so high as to bring the machine to a screeching halt (okay, slow it down perceptibly). What a lot of driver writers do for gigabit links is to move their driver into polling mode. They essentially set a timer to go off every X milliseconds and process all the packets that have been copied into memory during that timeframe.
This gives a lower bound on the latency. A packet will always take X milliseconds to be noticed and processed by the system. Interrupt overhead stays low, but packet latency goes up a smidge.
It's a good trade off. I would bet that on a saturated link, packet latency at gigabit speeds is equivalent or WORSE than 100Mb. I might have to test that out...
Hmm, but from what I remember, you can't start Mac apps from the command line (because they are directories). So you can kill AOL from SSH, but not start it. Great. Please, stop with the Mac shills.
You may use the command 'open' from the command line to launch applications. So yes, you may kill and start applications from the command line. Ooh, high tech...
That's fine for them, but tough for developers. Developers have to HELP them to make the OS the best it can be. However, that task becomes nearly impossible if you can't figure out how to use the new gee-whiz features to create the Next Big Thing.
Docs are very important. The old Apple knew it. I hope the new Apple is learning it.
I went through the previous incarnation of this manual and it was pretty lousy. I haven't had a good chance yet to study this one, but if they added any new information to it then I'll be happy.
The documentation for Apple's new systems has been rather poor. I've been writing an IOKit driver (check it out at http://sourceforge.net/projects/darwin-tulip/) and had a hell of a time figuring out some of the tricks. Some of that was related to this project being my first attempt at a driver (:-), but there were some critical areas where the documentation stopped dead in its tracks and said "This section is not written yet." D'oh!
My next project after this ethernet driver is to write either a) an opensource tool to defrag HFS+, or b) a VFS driver. If I do (a) first it will help with (b). I'm counting on there being better documentation on VFS than currently exists. I've started looking at the source code (the only documentation that exists on VFS), but it can take many months to become proficient with its internal workings; good doc should cut that down some.
Under the VFS section, there's a subsection entitled "A Politically Correct Example."
A Politically Correct Example
The Politically Correct File System is an example of a VFS stack. In this example, all calls are ignored (passed to the underlying layer) except for those that create, read, or write a file (or folder).
Upon receiving a request to create a file or folder, the Politically Correct (PC) stack intercepts the call before it can be executed by the underlying file system. The PC version of the create call checks the requested filename against a table of names. If the name is deemed politically incorrect, for example if the user chooses to name a file "vulgarity", the PC create call chooses a more pleasing name, for example, "politeness". The new name is passed to the create routine of the underlying file system.
Similarly, when a user opens a file to read or write it, such as with a text editor, the PC read and write routines first examine the data buffer, possibly substituting preferred words and phrases for their undesirable counterparts. After the substitutions are made, the buffer is handed to the underlying routine, which displays the data or writes it to disk.
Thus, if a user attempted to save a file containing a sentence such as this:
The beleaguered computer company's woes continue, despite rising stock prices.
the PC write routine might intercept and filter this sentence to a more desirable version:
The aspiring computer company's joys continue, due to rising stock prices.
I think Apple could support OS X on x86 at some point, but I would wager it is at least 18 months away. If I were Apple, here is how I would do it.
1. Continue enhancing the free development tools. Make sure gcc 3.1 and later is a first class citizen (I lurk on the gcc lists and there is a lot of Apple involvement).
2. Generate and distribute better documentation for writing IOKit drivers. Stress the importance of correct handling of microprocessor endian characteristics.
3. Use their investments and/or relationships with nVidia, ATI, et al. to push the development of a GPU that can accelerate their vector-based 2d graphics (Quartz).
4. Stress the use of the Cocoa framework for development; cease new development work on Carbon beyond bug fixes and performance enhancements. Alternately, port the Carbon framework to x86.
5. Line up a lot of driver support for 3rd party peripherals under PPC (related to #2).
6. Begin building support into Darwin x86 for some popular mass produced motherboards.
We already know that ProjectBuilder had a checkbox for compiling to x86 once upon a time (last seen in Rhapsody DR2 I think). Provided there is adequate availability of good drivers on the PPC platform, you may infer that a recompile of the IOKit drivers (or compiling them "fat") would also be adequate for a specific x86 system. IOKit abstracts the hardware layer enough such that the memory bus and device bus might "just work."
Apple could work a deal with an OEM (bury the hatchet with Dell perhaps?) to build a system using specific components that are known to be well supported by the OS. This would allow them to ship a machine that works out of the box with the same suite of hardware add-ons that we've all grown to love (all the great USB, IEEE1394, ATA, etc. devices).
On the ISV side of things, Apple could prove the viability of the platform just by shipping versions of iMovie, iTunes, iDVD, iPhoto, iEtc until the ISVs could catch up. Provided the dev tools are up to snuff, within 6 months there could be a reasonable number of x86 or fat applications available. It would be akin to the wait we've endured for OSX compatible apps since March of 2001 when it started shipping.
In 18 months the speed of microprocessors would hopefully be fast enough that the Altivec-enhanced graphic routines weren't necessary for a good user experience under x86. Couple that with a GPU that can accelerate Quartz and the need for Altivec diminishes even more for this specific operation. Also, Apple would need Motorola or IBM to have a PPC that was able to better compete with Intel and AMD so they don't completely lose their existing hardware sales.
Just a thought. I'm certain there are a million reasons this wouldn't work or Apple wouldn't do it, but it's fun speculating.
Apple was sued by the Beatles record company. Apple settled out of court (I believe) and agreed to never enter the music industry. They were sued again when Apple began to support the MIDI standard which was interpreted as breaching their agreement with the record label. I think that also got settled out of court.
Alan Kay is widely credited with inventing the basic GUI concepts upon which all modern GUIs are based. However, I *believe* that he did NOT invent the concept of overlapping windows. Check out HACKERS by Steven Levy to support this, but according to that book it was actually Bill Atkinson @ Apple who invented overlapping windows.
It came about after the second visit to PARC. Bill went back to start coding up Quickdraw and came up with the concept of regions when he tried to make windows overlap. He had to then add support for clipping. Up to this point, all Mac windows would butt up against each other but COULD NOT overlap.
Of course, HACKERS may be full of crap in which case ignore everything I've written here.
I had the distinct pleasure of seeing you speak at a meeting held by the student chapter of ACM at University of Illinois. You told some rather fascinating (and funny) stories about your evolution as a geek. Instead of being a major software geek (though you did some cool stuff with color on the Apple II), it seems your first love is hardware design.
You spent significant effort on the motherboard designs of the Apple II. You've spoken in the past about how you would tweak things here and there just to eliminate the raw number of chips in use on the board. The puzzle (and challenge) for you was designing elegance through the most minimal architecture possible while retaining maximum function.
[Q] In your opinion, how well do today's motherboard designers perform at their craft? Have you learned any new hardware tricks from modern day designs? Have any of your old tricks been lost, and if so, what are they?
Thanks for your contribution to computing. A lot of us wouldn't be here if not for you.
"We" are a financial services firm (trading outfit). The work involved is straight forward admin work, no pure research outside of "should we upgrade Apache to the latest rev" kind of research. We had approximately 95 Suns in production, but the past two years has seen us consolidating a bunch of tiny servers to fewer big servers. In other words, all the sparc20's and ultra 1's are getting replaced by E450's or E4500's with lots of processors. The interesting aspects of this move has been the use of various Veritas products for High Availability.
Of course, aside from supporting the production environment we support an entire development network and a group of 5-15 C++ coders. We manage the development and QA environments for the in-house apps that are created plus we handle all code migrations from QA to production. We don't test the in-house apps, however.
Then there are some of the basic infrastructure items we handle. For instance, tape backups of all dev/QA/prod machines, new installs, intranet web management, code migrations, 3rd party software installs, etc. Nothing we do is particularly tricky, but the admins need to be GOOD. Thankfully the admins here are very good which helps minimize downtime (time is money, hence all the High Availability stuff).
Having said all this, it is still difficult to quantify productivity. We assign most work in the form of projects and a deadline is tagged to it. To me it is a toss-up between salary and hourly which is why I approached the unix group and asked for their feedback.
They have elected salary, but I am confident it isn't for some of the reasons I've seen listed before (like "getting away" with non-job related functions all day but still collecting a paycheck). BTW, the overtime compensation that we do offer is in the form of a comp-day. This is awarded if you work overtime in excess of 4 hours on any given day. To collect, you take a day off in which you are paid your normal salary but don't have to work, OR you cash it in for $100 (gross). Depending on your tax bracket, the $100 becomes much less after Uncle Sam takes his kilo of flesh.
You wrote," I'm on a salary, and wouldn't have it any other way. As it is, I can spend an afternoon, say, with a book on my lap, boning up on a subject which is only borderline relevant to my job. A current example is XML, which may become an important part of my area in the next 6 months, but at present is nothing to do with our current project."
It sounds to me like you feel that reading a technical book is stealing from the company. That is hardly the truth, particularly if there are future applications of that knowledge to your job. I would chalk it up to education, and only the most stubborn and ugly companies would give you a hard time about furthering your knowledge base (especially if they will receive the fruits of those labors).
If they are really that hard-assed, I suggest finding another job. In your case, I don't think salary or hourly makes a bit of difference if the company behaves the way you describe it.
I appreciate your comments. What obviously got lost in my question submission was that the employees did not approach me, but instead I approached them. I felt the calculations were unfair to them, so in my quest for feedback what I got was "Everything is peachy!" Where I thought there was a problem, they told me there was not. Live and learn...
I'm a middle-management guy. I started out as Mr. Low-tech-on-the-totem-pole and through a combination of hard work and luck moved up the chain of command. I've reached the point now where I don't get to do a whole lot of hands-on tech work, but I most certainly REMEMBER what it was like to be one of the people who does the tech work. Believe it or not (the cynics on./ won't believe it), but I was genuinely concerned about their welfare and was trying to solicit feedback to make things better.
The message I received was that things are already good enough.
I'm enjoying all of these responses... I knew asking the question here would bring both nutcases and thoughtful folks out of the woodwork. Your response is squarely in the "thoughtful" category.
DreamerFi, it wasn't really feasible to submit an entire treatise on salary and wages during my "story" submission, so some of the details aren't there.
To answer your question, I don't have any trouble at all with getting folks to stay late and/or come in weekends to work. The genesis of my question came from MY disatisfaction with the way overtime is handled. I assumed that if I was unhappy then there was a good chance others were unhappy too. I try to be proactive when it comes to the well-being of the people I work with, hence the discussion I had with them.
Frankly, I was surprised by the response. We work a lot of overtime, but the concensus is to stick with salary. It's viewed as "safe."
Slashdot Mirror
I just looked at all the replies and agree with most of them. I'd like to add one album that really needs to be listened to as a whole. It tells a story from beginning to end and has some really excellent songs.
Queensryche - Operation Mindcrime
cr
I'd appreciate the correction if I were wrong. The original poster implies Safari needs more coders to get the product out SOONER. A properly managed project can scale like this (as you mentioned in your post), but this scaling comes at a cost. I think I applied Brooks' Law appropriately.
And please reread your post. When you condescend to other posters you aren't advancing the discussion.
cr
True, but anyone can use the WebCore framework when building their own browser. The Omnigroup guys have done this by releasing OmniWeb 4.5 using WebCore as the HTML engine. The WebCore framework is also comprised of open source code that anyone can examine, embrace, extend, etc.
cr
Firebird for OS X is available. You can download it here. It's not completely stable yet, but it is making excellent progress in the nightly builds.
cr
Throwing more programmers at a project often times makes the project LATER, not earlier. Please take a look at Frederick Brooks' classic Mythical Man Month for a discussion of a real world example showing your claim to be false.
It's like the old "pregnancy" fallacy. You can't make a baby in one month by getting 9 women pregnant. Regardless of how many women you throw at that project, each baby will take 9 months.
IMHO, Apple's progress on Safari has been adequate. Each point release gets better. In its current state it can be used full-time provided you don't mind the occassional botched page render (but I see that in all web browsers).
cr
HAHAHAHA, you've looked at all the data and ignored several pertinent facts in order to draw the exactly wrong conclusion. Congratulations.
There will continue to be competition on the Mac platform (and Windows and Linux) because Safari isn't the only game in town. I use Camino as my main browser. Firebird is looking very good too. Omniweb needs some more work, but it has been competitive since Day One.
Secondly, no hidden APIs are used by Safari. Its internal rendering engine uses the open source WebCore framework which is based off of KHTML. Omniweb 4.5 (just released a few weeks ago) uses that framework too, so it isn't exclusive to Apple. If you are thinking Safari uses super-secret-extra-special Quartz rendering APIs for blitting to the screen, think again. Camino draws to the screen just as quickly as Safari and it's 100% open source.
Competition is alive and well on the Mac platform. Perhaps it doesn't have 10 strong contenders in each category, but neither does the much larger Windows market.
cr
The latency question is a good one. I'd say the answer to this lies in the driver for the NIC. I've written an IOKit ethernet driver and experienced pretty decent performance at 100 Mb. The system is processing packets as incoming data causes interrupts in the system.
However, I think the interrupt overhead for a 1000Mb link would be so high as to bring the machine to a screeching halt (okay, slow it down perceptibly). What a lot of driver writers do for gigabit links is to move their driver into polling mode. They essentially set a timer to go off every X milliseconds and process all the packets that have been copied into memory during that timeframe.
This gives a lower bound on the latency. A packet will always take X milliseconds to be noticed and processed by the system. Interrupt overhead stays low, but packet latency goes up a smidge.
It's a good trade off. I would bet that on a saturated link, packet latency at gigabit speeds is equivalent or WORSE than 100Mb. I might have to test that out...
cr
cr
That's fine for them, but tough for developers. Developers have to HELP them to make the OS the best it can be. However, that task becomes nearly impossible if you can't figure out how to use the new gee-whiz features to create the Next Big Thing.
Docs are very important. The old Apple knew it. I hope the new Apple is learning it.
cr
I went through the previous incarnation of this manual and it was pretty lousy. I haven't had a good chance yet to study this one, but if they added any new information to it then I'll be happy.
The documentation for Apple's new systems has been rather poor. I've been writing an IOKit driver (check it out at http://sourceforge.net/projects/darwin-tulip/) and had a hell of a time figuring out some of the tricks. Some of that was related to this project being my first attempt at a driver (:-), but there were some critical areas where the documentation stopped dead in its tracks and said "This section is not written yet." D'oh!
My next project after this ethernet driver is to write either a) an opensource tool to defrag HFS+, or b) a VFS driver. If I do (a) first it will help with (b). I'm counting on there being better documentation on VFS than currently exists. I've started looking at the source code (the only documentation that exists on VFS), but it can take many months to become proficient with its internal workings; good doc should cut that down some.
cr
I think Apple could support OS X on x86 at some point, but I would wager it is at least 18 months away. If I were Apple, here is how I would do it.
1. Continue enhancing the free development tools. Make sure gcc 3.1 and later is a first class citizen (I lurk on the gcc lists and there is a lot of Apple involvement).
2. Generate and distribute better documentation for writing IOKit drivers. Stress the importance of correct handling of microprocessor endian characteristics.
3. Use their investments and/or relationships with nVidia, ATI, et al. to push the development of a GPU that can accelerate their vector-based 2d graphics (Quartz).
4. Stress the use of the Cocoa framework for development; cease new development work on Carbon beyond bug fixes and performance enhancements. Alternately, port the Carbon framework to x86.
5. Line up a lot of driver support for 3rd party peripherals under PPC (related to #2).
6. Begin building support into Darwin x86 for some popular mass produced motherboards.
We already know that ProjectBuilder had a checkbox for compiling to x86 once upon a time (last seen in Rhapsody DR2 I think). Provided there is adequate availability of good drivers on the PPC platform, you may infer that a recompile of the IOKit drivers (or compiling them "fat") would also be adequate for a specific x86 system. IOKit abstracts the hardware layer enough such that the memory bus and device bus might "just work."
Apple could work a deal with an OEM (bury the hatchet with Dell perhaps?) to build a system using specific components that are known to be well supported by the OS. This would allow them to ship a machine that works out of the box with the same suite of hardware add-ons that we've all grown to love (all the great USB, IEEE1394, ATA, etc. devices).
On the ISV side of things, Apple could prove the viability of the platform just by shipping versions of iMovie, iTunes, iDVD, iPhoto, iEtc until the ISVs could catch up. Provided the dev tools are up to snuff, within 6 months there could be a reasonable number of x86 or fat applications available. It would be akin to the wait we've endured for OSX compatible apps since March of 2001 when it started shipping.
In 18 months the speed of microprocessors would hopefully be fast enough that the Altivec-enhanced graphic routines weren't necessary for a good user experience under x86. Couple that with a GPU that can accelerate Quartz and the need for Altivec diminishes even more for this specific operation. Also, Apple would need Motorola or IBM to have a PPC that was able to better compete with Intel and AMD so they don't completely lose their existing hardware sales.
Just a thought. I'm certain there are a million reasons this wouldn't work or Apple wouldn't do it, but it's fun speculating.
cr
Okay, I was wrong about Atkinson inventing overlapping windows. My memory is fallible.
cr
Apple was sued by the Beatles record company. Apple settled out of court (I believe) and agreed to never enter the music industry. They were sued again when Apple began to support the MIDI standard which was interpreted as breaching their agreement with the record label. I think that also got settled out of court.
So you got your wish.
cr
Alan Kay is widely credited with inventing the basic GUI concepts upon which all modern GUIs are based. However, I *believe* that he did NOT invent the concept of overlapping windows. Check out HACKERS by Steven Levy to support this, but according to that book it was actually Bill Atkinson @ Apple who invented overlapping windows.
It came about after the second visit to PARC. Bill went back to start coding up Quickdraw and came up with the concept of regions when he tried to make windows overlap. He had to then add support for clipping. Up to this point, all Mac windows would butt up against each other but COULD NOT overlap.
Of course, HACKERS may be full of crap in which case ignore everything I've written here.
cr
Woz,
I had the distinct pleasure of seeing you speak at a meeting held by the student chapter of ACM at University of Illinois. You told some rather fascinating (and funny) stories about your evolution as a geek. Instead of being a major software geek (though you did some cool stuff with color on the Apple II), it seems your first love is hardware design.
You spent significant effort on the motherboard designs of the Apple II. You've spoken in the past about how you would tweak things here and there just to eliminate the raw number of chips in use on the board. The puzzle (and challenge) for you was designing elegance through the most minimal architecture possible while retaining maximum function.
[Q] In your opinion, how well do today's motherboard designers perform at their craft? Have you learned any new hardware tricks from modern day designs? Have any of your old tricks been lost, and if so, what are they?
Thanks for your contribution to computing. A lot of us wouldn't be here if not for you.
cr
"We" are a financial services firm (trading outfit). The work involved is straight forward admin work, no pure research outside of "should we upgrade Apache to the latest rev" kind of research. We had approximately 95 Suns in production, but the past two years has seen us consolidating a bunch of tiny servers to fewer big servers. In other words, all the sparc20's and ultra 1's are getting replaced by E450's or E4500's with lots of processors. The interesting aspects of this move has been the use of various Veritas products for High Availability.
Of course, aside from supporting the production environment we support an entire development network and a group of 5-15 C++ coders. We manage the development and QA environments for the in-house apps that are created plus we handle all code migrations from QA to production. We don't test the in-house apps, however.
Then there are some of the basic infrastructure items we handle. For instance, tape backups of all dev/QA/prod machines, new installs, intranet web management, code migrations, 3rd party software installs, etc. Nothing we do is particularly tricky, but the admins need to be GOOD. Thankfully the admins here are very good which helps minimize downtime (time is money, hence all the High Availability stuff).
Having said all this, it is still difficult to quantify productivity. We assign most work in the form of projects and a deadline is tagged to it. To me it is a toss-up between salary and hourly which is why I approached the unix group and asked for their feedback.
They have elected salary, but I am confident it isn't for some of the reasons I've seen listed before (like "getting away" with non-job related functions all day but still collecting a paycheck). BTW, the overtime compensation that we do offer is in the form of a comp-day. This is awarded if you work overtime in excess of 4 hours on any given day. To collect, you take a day off in which you are paid your normal salary but don't have to work, OR you cash it in for $100 (gross). Depending on your tax bracket, the $100 becomes much less after Uncle Sam takes his kilo of flesh.
cr
You wrote ," I'm on a salary, and wouldn't have it any other way. As it is, I can spend an afternoon, say, with a book on my lap, boning up on a subject which is only borderline relevant to my job. A current example is XML, which may become an important part of my area in the next 6 months, but at present is nothing to do with our current project."
It sounds to me like you feel that reading a technical book is stealing from the company. That is hardly the truth, particularly if there are future applications of that knowledge to your job. I would chalk it up to education, and only the most stubborn and ugly companies would give you a hard time about furthering your knowledge base (especially if they will receive the fruits of those labors).
If they are really that hard-assed, I suggest finding another job. In your case, I don't think salary or hourly makes a bit of difference if the company behaves the way you describe it.
cr
I appreciate your comments. What obviously got lost in my question submission was that the employees did not approach me, but instead I approached them. I felt the calculations were unfair to them, so in my quest for feedback what I got was "Everything is peachy!" Where I thought there was a problem, they told me there was not. Live and learn...
./ won't believe it), but I was genuinely concerned about their welfare and was trying to solicit feedback to make things better.
I'm a middle-management guy. I started out as Mr. Low-tech-on-the-totem-pole and through a combination of hard work and luck moved up the chain of command. I've reached the point now where I don't get to do a whole lot of hands-on tech work, but I most certainly REMEMBER what it was like to be one of the people who does the tech work. Believe it or not (the cynics on
The message I received was that things are already good enough.
I'm enjoying all of these responses... I knew asking the question here would bring both nutcases and thoughtful folks out of the woodwork. Your response is squarely in the "thoughtful" category.
cr
DreamerFi, it wasn't really feasible to submit an entire treatise on salary and wages during my "story" submission, so some of the details aren't there.
To answer your question, I don't have any trouble at all with getting folks to stay late and/or come in weekends to work. The genesis of my question came from MY disatisfaction with the way overtime is handled. I assumed that if I was unhappy then there was a good chance others were unhappy too. I try to be proactive when it comes to the well-being of the people I work with, hence the discussion I had with them.
Frankly, I was surprised by the response. We work a lot of overtime, but the concensus is to stick with salary. It's viewed as "safe."
cr