I'd like to suggest that you stop using recruiters. Recruiters are your worst enemy.
Besides taking an enormous amount of money for doing very little real work (do you really think recruiters read a candidate's resume before they submit them?) many of them are either dishonest or even if they try to do the right thing they do not have the technical background to be able to separate the good candidates from the bad ones.
Your time will be much better spent if you find the candidates yourself. Perhaps you could hire a non-technical work-study student to use a search engine like Google to locate resumes for you. Then screen them and call them personally.
As a software consultant I cannot emphasize enough how much more carefully I pay attention to contacts from actual clients than I do from recruiters (or from potential employers, back when I was looking for perm jobs).
For my own policy about how and why I don't deal with recruiters, please read:
I have intended for a long time to put up a page addressing how employers can find technical talent. I haven't done that yet, but in the meantime you can find out how I find clients and figure out the inverse to see how you can use the web to find programmers:
I'm not clear on the answer to whether Speak Freely supports SIP or H.323, but my hazy recollection is that there's work being done in general towards interoperability.
You'll find some discussion about interoperability here.
Are you, like me, an audiophile who's really annoyed with the poor acoustical quality of telephones?
What you get is transmitted as 8 bits, although since it's mu-law encoded it's approximately as good as 13 bits. But it has only three kilohertz bandwidth.
The audio quality of the modern telephone was decided decades ago as basically what was required to make speech easily intelligible, but not what would make it enjoyable.
It is not really within the telco's power to change that because all of the equipment from one end to the other, as well as all of the communications protocols and software are pretty hardwired for that limitation.
Many VOIP products observe this limitation and in fact are often not as clear sounding as a real phone, either because they need to work over a 28.8 modem, or because you're using a commercial carrier (even though it's over the internet) who doesn't want to pay a lot for a lot of bandwidth for high-quality calls.
This was my experience when I got an "Internet Calling Card" which worked just like a regular calling card, but the voice was streamed over the net in the middle. The audio quality was terrible, much worse than a telephone, and my then-girlfriend (now my wife) asked me to stop using it as it disrupted the closeness of our conversations.
I was investigating all the options a couple years ago, as I was in California and the woman who is now my wife was in Nova Scotia. I eventually settled on AT&T One Rate International because her 486 wasn't powerful enough to run VOIP.
But these days we have powerful processors and fast net connections. I believe that it is within our grasp to have two-way voice conversations with 128 kbps streaming MP3 with real-time compression.
Just voice over IP isn't going to win that many people over if all they're saving is some money, because most people don't make that many phone calls that the expense is worth the extra trouble. But imagine if they could get CD quality sound during their conversations!
And there would be nothing the telcos could do about it because they would be hamstrung by their legacy technology.
Probably it would be better to implement this using Ogg Vorbis so there would be no patent issues.
And I'd like to suggest that it be built with the ZooLib cross-platform application framework so clients could be built for Mac OS, Windows, Linux and other Unix variants and BeOS from the same codebase - note ZooLib includes networking.
It really doesn't need to be higher priority than regular traffic.
The bandwidth required for a voice quality phone call that has been compressed by a modern voice compression algorithm (such as one of those available in Speak Freely) will be much less than someone using Napster, Gnutella or browsing an, uh, "image archive".
A good voice over IP product will work fine over a 28.8 modem. I know this because this is how I used to talk to my brother in law from California to Newfoundland.
You do occasionally suffer some dropouts or delays, but it's pretty tolerable, especially if you have a higher bandwidth connection, like at least dual-channel ISDN or 128 DSL. But still that's pretty modest as net connections go these days.
Probably your biggest concern is to make sure your ISP's connection to the internet is fat enough to support all their customers. Once it gets on the backbone its insignificant.
What I would like to see is voice over IP where the compression algorithm was streaming MP3, and we could have high-fidelity audio speech conversations at 16 bits and 44 khz. There's no reason we should have to deal with crappy 8-bit voice with 3 khz bandwidth in this day and age.
But even this wouldn't require a terrible lot of bandwidth.
Because Speak Freely allows you to configure the UDP port it uses, it is difficult if not impossible to block it.
In many respects it is the best VOIP package available, because source code is available (public domain, which doesn't fit the stricter definition of an open source license), it allows a choice of both transmission protocols and compression algorithms, so you can adjust each for your particular setup to get the best results, and it offers strong encryption (a non-encrypting download is available for places where that's illegal).
The main disadvantage is that because of all the options it is rather difficult to use. And because of some architectural features of Linux, it's hard to get working at all under Linux (but it can be done).
Usually what you need to do is learn how to use it, then get someone on the other end at a computer where they have both the telephone and internet available at the same time, and talk them through it. But I have worked with Speak Freely with novice users after giving them a little while of instruction.
It also has ICQ integration and if you have a full-time net connection you can use it in answering machine mode.
The ZooLib cross-platform application framework does not at the moment provide what you want but I think it provides the tools that could get you there pretty quickly.
It only requires very basic support from the underlying graphics subsystem for its GUI to work, so it can be bound to a new platform pretty quickly.
At the present time, it supports Mac OS, Windows, BeOS and POSIX platforms with XWindows (such as Linux). It enables you to write a single C++ codebase and build native executables for all those platforms from it.
I've had in mind building my own Linux distribution that would be all GUI with no command-line tools except for daemon services - all the configuration would be done through GUI kind of like the preferences under the BeOS. This would have a simple graphics subsystem that would be the minimum required to bring up ZooLib on it.
It wouldn't be aimed at the kind of user who wants command-line and XWindows, but would be very lightweight (could be used on a handheld, for example).
The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the
Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA.,
apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually
entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to
software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News,
13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/July13/cov2.html]
Risks moderator Peter Neumann tells me the Navy insists that this was not a software defect in the shipboard operating system but was caused by user error because a sailor entered a zero into a database field and then an NT application divided by it and brought down the ship.
Try Geneva, Switzerland, which has a number of big tech companies like IBM, as well as CERN - the big european particle accellerator facility and home of this newfangled thing called the World Wide Web (perhaps you've heard of it).
I'm not sure, but I think only citizens of CERN member states can be CERN staff members, and the U.S. is not a member state, but many american universities participate in CERN experiments and so you can go as a staff member of an american university - I did, as an undergraduate student, I did my senior thesis work at UC Santa Cruz at CERN this way.
Physicists have some strange ideas about what constitutes good software practice though. I try to politely correct this in this paper which I wrote for my experiment at CERN, proposing we scrap our FORTRAN codebase and rewrite it in C++.
Geneva's a little expensive to live in but if you work at CERN you can live in either france or Switzerland. (The particles have to show their passports twice each time around the accellerator ring as it crosses the border). I lived in France and found it very affordable.
Michael D. Crawford GoingWare Inc
My work at Live Picture was mostly debugging
on
Netscape 6 Vs. 4.7x
·
· Score: 2
I cannot imagine what you could be talking about, Live Picture being slow. Compared to the competition, it is blazingly fast. You could work with much larger files on much slower machines with less memory than has ever been possible with Photoshop or GIMP. Yes, in part it gains this speed by rendering only at screen resolution and deferring all time consuming processes until all the edits are done and you build to a final tiff file.
But this required incredible sophistication in the program.
I probably should clarify it in my resume as you really can't see what I actually did on Live Picture, but I didn't write the thing - almost all the work I did on it was debugging with a little bit of performance tuning. In particular, I fixed bugs towards the end of the 2.6 release and then I did all the engineering in the 2.6.1 release pretty much by myself, entirely debugging a codebase of 70 MB of C++ source code. Yes, 70 megabytes.
If you think intel hasn't done anything amazing I suggest you compare a Xeon to a 4004. Mistakes do happen, the fact is even for all of Intels mistakes the errors in hardware are much rarer than errors in software.
Why was it that Intel got all the heat for the bugs in their chips but Microsoft doesn't? Why should software be held to lower standards than harware?
While Live Picture was a very sophisticated product, I feel the company was poorly managed. Please see my resignation from Live Picture.
Heh, heh, heh I was quite struck by the weird moderation too. But hopefully I made some people think and talk about an important issue. I hope this does some good.
I want to apologize, I wrote quickly and when I said "programmers are lazy" that came out saying "all programmers are lazy". I more meant to say that the programmers who write bloatware are lazy.
That's not the only reason for bloatware. You can have hardworking programmers who are hamstrung by management. But I think the reason is important in practice.
I want to assert very firmly that the above was not a troll. I meant it very seriously and it is something that I have been discussing and posting widely on newsgroups and mailing lists for years.
I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:
If you don't take pride in your work you have no reason to be here.
This was back in my bad old days of being a college dropout, hungry with no idea what I was going to do for a career. I told him I thought that would be a terrible place to work, the boss would always be bugging you to work harder.
But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.
And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)
I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.
I also discuss it in my article
Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.
Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.
My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.
While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.
A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?
I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.
The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.
At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.
I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.
Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.
Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.
Michael D. Crawford GoingWare Inc
I am in fact a developer, here's my resume
on
Netscape 6 Vs. 4.7x
·
· Score: 5
Well, are you a developer?
I'm typing this from my workstation at my client's office, a web application company (I've clocked out). I'm using whatever Netscape came from the Debian site when I updated my software on Monday when I started.
Read about my laptop which was my main development machine for most of the last year. It boots NT, Slackware and BeOS.
You can read my resume - note the long list of products I've shipped, and keep in mind I haven't been keeping that list up to date. See the long list of projects I've done in the two and a half years I've been a consultant.
Note that among the jobs I've held was Senior Engineer at A Big Fruit Company where I held the role of "Debug Meister" - I did low-level debugging and in fact performance tuning of the Mac operating system.
When a tester found that an application would crash under a new system build and they didn't understand what component was at fault, it came to my team (Traditional OS Integration, formerly known as the Blue Meanies). We would track down the bug and assign it to the right engineer or fix it ourselves.
Note that sometimes, probably half the time, the bug was due to a third-party app bug, and we determined this purely by running MacsBug, an assembly level debugger, inside the app and system software. We had the entire Mac OS source code at our disposal but this wasn't usually readily available when you were visiting a crashed Mac at a tester's cube so you just had to know your MacBug.
I use and contribute to open source. My latest effort was aiding the author of the ZooLib cross-platform application framework in releasing his library under the MIT License; I worked with Andy Green for a year to test his code by developing a product with it and led a beta test of developers who also developed products with it.
I found ZooLib to be an incredibly enlightening example of well-architected, efficient and compact code for what it does. Just using it and reading the source code increased my own abilities as a programmer and architect tremendously.
So yes, I am in fact a developer, thank you. It's just that I maintain high standards and I like to encourage others to do so as well.
Michael D. Crawford GoingWare Inc
Programmers Make Computers Slower Year by Year
on
Netscape 6 Vs. 4.7x
·
· Score: 4
Even while our friends at Intel, Motorola and IBM do the most amazing things to speed up computer hardware (and don't forget our friends at Adaptec with the blazing 29160 SCSI Ultra160 Host Bus Adapter), programmers consistently work harder year after year to steal from the end user the gains that they might otherwise have from purchasing new hardware.
This leads to the ridiculous situation that an old computer runs slower and slower as new software is loaded on it, until you finally have to buy a new one just to run at all.
It's not just that you have the perception that your computer of old is running slower than the new computers because it was less zippy when you bought it, but because the regressive performance dehancements of operating systems and bloated applications really do make your computers run slower.
Note that I used to run SlackWare and Apache on a 100 MHz 486, serving up web pages (admittedly with a light load) while I used X at its console - and it worked fine. But when I loaded Windows 95 on it it was dog slow. There's no question of running Windows 98.
I had a 233 MHz Pentium II with 32 MB of Ram that I ran BeOS 3 for Pentium on. It worked great - I shipped Spellswell for BeOS Intel with this. But when BeOS 4 came out and they switched to Elf format, I had to upgrade to 96 MB because I couldn't run a compile and read my email at the same time.
Later I installed a near-final beta of Windows 2000 server on this machine. I intended to use it to develop a Java GUI app under CodeWarrior for Windows. To get the machine to run at all - not even running CodeWarrior - I had to add another 128 MB of RAM for a total of 224 MB. The machine was dog slow even after the memory upgrade.
There is no excuse for this. New features should not come at the expense of performance, and each new release of both operating systems and applications should be both faster and take up less space, not more. If substantial new features have been added then there may be cause for a little more code size but certainly not what we see in practice, such as what was listed in the Netscape 6 review.
Why does this happen?
One thing is because programmers are lazy, and if their code runs slow they assume the user will just get a faster machine. But friends, the user wants to buy fast hardware so they can actually run fast, not just so they can run at all.
Pressure to ship a commercial product makes managers fail to support efforts to do substantial performance tuning, especially tuning that is not localized but would require substantial rearchitecture.
And finally a lot of people just don't know how to architect or code. I think we could all benefit from learning and writing some assembly, so we could really understand what our software is doing.
Maybe then we could strip out some of the thick layers of software bureaucracy that lies between the user and his cpu.
It works pretty well software-wise, but two basic problems. NT4 doesn understand hard drives larger than 8 GB when you run its installer CD, with the unfortunate result that it ate my windows 98 installation that came preinstalled. Had I to do over again, I would have done a Norton Ghost backup image before trying anything.
NT4 does work with the large hard disk once you install the service pack and you can resize the partition with System Commander, but then the Emergency Repair disk process won't work. Someone in a newsgroup told me how to deal with this but I didn't understand it and would like to know how to do an emergency repair while booting of a CD that has already had the service pack applied, and that will install files with the service pack applied also.
I got the accellerated X server to work at first but lost my XF86Config after the hard drive consumption.
The happy news is that the BeOS recovered most of my windows data files.
The other issue is that the hardware has been unreliable. There is a fragile ribbon cable in the DVD drive that gets creased when you push the tray back in and jams it; sometimes it sticks the drive shut and you have to pry it open with a paper clip.
Also sometimes some random key will refuse to type for a few days and you have to keep banging on it to get it to type.
Finally, the connection between the power adapter and the socket on the laptop became unreliable so it wouldn't reliably charge. At first it would work if you fiddled with it and then left it sitting in one position during use, but this prevented you from using it for long on your lap.
Eventually it failed entirely and I needed to send it in for repair. But I was on an extended visit to Canada and even though Compaq has a Canadian subsidiary with Canadian service, this was a U.S. model purchased in the U.S and they wouldn't service it in Canada. They also wouldn't send the shipping container to Canada, or ship it back to Canada.
The end result was, because this was my main development machine and my business ground to a halt when the laptop failed, I ended up buying a custom built desktop machine from all standard OEM components.
I specifically wanted the ability to replace any failed part in the desktop myself from parts I could readily get at a computer store - you can usually do this with PC's bought at a "screwdriver shop" but not necessarily a name brand desktop PC, not just because you might void the warranty but because they use nonstandard parts that don't allow for OEM replacements that will fit.
I got compaq to send a replacement power adapter to my dad in Washington state and he expressed it to me in Canada - at about the cost of buying a brand new adapter - and with this, if I had my wife adjust it (with her steadier hands) we could get it to charge. This allowed me to recover my work from the laptop so I could install whatever files weren't backed up on my new desktop machine.
Then I waited about two months to fly home to the United states for Thanksgiving, where I arranged for compaq to send a shipping box so I could express the laptop in for warranty repair. I think they said they'd install a new system board, although they could just solder on a new plug.
They promised 7-day turnaround on the repair and free express shipping both ways. I flew to another state for some contract work so when my parents get the laptop back they'll have to forward it to me at our expense.
But after too many years of too many broken promises from Be, Inc. I spoke up one too many times on BeDevTalk and got forcibly unsubscribed after being one of Be's most loyal developers, and winning an award for shipping one of the few actual commercial BeOS applications.
I haven't had any first-hand experience with Microsoft but I have heard many horror stories that didn't make it into the Microsoft/DoJ antitrust trial. Remember that one of DoJ's problems was getting executives to testify publicly - but there's no shortage of developers willing to confide privataly about how Microsoft has screwed them.
One very public example is Stacker Software. They invented filesystem compression. Microsoft offerred to purchase Stacker, and examined their source code under nondisclosure while doing due diligence. Then they canceled the acquisition and came out with their own implementation of filesystem compression. Stacker sued and won over $100 million.
For the past year I have been working with the ZooLib cross-platform application framework. It allows you to write a single set of C++ sources and build native executables for Mac OS, Windows, BeOS and POSIX flavors that provide XWindows (such as Linux).
I believe ZooLib represents one important part of a strategy for freeing ourselves from these broken promises.
Note that I include quotes from Judge Thomas Penfield Jackson, who presided over the antitrust trial, one how Microsoft felt that it was so important to put a stop to cross-platform API's that it broke the law to interfere with their widespread use.
Jackson makes the same observation in his rulings that I have noticed in the past, that API and OS vendors work very hard to get developers to code to the native API rather than using a portability layer, as doing so locks the developer into the platform.
I mentioned this in another reply, but I'd like to emphasize something I wrote that I feel is pertinent - even having a shipping product, even having investment, even going public doesn't prevent a company from getting in trouble because of bad business decisions.
Sometimes those decisions are forced on a company against the wishes of even the senior management by the stockholder, venture capitalists, or the perceived interests of wall street.
Hey cool, if you come even close with that you'll have no problem getting some killer jobs.
It occurred to me that profiling a kernel like I suggested is a problem because the kernel can disable interrupts (as when handling an interrupt) and so even though you might be able to sample to some extent it may be hard to get good results. Also you crash the machine, etc.
But I recall reading recently here that someone had the Linux kernel running as a user space program. So you boot a real linux kernel, then run a fake kernel inside of some kind of hardware emulator or something. It was suggested to use this for kernel development - you could quit the kernel and restart it much quicker than rebooting and there's less danger of corrupting your machine, if your test machine is also your user machine, as is all too often the case.
But with this you could easily profile a userspace kernel and be interrupting it from the outside without the test kernel being aware its being interrupted, as those interrupts are not handled by the test kernel, but external code.
Of course, you'd want this to work for ordinary programs first. Let the kernel be your fourth year project!
which I'd suggest is good reading for anyone thinking of starting a company, or working at a startup.
But anyway, back in 1996 or so Live Picture 2.5 could open multiple 200 megabyte images and composite them together in sophisticated ways on a 68040 Mac with 64 MB of memory or less - with photoshop you need twice as much physical ram as your open files plus a scratch disk also.
With Live Picture, the response was always snappy. Just try opening a 200 MB image in Photoshop and rotate it two degrees. Go have a coffee. In Live Picture, you see the results now and can continue working.
Yes, there is a slow "build" process to save the end result to a TIFF at the end of the day but this can be run unattended, for example overnight and in a batch process.
Further, with Photoshop there's only one chance at undo. With Live Picture, it had essentially infinite undo.
The need to compete with Live Picture is why they added layers to Photoshop.
Photoshop does the job well, admittedly, but it does it in a simple way, through brute force. Live Picture used incredibly sophisticated algorithms and very deeply complex code. It was my job to do the engineering for the Live Picture 2.6.1 release, which was entirely a debug release - I was working with 70 megabytes of C++ code that took over an hour to compile on a Mac 8500/150.
I can't say anything about how it works, but Apple has basically two kinds of 68000 emulators that run on the PowerPC Macintoshes.
The first emulator I understand was basically an interpreter, sort of like the Java virtual machine but where the "bytecodes" are 68000 instructions (I'm not sure which actual microprocessor was emulated, maybe it was the '020). Not real fast because you have to
decode each instruction every time you hit it, but it was well-written and reliable.
Then there was the dynamic recompilation emulator which I believe first appeared in the first PCI Macs (like the 8500/120) and System 7.5.3 (not exactly sure if that's right but thereabouts).
This was like the JIT - "Just in Time" compilers for Java, it would compile 68000 code to PowerPC code and then execute the PowerPC code natively.
This was a shipping product I believe in late '95 and I'm pretty sure Apple was not the first to do such a thing.
Note that on the Mac they were unable to rewrite much of the low-level OS code from 68000 to PowerPC, at least not initially, and so a lot of system software remained emulated and probably still does. Also it is very common for Mac applications to install interrupt time tasks and many of those are legacy 68k apps and it would be innefficient to switch instruction set architectures all the time.
I seem to recall it takes something like 200 PPC instructions to switch from one architecture to the other so if you're already in 68k code and you're about to run a small routine it's best to remain emulated.
It is possible to write "fat" code that provides both options and the machine will use whichever one it's currently running - this is common for "Extensions" which make "fat patches" to OS calls, and many OS calls are "fat traps".
For this reason, the Classic System 7 MacOS (of which Mac OS 8 and OS 9 are examples, but Mac OS X is a whole different thing) handles hardware interrupts in emulated 68000 code.
Interrupt handlers and device drivers may be written in 68k code or PowerPC code as you like and run on a PowerPC machine.
The dynamic recompilation emulator I think emulates an '040 with its instruction cache issues, and it correctly handles hardware interrupts that happen in the middle of running a chunk of recompiled code.
Early Mac apps very commonly used self-modifying
code. For example, if a "code resource" was expected to be loaded into memory and used by the system, many applications would load a small stub that jumped to an offset that was a placeholder. Then they would write an address in the running program code into the placeholder after it was loaded. This kind of thing screwed up on the 040 because you were writing to code using data instructions, but there were lots of workarounds such as the painful decision to flush the data cache after calling BlockMove - and the addition of the BlockMoveData call which wouldn't flush the cache.
Also note that an application (or any code) can install callbacks that are written in 68k, PPC code or fat, and this code will be correctly called from the OS or toolbox, whether it started in 68k or PPC. This works because of something called a "routine descriptor" that is a compact description of a function API - it handles Pascal vs. C calling conventions, instruction set architectures, and the possibility of providing alternative entry points for each architecture.
On 68k there is a "trap" - a defined illegal instruction, that causes a jump to an exception handler. The exception handler reads in the routine descriptor and does the right thing. On PPC, you pass the routine descriptor to the CallRoutineDescriptor function (or something like that).
68k code is legacy and knows nothing about routine descriptors, but the emulated processor handles traps correctly. PowerPC being released after the routine descriptor architecture was all implemented, developers can easily put it directly in their code. There are headers with macros that make most of this transparent so you can compile both kinds from one set of sources.
I read an IBM paper when I was an OS engineer at A Big Fruit Company which discussed the use of instruction-pointer sampling profilers to optimize compiled PowerPC code (I think maybe actually POWER code, similar but not the same) by rearranging blocks of the machine code in the executable file.
This was in either late '95 or early '96 - but the IBM work on this had been around for a while by the time I read the paper.
This technology is widely available now - read all the way to the end to see how you can try it out.
If you have a jump to a certain offset in a routine, you can move the code where you jump to elsewhere in the file and change the offset you give in the jump. Complicated, because you need to parse RISC machine code, but doable.
It's made a little easier by PowerPC instructions always being fixed at 32 bits with no extension words (a side effect of that is that there's no way to load a 32-bit constant into a register with a single instruction, which makes it hard to scan machine code by eye for constants in an assembly debugger.)
This has the effect of speeding up the overall program execution because you group frequently used code blocks together in the executable file, and also in memory once it's loaded. You may find less-commonly used branches of an if-statement put miles away at the end of the file, so that you jump a long ways away and then back in sometimes, but this isn't a big deal because all the frequent cases flow straight along.
The reason this is a big win is twofold. First, you reduce virtual memory paging and the code resident in physical memory because less commonly used code is all grouped together and just sits idly paged out on disk; that which is taking up valuable physical RAM is of a minimum size and being used actively.
Also (and more importantly in small programs, and in CPU-bound cases), you make more effective use of your processor's code cache.
This is because jumping over an uncommonly used branch may load a few unused instructions into the cache at the beginning and end of the branch that's not taken - cache lines (blocks) are of a fixed size and are always aligned by the cache block size, so if you have 32 byte cache lines then the start of any cached code falls at a physical address that is divisible by 32.
If you run even one instruction into the address rangle, you load 32 whole bytes of code into the cache, deleting 32 bytes of code that might be useful later, then if your code is not optimized this way you'll just end up jumping over most of it.
Many people who are trying to make their programs
run faster would benefit from knowing more about
how the cache works. Gary Kacmarcik's
Optimizing PowerPC Code has a good discussion of this that will benefit anyone who programs on modern microprocessors - not just PowerPCs. And while Kacmarcik emphasizes PowerPC assembly, most of the benefit of improving cache use you can do from C, C++ or another higher level language.
The way the profiler works is that an interrupt-driven task is used to check the instruction counter at frequent but random intervals. The samples are saved to a file for later analysis, then a postprocessor makes a histogram which gives the number of samples per basic block of instructions.
(A basic block, essentially, is any code that falls between a pair of curly braces if it came from original C source code. It's more complicated than that in practice but basically it's a chunk of machine code that has one entry point and one exit. It's possible to analyize machine code with a program and divvy it up into basic blocks.)
Then basically what you do is sort the machine code, with the most frequently used basic blocks coming earlier in the file.
Note that the profiling process depends necessarily on the use to which the program is put during the sampling. For best results, you might actually want to prepare several seperate binaries of the same program, each optimized for a different purpose. Or you might want to construct test data or a test script that gives you a good overall average performance.
Now, how do you get this tool? It's more than just theory. It's available for IBM RS-6000's, although I don't remember what they call it.
I believe a variant of this is available in the Metrowerks Codewarrior development environment for PowerPC (CodeWarrior also supports Windows, Linux via GCC and lots of embedded systems but I believe the code reordering is only available for PowerPC).
CodeWarrior provides both an IDE (on Windows there's a choice of MDI user interface or Mac style with a global menu bar and free windows, which makes me much happier when I program on Windows) and it also provides command line tools, including the entirety of MPW with mwcc preinstalled so you can do "make" style builds on the MacOS (but with a weird makefile syntax).
I don't seem to find any mention of this on Metrowerks' website. I'll ask their friendly support guy if I'm correct about this.
Perhaps you're lusting over using this for Linux. It would certainly be interesting to try using this on the kernel - build the kernel, boot the machine off it, run it for a while under a normal load while you run the instruction pointer sampler, then reorder the instructions in the kernel and boot off the new kernel and you run faster!
This would probably be easiest to do on PowerPC Linux given the availability of published information from IBM and Apple about it, but I don't see why you couldn't do it for any instruction set. Some would just be harder to parse or rearrange correctly than others.
Damn web browsers - the web is a horrible platform for delivering applications. I fumbled some mouse clicks in my original browser and lost the first draft of my post. Any self-respecting GUI app would have said "save changes before closing?" but web browsers don't do that with the contents of a form!
Anyway, what I wanted to say was that high-tech is an expensive business and high-tech talent is hard to come by, the people who have the talent have to work long and hard to get the skills they possess and so they deserve to be richly rewarded.
If your business model does not allow you to pay your employees fairly and still remain profitable, you need to reevaluate your business model.
One suggestion might be to shut down your business and sell real estate or something.
Another suggestion would be to provide the training in command-line interfaces to your Mac OS X techs, and continue beyond that to cover Unix training of all sorts, so you can take on customers who are running "dot-com" web applications and are likely to be willing to pay more for service, and require it in higher quantities, than the typical home, education and small business consumer that is going to be using a Mac.
You should bring this question up in Apple's forums too - it's something Apple needs to address, because if end-users aren't going to be able to get their Macs serviced because all the techs have taken higher paying jobs doing something else, then Apple's not going to be able to sell Macs.
I've been a consultant since April 1, 1998. I was hating life for years before that, but my life as a consultant is rapidly closing in on the longest job I've held with one company - my own.
Speaking as one company to another - here's everything I know about finding clients - or everything I knew at the time I wrote it, it could use some updating:
While a little off-topic, some of you might be sitting around wondering how best to convince your boss to give you some training.
While it is often in your employer's best interests to train you, and you should evaluate opportunities for training when selecting a new job, don't ever allow yourself to lapse into the belief that all of your training is your employer's responsibility.
At the very best, your employer will train you for what is required for you to perform your current job, or to allow your company to take on tasks that no one knows how to do yet. You won't be trained in things that will allow you to advance out of your current rank within the company, to find a better job at a new company - or importantly, to recover from losing your job.
Think you can't be fired? Well, maybe so. But your company could tank or lose enough money you have to be laid off. Always be prepared for this.
As a consultant, I keep canceled checks and receipts for technical books that I purchase for my own self-training. Most of my training comes from reading these books, websites on programming, participating in newsgroups on programming topics of interest to my work at hand or future work I'd like to do, and contributing to open source projects like the ZooLib cross-platform application framework.
As a self-employed businessperson, I can deduct my technical books as a business expense, so I know how much I spend each year on my books. In 1999, I spent about $750 on technical books alone, in 1998 I spent about $250.
You should spend a significant amount of your free time when you're away from work doing self training. Otherwise you may find that your skills are regarded as out of date and you're not able to get a job, or you cannot get a job with pay appropriate to your level of experience - fifteen years of experience in a language no one uses anymore won't get you anywhere, but fifteen years of experience as a programmer where you've picked up a new language and a few new API's each year and you'll be very salable.
Slashdot Mirror
Besides taking an enormous amount of money for doing very little real work (do you really think recruiters read a candidate's resume before they submit them?) many of them are either dishonest or even if they try to do the right thing they do not have the technical background to be able to separate the good candidates from the bad ones.
Your time will be much better spent if you find the candidates yourself. Perhaps you could hire a non-technical work-study student to use a search engine like Google to locate resumes for you. Then screen them and call them personally.
As a software consultant I cannot emphasize enough how much more carefully I pay attention to contacts from actual clients than I do from recruiters (or from potential employers, back when I was looking for perm jobs).
For my own policy about how and why I don't deal with recruiters, please read:
Important Note to Recruiters and Contract Agencies
I have intended for a long time to put up a page addressing how employers can find technical talent. I haven't done that yet, but in the meantime you can find out how I find clients and figure out the inverse to see how you can use the web to find programmers:
Market Yourself - Tips for High-Tech Consultants
Michael D. Crawford
GoingWare Inc
You'll find some discussion about interoperability here.
Also see Speak Freely's development plans.
Michael D. Crawford
GoingWare Inc
What you get is transmitted as 8 bits, although since it's mu-law encoded it's approximately as good as 13 bits. But it has only three kilohertz bandwidth.
The audio quality of the modern telephone was decided decades ago as basically what was required to make speech easily intelligible, but not what would make it enjoyable.
It is not really within the telco's power to change that because all of the equipment from one end to the other, as well as all of the communications protocols and software are pretty hardwired for that limitation.
Many VOIP products observe this limitation and in fact are often not as clear sounding as a real phone, either because they need to work over a 28.8 modem, or because you're using a commercial carrier (even though it's over the internet) who doesn't want to pay a lot for a lot of bandwidth for high-quality calls.
This was my experience when I got an "Internet Calling Card" which worked just like a regular calling card, but the voice was streamed over the net in the middle. The audio quality was terrible, much worse than a telephone, and my then-girlfriend (now my wife) asked me to stop using it as it disrupted the closeness of our conversations.
I was investigating all the options a couple years ago, as I was in California and the woman who is now my wife was in Nova Scotia. I eventually settled on AT&T One Rate International because her 486 wasn't powerful enough to run VOIP.
But these days we have powerful processors and fast net connections. I believe that it is within our grasp to have two-way voice conversations with 128 kbps streaming MP3 with real-time compression.
Just voice over IP isn't going to win that many people over if all they're saving is some money, because most people don't make that many phone calls that the expense is worth the extra trouble. But imagine if they could get CD quality sound during their conversations!
And there would be nothing the telcos could do about it because they would be hamstrung by their legacy technology.
Probably it would be better to implement this using Ogg Vorbis so there would be no patent issues.
And I'd like to suggest that it be built with the ZooLib cross-platform application framework so clients could be built for Mac OS, Windows, Linux and other Unix variants and BeOS from the same codebase - note ZooLib includes networking.
Ah, but not UDP networking. Not yet...
Michael D. Crawford
GoingWare Inc
The bandwidth required for a voice quality phone call that has been compressed by a modern voice compression algorithm (such as one of those available in Speak Freely) will be much less than someone using Napster, Gnutella or browsing an, uh, "image archive".
A good voice over IP product will work fine over a 28.8 modem. I know this because this is how I used to talk to my brother in law from California to Newfoundland.
You do occasionally suffer some dropouts or delays, but it's pretty tolerable, especially if you have a higher bandwidth connection, like at least dual-channel ISDN or 128 DSL. But still that's pretty modest as net connections go these days.
Probably your biggest concern is to make sure your ISP's connection to the internet is fat enough to support all their customers. Once it gets on the backbone its insignificant.
What I would like to see is voice over IP where the compression algorithm was streaming MP3, and we could have high-fidelity audio speech conversations at 16 bits and 44 khz. There's no reason we should have to deal with crappy 8-bit voice with 3 khz bandwidth in this day and age. But even this wouldn't require a terrible lot of bandwidth.
Michael D. Crawford
GoingWare Inc
In many respects it is the best VOIP package available, because source code is available (public domain, which doesn't fit the stricter definition of an open source license), it allows a choice of both transmission protocols and compression algorithms, so you can adjust each for your particular setup to get the best results, and it offers strong encryption (a non-encrypting download is available for places where that's illegal).
The main disadvantage is that because of all the options it is rather difficult to use. And because of some architectural features of Linux, it's hard to get working at all under Linux (but it can be done).
Usually what you need to do is learn how to use it, then get someone on the other end at a computer where they have both the telephone and internet available at the same time, and talk them through it. But I have worked with Speak Freely with novice users after giving them a little while of instruction.
It also has ICQ integration and if you have a full-time net connection you can use it in answering machine mode.
Michael D. Crawford
GoingWare Inc
It only requires very basic support from the underlying graphics subsystem for its GUI to work, so it can be bound to a new platform pretty quickly.
At the present time, it supports Mac OS, Windows, BeOS and POSIX platforms with XWindows (such as Linux). It enables you to write a single C++ codebase and build native executables for all those platforms from it.
I've had in mind building my own Linux distribution that would be all GUI with no command-line tools except for daemon services - all the configuration would be done through GUI kind of like the preferences under the BeOS. This would have a simple graphics subsystem that would be the minimum required to bring up ZooLib on it.
It wouldn't be aimed at the kind of user who wants command-line and XWindows, but would be very lightweight (could be used on a handheld, for example).
Michael D. Crawford
GoingWare Inc
Also see my web pages:
-
Market Yourself - Tips for High-Tech Consultants
-
Important Note to Recruiters and Contract Agencies
Best of Luck,Michael D. Crawford
GoingWare Inc
Michael D. Crawford
GoingWare Inc
I'm not sure, but I think only citizens of CERN member states can be CERN staff members, and the U.S. is not a member state, but many american universities participate in CERN experiments and so you can go as a staff member of an american university - I did, as an undergraduate student, I did my senior thesis work at UC Santa Cruz at CERN this way.
Physicists have some strange ideas about what constitutes good software practice though. I try to politely correct this in this paper which I wrote for my experiment at CERN, proposing we scrap our FORTRAN codebase and rewrite it in C++.
Geneva's a little expensive to live in but if you work at CERN you can live in either france or Switzerland. (The particles have to show their passports twice each time around the accellerator ring as it crosses the border). I lived in France and found it very affordable.
Michael D. Crawford
GoingWare Inc
I cannot imagine what you could be talking about, Live Picture being slow. Compared to the competition, it is blazingly fast. You could work with much larger files on much slower machines with less memory than has ever been possible with Photoshop or GIMP. Yes, in part it gains this speed by rendering only at screen resolution and deferring all time consuming processes until all the edits are done and you build to a final tiff file.
But this required incredible sophistication in the program.
I probably should clarify it in my resume as you really can't see what I actually did on Live Picture, but I didn't write the thing - almost all the work I did on it was debugging with a little bit of performance tuning. In particular, I fixed bugs towards the end of the 2.6 release and then I did all the engineering in the 2.6.1 release pretty much by myself, entirely debugging a codebase of 70 MB of C++ source code. Yes, 70 megabytes.
If you think intel hasn't done anything amazing I suggest you compare a Xeon to a 4004. Mistakes do happen, the fact is even for all of Intels mistakes the errors in hardware are much rarer than errors in software.
Why was it that Intel got all the heat for the bugs in their chips but Microsoft doesn't? Why should software be held to lower standards than harware?
While Live Picture was a very sophisticated product, I feel the company was poorly managed. Please see my resignation from Live Picture.
Michael D. Crawford
GoingWare Inc
I want to apologize, I wrote quickly and when I said "programmers are lazy" that came out saying "all programmers are lazy". I more meant to say that the programmers who write bloatware are lazy.
That's not the only reason for bloatware. You can have hardworking programmers who are hamstrung by management. But I think the reason is important in practice.
Michael D. Crawford
GoingWare Inc
I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:
This was back in my bad old days of being a college dropout, hungry with no idea what I was going to do for a career. I told him I thought that would be a terrible place to work, the boss would always be bugging you to work harder.But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.
And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)
I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.
I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?
I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.
Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.
My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.
While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.
A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?
I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.
The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.
At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.
I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.
Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.
My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks
Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.
Michael D. Crawford
GoingWare Inc
I'm typing this from my workstation at my client's office, a web application company (I've clocked out). I'm using whatever Netscape came from the Debian site when I updated my software on Monday when I started.
Read about my laptop which was my main development machine for most of the last year. It boots NT, Slackware and BeOS.
You can read my resume - note the long list of products I've shipped, and keep in mind I haven't been keeping that list up to date. See the long list of projects I've done in the two and a half years I've been a consultant.
Note that among the jobs I've held was Senior Engineer at A Big Fruit Company where I held the role of "Debug Meister" - I did low-level debugging and in fact performance tuning of the Mac operating system.
When a tester found that an application would crash under a new system build and they didn't understand what component was at fault, it came to my team (Traditional OS Integration, formerly known as the Blue Meanies). We would track down the bug and assign it to the right engineer or fix it ourselves.
Note that sometimes, probably half the time, the bug was due to a third-party app bug, and we determined this purely by running MacsBug, an assembly level debugger, inside the app and system software. We had the entire Mac OS source code at our disposal but this wasn't usually readily available when you were visiting a crashed Mac at a tester's cube so you just had to know your MacBug.
I use and contribute to open source. My latest effort was aiding the author of the ZooLib cross-platform application framework in releasing his library under the MIT License; I worked with Andy Green for a year to test his code by developing a product with it and led a beta test of developers who also developed products with it.
I found ZooLib to be an incredibly enlightening example of well-architected, efficient and compact code for what it does. Just using it and reading the source code increased my own abilities as a programmer and architect tremendously.
You can read some of my thoughts on the business and technique of programming at GoingWare's Bag of Programming Tips
Linux is better than most as far as efficiency is concerned, but don't get me started about reliability and ease of use.
As for what I think is a well engineered OS, try the BeOS but you don't want to get involved with the company.
Read why I think developers need to take back control of their lives from operating systems vendors and how I think they ought to do it. If you really want the full-bore opinion, read The Cross-Platform Manifesto
So yes, I am in fact a developer, thank you. It's just that I maintain high standards and I like to encourage others to do so as well.
Michael D. Crawford
GoingWare Inc
This leads to the ridiculous situation that an old computer runs slower and slower as new software is loaded on it, until you finally have to buy a new one just to run at all.
It's not just that you have the perception that your computer of old is running slower than the new computers because it was less zippy when you bought it, but because the regressive performance dehancements of operating systems and bloated applications really do make your computers run slower.
Note that I used to run SlackWare and Apache on a 100 MHz 486, serving up web pages (admittedly with a light load) while I used X at its console - and it worked fine. But when I loaded Windows 95 on it it was dog slow. There's no question of running Windows 98.
I had a 233 MHz Pentium II with 32 MB of Ram that I ran BeOS 3 for Pentium on. It worked great - I shipped Spellswell for BeOS Intel with this. But when BeOS 4 came out and they switched to Elf format, I had to upgrade to 96 MB because I couldn't run a compile and read my email at the same time.
Later I installed a near-final beta of Windows 2000 server on this machine. I intended to use it to develop a Java GUI app under CodeWarrior for Windows. To get the machine to run at all - not even running CodeWarrior - I had to add another 128 MB of RAM for a total of 224 MB. The machine was dog slow even after the memory upgrade.
There is no excuse for this. New features should not come at the expense of performance, and each new release of both operating systems and applications should be both faster and take up less space, not more. If substantial new features have been added then there may be cause for a little more code size but certainly not what we see in practice, such as what was listed in the Netscape 6 review.
Why does this happen?
One thing is because programmers are lazy, and if their code runs slow they assume the user will just get a faster machine. But friends, the user wants to buy fast hardware so they can actually run fast, not just so they can run at all.
Pressure to ship a commercial product makes managers fail to support efforts to do substantial performance tuning, especially tuning that is not localized but would require substantial rearchitecture.
And finally a lot of people just don't know how to architect or code. I think we could all benefit from learning and writing some assembly, so we could really understand what our software is doing.
Maybe then we could strip out some of the thick layers of software bureaucracy that lies between the user and his cpu.
Michael D. Crawford
GoingWare Inc
It works pretty well software-wise, but two basic problems. NT4 doesn understand hard drives larger than 8 GB when you run its installer CD, with the unfortunate result that it ate my windows 98 installation that came preinstalled. Had I to do over again, I would have done a Norton Ghost backup image before trying anything.
NT4 does work with the large hard disk once you install the service pack and you can resize the partition with System Commander, but then the Emergency Repair disk process won't work. Someone in a newsgroup told me how to deal with this but I didn't understand it and would like to know how to do an emergency repair while booting of a CD that has already had the service pack applied, and that will install files with the service pack applied also.
I got the accellerated X server to work at first but lost my XF86Config after the hard drive consumption.
The happy news is that the BeOS recovered most of my windows data files.
The other issue is that the hardware has been unreliable. There is a fragile ribbon cable in the DVD drive that gets creased when you push the tray back in and jams it; sometimes it sticks the drive shut and you have to pry it open with a paper clip.
Also sometimes some random key will refuse to type for a few days and you have to keep banging on it to get it to type.
Finally, the connection between the power adapter and the socket on the laptop became unreliable so it wouldn't reliably charge. At first it would work if you fiddled with it and then left it sitting in one position during use, but this prevented you from using it for long on your lap.
Eventually it failed entirely and I needed to send it in for repair. But I was on an extended visit to Canada and even though Compaq has a Canadian subsidiary with Canadian service, this was a U.S. model purchased in the U.S and they wouldn't service it in Canada. They also wouldn't send the shipping container to Canada, or ship it back to Canada.
The end result was, because this was my main development machine and my business ground to a halt when the laptop failed, I ended up buying a custom built desktop machine from all standard OEM components.
I specifically wanted the ability to replace any failed part in the desktop myself from parts I could readily get at a computer store - you can usually do this with PC's bought at a "screwdriver shop" but not necessarily a name brand desktop PC, not just because you might void the warranty but because they use nonstandard parts that don't allow for OEM replacements that will fit.
I got compaq to send a replacement power adapter to my dad in Washington state and he expressed it to me in Canada - at about the cost of buying a brand new adapter - and with this, if I had my wife adjust it (with her steadier hands) we could get it to charge. This allowed me to recover my work from the laptop so I could install whatever files weren't backed up on my new desktop machine.
Then I waited about two months to fly home to the United states for Thanksgiving, where I arranged for compaq to send a shipping box so I could express the laptop in for warranty repair. I think they said they'd install a new system board, although they could just solder on a new plug.
They promised 7-day turnaround on the repair and free express shipping both ways. I flew to another state for some contract work so when my parents get the laptop back they'll have to forward it to me at our expense.
Thanks Compaq!
Michael D. Crawford
GoingWare Inc
I wrote a web page a long time ago about why I quit Mac programming and took up the BeOS instead
But after too many years of too many broken promises from Be, Inc. I spoke up one too many times on BeDevTalk and got forcibly unsubscribed after being one of Be's most loyal developers, and winning an award for shipping one of the few actual commercial BeOS applications.
I haven't had any first-hand experience with Microsoft but I have heard many horror stories that didn't make it into the Microsoft/DoJ antitrust trial. Remember that one of DoJ's problems was getting executives to testify publicly - but there's no shortage of developers willing to confide privataly about how Microsoft has screwed them.
One very public example is Stacker Software. They invented filesystem compression. Microsoft offerred to purchase Stacker, and examined their source code under nondisclosure while doing due diligence. Then they canceled the acquisition and came out with their own implementation of filesystem compression. Stacker sued and won over $100 million.
For the past year I have been working with the ZooLib cross-platform application framework. It allows you to write a single set of C++ sources and build native executables for Mac OS, Windows, BeOS and POSIX flavors that provide XWindows (such as Linux).
I believe ZooLib represents one important part of a strategy for freeing ourselves from these broken promises.
Please read why I think ZooLib is good for the community
Note that I include quotes from Judge Thomas Penfield Jackson, who presided over the antitrust trial, one how Microsoft felt that it was so important to put a stop to cross-platform API's that it broke the law to interfere with their widespread use.
Jackson makes the same observation in his rulings that I have noticed in the past, that API and OS vendors work very hard to get developers to code to the native API rather than using a portability layer, as doing so locks the developer into the platform.
Michael D. Crawford
GoingWare Inc
Sometimes those decisions are forced on a company against the wishes of even the senior management by the stockholder, venture capitalists, or the perceived interests of wall street.
Please read:
The Valley is a Harsh Mistress
Michael D. Crawford
GoingWare Inc
It occurred to me that profiling a kernel like I suggested is a problem because the kernel can disable interrupts (as when handling an interrupt) and so even though you might be able to sample to some extent it may be hard to get good results. Also you crash the machine, etc.
But I recall reading recently here that someone had the Linux kernel running as a user space program. So you boot a real linux kernel, then run a fake kernel inside of some kind of hardware emulator or something. It was suggested to use this for kernel development - you could quit the kernel and restart it much quicker than rebooting and there's less danger of corrupting your machine, if your test machine is also your user machine, as is all too often the case.
But with this you could easily profile a userspace kernel and be interrupting it from the outside without the test kernel being aware its being interrupted, as those interrupts are not handled by the test kernel, but external code.
Of course, you'd want this to work for ordinary programs first. Let the kernel be your fourth year project!
Michael D. Crawford
GoingWare Inc
Unfortunately the company was poorly managed - one major investor and for a while the CEO was former Apple President John Sculley. I discuss this in:
The Valley is a Harsh Mistress
which I'd suggest is good reading for anyone thinking of starting a company, or working at a startup.
But anyway, back in 1996 or so Live Picture 2.5 could open multiple 200 megabyte images and composite them together in sophisticated ways on a 68040 Mac with 64 MB of memory or less - with photoshop you need twice as much physical ram as your open files plus a scratch disk also.
With Live Picture, the response was always snappy. Just try opening a 200 MB image in Photoshop and rotate it two degrees. Go have a coffee. In Live Picture, you see the results now and can continue working.
Yes, there is a slow "build" process to save the end result to a TIFF at the end of the day but this can be run unattended, for example overnight and in a batch process.
Further, with Photoshop there's only one chance at undo. With Live Picture, it had essentially infinite undo.
The need to compete with Live Picture is why they added layers to Photoshop.
Photoshop does the job well, admittedly, but it does it in a simple way, through brute force. Live Picture used incredibly sophisticated algorithms and very deeply complex code. It was my job to do the engineering for the Live Picture 2.6.1 release, which was entirely a debug release - I was working with 70 megabytes of C++ code that took over an hour to compile on a Mac 8500/150.
You might also want to read my resignation from Live Picture.
Michael D. Crawford
GoingWare Inc
Give Google a try too
Modify the search terms to include the app you're looking for but include several others to be sure you've got a crackz site.
I discuss this in Modern Technology and the Death of Copyright
Yours,
Michael D. Crawford
GoingWare Inc
The first emulator I understand was basically an interpreter, sort of like the Java virtual machine but where the "bytecodes" are 68000 instructions (I'm not sure which actual microprocessor was emulated, maybe it was the '020). Not real fast because you have to decode each instruction every time you hit it, but it was well-written and reliable.
Then there was the dynamic recompilation emulator which I believe first appeared in the first PCI Macs (like the 8500/120) and System 7.5.3 (not exactly sure if that's right but thereabouts).
This was like the JIT - "Just in Time" compilers for Java, it would compile 68000 code to PowerPC code and then execute the PowerPC code natively.
This was a shipping product I believe in late '95 and I'm pretty sure Apple was not the first to do such a thing.
Note that on the Mac they were unable to rewrite much of the low-level OS code from 68000 to PowerPC, at least not initially, and so a lot of system software remained emulated and probably still does. Also it is very common for Mac applications to install interrupt time tasks and many of those are legacy 68k apps and it would be innefficient to switch instruction set architectures all the time.
I seem to recall it takes something like 200 PPC instructions to switch from one architecture to the other so if you're already in 68k code and you're about to run a small routine it's best to remain emulated.
It is possible to write "fat" code that provides both options and the machine will use whichever one it's currently running - this is common for "Extensions" which make "fat patches" to OS calls, and many OS calls are "fat traps".
For this reason, the Classic System 7 MacOS (of which Mac OS 8 and OS 9 are examples, but Mac OS X is a whole different thing) handles hardware interrupts in emulated 68000 code.
Interrupt handlers and device drivers may be written in 68k code or PowerPC code as you like and run on a PowerPC machine.
The dynamic recompilation emulator I think emulates an '040 with its instruction cache issues, and it correctly handles hardware interrupts that happen in the middle of running a chunk of recompiled code.
Early Mac apps very commonly used self-modifying code. For example, if a "code resource" was expected to be loaded into memory and used by the system, many applications would load a small stub that jumped to an offset that was a placeholder. Then they would write an address in the running program code into the placeholder after it was loaded. This kind of thing screwed up on the 040 because you were writing to code using data instructions, but there were lots of workarounds such as the painful decision to flush the data cache after calling BlockMove - and the addition of the BlockMoveData call which wouldn't flush the cache.
Also note that an application (or any code) can install callbacks that are written in 68k, PPC code or fat, and this code will be correctly called from the OS or toolbox, whether it started in 68k or PPC. This works because of something called a "routine descriptor" that is a compact description of a function API - it handles Pascal vs. C calling conventions, instruction set architectures, and the possibility of providing alternative entry points for each architecture.
On 68k there is a "trap" - a defined illegal instruction, that causes a jump to an exception handler. The exception handler reads in the routine descriptor and does the right thing. On PPC, you pass the routine descriptor to the CallRoutineDescriptor function (or something like that).
68k code is legacy and knows nothing about routine descriptors, but the emulated processor handles traps correctly. PowerPC being released after the routine descriptor architecture was all implemented, developers can easily put it directly in their code. There are headers with macros that make most of this transparent so you can compile both kinds from one set of sources.
Michael D. Crawford
GoingWare Inc
This was in either late '95 or early '96 - but the IBM work on this had been around for a while by the time I read the paper.
This technology is widely available now - read all the way to the end to see how you can try it out.
If you have a jump to a certain offset in a routine, you can move the code where you jump to elsewhere in the file and change the offset you give in the jump. Complicated, because you need to parse RISC machine code, but doable.
It's made a little easier by PowerPC instructions always being fixed at 32 bits with no extension words (a side effect of that is that there's no way to load a 32-bit constant into a register with a single instruction, which makes it hard to scan machine code by eye for constants in an assembly debugger.)
This has the effect of speeding up the overall program execution because you group frequently used code blocks together in the executable file, and also in memory once it's loaded. You may find less-commonly used branches of an if-statement put miles away at the end of the file, so that you jump a long ways away and then back in sometimes, but this isn't a big deal because all the frequent cases flow straight along.
The reason this is a big win is twofold. First, you reduce virtual memory paging and the code resident in physical memory because less commonly used code is all grouped together and just sits idly paged out on disk; that which is taking up valuable physical RAM is of a minimum size and being used actively.
Also (and more importantly in small programs, and in CPU-bound cases), you make more effective use of your processor's code cache.
This is because jumping over an uncommonly used branch may load a few unused instructions into the cache at the beginning and end of the branch that's not taken - cache lines (blocks) are of a fixed size and are always aligned by the cache block size, so if you have 32 byte cache lines then the start of any cached code falls at a physical address that is divisible by 32.
If you run even one instruction into the address rangle, you load 32 whole bytes of code into the cache, deleting 32 bytes of code that might be useful later, then if your code is not optimized this way you'll just end up jumping over most of it.
Many people who are trying to make their programs run faster would benefit from knowing more about how the cache works. Gary Kacmarcik's Optimizing PowerPC Code has a good discussion of this that will benefit anyone who programs on modern microprocessors - not just PowerPCs. And while Kacmarcik emphasizes PowerPC assembly, most of the benefit of improving cache use you can do from C, C++ or another higher level language.
The way the profiler works is that an interrupt-driven task is used to check the instruction counter at frequent but random intervals. The samples are saved to a file for later analysis, then a postprocessor makes a histogram which gives the number of samples per basic block of instructions.
(A basic block, essentially, is any code that falls between a pair of curly braces if it came from original C source code. It's more complicated than that in practice but basically it's a chunk of machine code that has one entry point and one exit. It's possible to analyize machine code with a program and divvy it up into basic blocks.)
Then basically what you do is sort the machine code, with the most frequently used basic blocks coming earlier in the file.
Note that the profiling process depends necessarily on the use to which the program is put during the sampling. For best results, you might actually want to prepare several seperate binaries of the same program, each optimized for a different purpose. Or you might want to construct test data or a test script that gives you a good overall average performance.
Now, how do you get this tool? It's more than just theory. It's available for IBM RS-6000's, although I don't remember what they call it.
But if you can spare the cash for an iMac you can get it included with the Macintosh Programmer's Workshop - MPW. The particular tool that's used for this is called MrPlus, which is discussed in Apple's Technote 1174 and Technote 1066
I believe a variant of this is available in the Metrowerks Codewarrior development environment for PowerPC (CodeWarrior also supports Windows, Linux via GCC and lots of embedded systems but I believe the code reordering is only available for PowerPC).
CodeWarrior provides both an IDE (on Windows there's a choice of MDI user interface or Mac style with a global menu bar and free windows, which makes me much happier when I program on Windows) and it also provides command line tools, including the entirety of MPW with mwcc preinstalled so you can do "make" style builds on the MacOS (but with a weird makefile syntax). I don't seem to find any mention of this on Metrowerks' website. I'll ask their friendly support guy if I'm correct about this.
Perhaps you're lusting over using this for Linux. It would certainly be interesting to try using this on the kernel - build the kernel, boot the machine off it, run it for a while under a normal load while you run the instruction pointer sampler, then reorder the instructions in the kernel and boot off the new kernel and you run faster!
This would probably be easiest to do on PowerPC Linux given the availability of published information from IBM and Apple about it, but I don't see why you couldn't do it for any instruction set. Some would just be harder to parse or rearrange correctly than others.
Stop drooling and start studying.
Michael D. Crawford
GoingWare Inc
Anyway, what I wanted to say was that high-tech is an expensive business and high-tech talent is hard to come by, the people who have the talent have to work long and hard to get the skills they possess and so they deserve to be richly rewarded.
If your business model does not allow you to pay your employees fairly and still remain profitable, you need to reevaluate your business model.
One suggestion might be to shut down your business and sell real estate or something.
Another suggestion would be to provide the training in command-line interfaces to your Mac OS X techs, and continue beyond that to cover Unix training of all sorts, so you can take on customers who are running "dot-com" web applications and are likely to be willing to pay more for service, and require it in higher quantities, than the typical home, education and small business consumer that is going to be using a Mac.
You should bring this question up in Apple's forums too - it's something Apple needs to address, because if end-users aren't going to be able to get their Macs serviced because all the techs have taken higher paying jobs doing something else, then Apple's not going to be able to sell Macs.
Michael D. Crawford
GoingWare Inc
I've been a consultant since April 1, 1998. I was hating life for years before that, but my life as a consultant is rapidly closing in on the longest job I've held with one company - my own.
Speaking as one company to another - here's everything I know about finding clients - or everything I knew at the time I wrote it, it could use some updating:
Market Yourself - Tips for High-Tech Consultants
And for everyone to read - you ever deal with those pesky headhunters?
Important Note to Recruiters and Contract Agencies
Michael D. Crawford
GoingWare Inc
While it is often in your employer's best interests to train you, and you should evaluate opportunities for training when selecting a new job, don't ever allow yourself to lapse into the belief that all of your training is your employer's responsibility.
At the very best, your employer will train you for what is required for you to perform your current job, or to allow your company to take on tasks that no one knows how to do yet. You won't be trained in things that will allow you to advance out of your current rank within the company, to find a better job at a new company - or importantly, to recover from losing your job.
Think you can't be fired? Well, maybe so. But your company could tank or lose enough money you have to be laid off. Always be prepared for this.
As a consultant, I keep canceled checks and receipts for technical books that I purchase for my own self-training. Most of my training comes from reading these books, websites on programming, participating in newsgroups on programming topics of interest to my work at hand or future work I'd like to do, and contributing to open source projects like the ZooLib cross-platform application framework.
As a self-employed businessperson, I can deduct my technical books as a business expense, so I know how much I spend each year on my books. In 1999, I spent about $750 on technical books alone, in 1998 I spent about $250.
You should spend a significant amount of your free time when you're away from work doing self training. Otherwise you may find that your skills are regarded as out of date and you're not able to get a job, or you cannot get a job with pay appropriate to your level of experience - fifteen years of experience in a language no one uses anymore won't get you anywhere, but fifteen years of experience as a programmer where you've picked up a new language and a few new API's each year and you'll be very salable.
Also see my advice Study Fundamentals not APIs, OSes or Tools.
Michael D. Crawford
GoingWare Inc