Consider running Virtual PC from Connectix. While it's not as fast as running directly on the hardware it's stable, well documented, and generally fast enough for most folks on any reasonably modern Mac.
One of the advantages I appreciate about it is the ability to keep my Mac environment while popping in & out of others at need, no reboots required. At various times I've had RedHat & Mandrake installed, Netware, Win9x, and several NTs. Double-click - I'm running NT. Double-click - I'm in Netware. Double-click - hey it's Linux! Click - I'm back to my MacOS which never stopped running. No messy partitions, no boot managers, no shut-down-everything-then-reboot-into-whatever.
Moving from hardware to hardware is simply a matter of reinstalling VPC then copying the settings & disk image. I keep a small hub on my desk so I can drag these images between my desktop & laptop without burdoning the office LAN (routinely copying a 1 GB file on shared media isn't really a nice thing to do to one's office-mates)
Tips for running VPC: Memory and disk space, you can't have too much of either. A stock iBook would be crowded with VPC, really consider bumping up whatever you get as much as reasonably possible.
Actually I was talking to the owner of a small software company that makes software for a niche market & this is exactly what was considered.
Their application runs under BSD & 'till recently they've been requiring their customers buy a standard distribution. They've now expanded their support to the various free BSDs and are now considering MacOS X.
As their customer base is non-technical folks with limited support resources something like MacOS X would seem a logical step. However they're unwilling to commit resources and fork their product until MacOS X has been out in the market awhile, appears successful & enough customers seem willing to adopt it.
One interim strategy we discussed was simply continuing to run their application under an X Server and pretty-much ignoring the whole MacOS X-side of things until they've determined how far they want to go with this.
Generally one can get a significant discount from MSRP if one licenses only the required parts of a product, limits it's use to running the licensed application, handles product support & is willing to include an upgrade offer in the packaging. If the X Server vendor is open to licenses like this then the cost per unit could be acceptable.
Thus their product could ship almost immediately and with the exception of the added X Server install and some other "MacOS-X-ifications" (graphical installer, file locations, frameworks, icons) would be the same as their other releases. Indeed we guesstimated it would take 2 or 3 days to modify the unix side of things and another 2 or 3 to produce the MacOS X side.
This is exactly the sort of thing Apple probably worries about. Ultimately it might be a win for them but in the meantime they'll have a quasi-ported-application runnning on their shiny new OS.
As to concerns regarding the supplier, well, yours aren't new ones. Generally one can request an audit of the company to determine it's health, invest in things like a code-escrow policy, have alternative strategies in place (I expect there won't be one X Server vendor for MacOS X forever), etc.
Finally these concerns are less strong then they might be otherwise as this would intended as an interim step. Should the product prove popular then the full port to Mac OS X would take place with the Aqua GUI etc. and then the licensed X Server could be dispensed with.
Your issue seems to be your employer has limited your access to the internet. Unless you've left something out of your message it's irrelevant whater or not you're on a Mac.
As I see it you have four choices:
Accept that your employer has made a decision about how they want their computers on their network used by their employees on time they're paying for to use their internet connection.
Speak to your Manager, IS Administrator, whomever is appropriate and request greater access. Be prepared to provide a business-relatad justification for the greater access.
Try and get around the policies that have been established, run various applications through non-standard ports etc. and generally subvert your employers policies. Don't be suprised the day someone twigs what you're attempting to pull and you find yourself abruptly terminated for cause.
Leave the company for someplace with policies more to your liking. Frankly if getting unfettered 'net access during working hours is so critical to you I'd worry about loosing perspective but hey, it's your call. I just wouldn't try to explain to a potential employer that you left your previous job for this reason...
Damn - posted instead of previewing. Well, there it is, warts & all - you get the idea. Honestly I'm not terribly interested in pursuing this discussion much futher anyway. Apple buying SGI seems extremely unlikely IMHO and 'what ifs' aren't particularly engaging.
What exactly would buying SGI bring to Apple? Are these things Apple couldn't develop for itself just as cheaply yet apply across it's entire product line?
Software-wise they're not a particularly good matchup. Sure they overlap in some ways but then almost everyone in that part of the market does.
Hardware-wise they've very little in common. Where SGI does have 'kewl stuff' it's not particularly applicable towards Apple's current hardware base (that I'm aware of.)
Customers, contracts, service & support, development engineers - SGI is hemmoraging all of those and again, none of them are very good matches for Apple's business model.
What Apple needs now is to improve it's hardware and solidify MacOS X.
In hardware Apple needs faster, more flexible motherboards. Faster CPU's would be great too but they can get away with dual (or more) PowerPC's as long as they're competively priced. Should PowerPC truly be stuck at a roadblock Apple could consider moving to Alpha. In no case are they going to succeed (ie profit) competing in the consumer or workstation x86 market - at least not in the near-future. Once the transition to MacOS X is complete and it's established Apple would do well to consider a Darwin-based x86 subset specialized for server duty, much like the MacOS X Server release of two years ago is used today but on a x86 hardware platform. I expect they'd treat it much like they do their '486-based AirPort today - the CPU is x86 but they don't make a big deal of it.
OS X needs to get out in the market and establish itself as a Unix peer. Once it gets some creditability as a stable Unix vendors can start porting over Unix-apps to it and customers can start weaning off of the Classic/Carbon codebase. With this transition Apple could begin to move into some of the server market making the same arguments MS makes for NT: one OS scalable for desktop / workstation / server. They'd be able to come up to speed rather quickly in the server space as the developers would be simply performing another Unix port with some added UI work.
Were I Apple i'd be looking to spend my money on a few things:
Improving the motherboard architecture. 100 MHz motherboard, ATA 100 drive connects, AGP 4x or 8x graphics, better built-in audio, etc.
Faster CPU's. 500MHz+ PowerPCs'. Two, four, even eight CPUs on a board. Possibly add Alphas to the mix.
Wooing developers to Darwin & MacOS X. Seeding hardware & software. Providing technical support where useful. Encouraging widespread adoption of MacOS X as at least an alternative for unix applications if not a preferred environment.
"albeit slipping somewhat" ? Is that like "a little bit pregnant" ? Lets go for words like implode, power-dive, collapse, crash-'n-burn, etc. SGI has at this point been plundered, passed over, beaten-up, and now being sold off to anyone who wants some of the meat left on it's picked-over bones.
Why would Apple, fresh from it's own brush with death want to purchase another ailing company, particularly one with such poor prospects?
Apple has finally gotten it's hardware habit somewhat under control. The original lean line-up has now ballooned but at least almost everything is being based on common motherboards. SGI would bring in a completely different set of technologies with almost no common elements.
Apple has also pared down it's software holdings. No longer does it try to compete with it's own applications but has spun off/shut down/de-emphasized most of those distracting and ultimately non-profitable lines of business. SGI would pull it back into those markets in a big way.
Finally, Apple is once again focussing on profitable markets, one where it can sell either enormous quantities of hardware (iMacs) or fewer but highly marked up ones (Cubes.) SGI doesn't fit into either category particularly well, nor does it's own category seem much longer for this world.
This appears to be a case of looking-for-a-buyer-for-SGI & not what-could-Apple-spend-it's-bucks on. Sure if gifted with SGI I'm sure Apple would be happy but $ for $ they'd be a lot better off spending their money on R&D to extend their own stuff into what's left of SGI's market.
How hard is it to look up something before posting? I mean, it's not like all of the relevant info isn't on the web or anything...
Apple's MacOS X does not come with an X Windows server. Apple has no intention of developing or releasing such a beast. Apple instead chose to develop a PDF-based display system called "Quartz" upon which runs their UI named "Aqua".
Tenon, a respected developer of Mac software, has developed an X Server that runs on MacOS X. This is significantly different from John Carmack's port of X to Apple's open-source OS Darwin (upon which MacOS X is based.) Tenon's X Server is driving the Quartz PDF-based display and utilizes the Aqua toolkits to produce a fully MacOS X-integrated display. In short anything run under Tenon's X Server is immediately available to the rest of the MacOS environment as just another PDF (cut-'n-paste, etc.) as well as appearing as Aqua-like as possible.
Thus with Tenon's X Server one can run a generic X application and it will appear as simply another Mac OS X application obeying as many of the Aqua UI principals as possible. Indeed with many X applications trivial changes will be required to make them appear to be native Mac OS X applications (mostly menu placements, dialogue boxes, etc.)
As one can imagine, this is both good news and bad news for Apple They undoubtedly welcome this product as it gives the connectivity they so sorely need; particularly in their important scientific research market where they're already fairly popular. On the other hand there is likely a fear that developers might 'port' to MacOS X by simply running their apps in a X term session (possibly a cut-down server licensed from Tenon) and not go native.
As to Tenon's other 'ports' - are they ports? Likely yes. Getting a unix application, particularly one already native to BSD to run under Mac OS X isn't much effort, if any. Constructing a native user interface for it, while not very difficult, does take time and some (presumably) skill. Since we already talk of ports to other such brother/sister OS's the same would seem to apply here. The argument is strengthened with the added effort of creating an Aqua UI and integrating other Mac OS X conventions which Tenon has done.
-- Michael
No affiliation with any Mac developer currently, nor have I ever purchased any Tenon product. However I do look forward to running their OS X Server.
I've had old voicemail accounts last at least five years after leaving (that was as-of a few years ago - I'd check again but I can't remember the extension) and email accounts from places I left over a decade ago still working.
In places I've managed one of my first changes has been to insist that HR put a message on a email distribution list every time a position is created (note this is often well before someone is hired but it gives my staff time to determine the future employee's needs), upon a hiring, and the instant they believe someone may or will be leaving. In these communications HR must specify dates and the appropriate managers to contact for direct instruction. I also put an emergency procedure in place for 'rapid-separations' where all of a person's accounts are identified, marked for immediate back-up, and locked down until the situation is clarified.
I generally drive these policies & procedures home by holding a meeting between HR, IS, and Legal with all of us asked to brainstorm on the awful things that could happen should we drop the ball on this. One can usually come up with some very nasty scenarios pretty fast. The folks involved also generally know a few real-life stories we've seen or heard of we can recount just to completely scare everyone into following these policies seriously.
What can really force these policies is privacy laws. Even though many would think that communications to someone via a companies resources would be properly a companies property this changes a bit once the person is no longer an employee. I'm not a lawyer but I do know that in most places one is on shaky ground continuing to allow the former employee's name to remain active in the email system after a reasonable amount of time. To have someone then go through a former employees communications, specifically any that are received after the employee is separated from the company, is very dangerous and just asking for a nasty lawsuit.
My own solution to moved-on employees has been to place an auto-responder on the email account indicating the person is no longer with the company, possibly listing the other person(s) who are now handling the former employees responsibilities, and referring all other communications to HR. Generally this will do for up to a year after which the account just becomes another generic dead one. For voicemail a similar procedure is used by closing the person's inbox and replacing their old greeting with a new one giving the new numbers to contact for various services.
Of course one can avoid many of these problems by encouraging the use of functional email & voicemail accounts. With these many messages go to "Department - Function" instead of individual persons. One can't (and oftentimes shouldn't) get rid of personal email accounts but by keeping much of the purely administrative email on the functional address list does. Utilizing this duplicate system can cut down enormously on mail-list administration and general administrivia.
Another problem I commonly run into is the 'legacy' account where someone has moved on but another simply assumed their accounts, oftentimes their replacement. This sort of thing leads to really confusing situations where one isn't sure who is using what accounts, which are active, and which are linked. This can become particularly problematic when trying to implement unified login systems.
Finally there's the nightmare of IS staff leaving. Oftentimes we know waaay too many passwords, particularly the 'deep-mojo' ones. To help expedite these transitions I generally try to keep a list of all the primary accounts (passwords stored seperately in a secure place)and a instruction sheet on changing them all at need. It's also simply good practice to discourage users from giving passwords to IS staff and simply requiring them to enter themselves when needed.
So what services do you have access to? I'll be more then happy to run the search for you but you can pay for your own copies. Doubtless a finance whiz like you subscribes to Bloomberg / FirstCall / West / etc.
What about running IPv6 on 9x/NT/2k? Anyone have any reports on it? How hard was it to get running? Did your apps play nice with it? How was performance? Who was there to talk to? Any practical immediate advantages? Are there any ISP's yet offering IPv6 support? What will AT&T @Home (is that their name this 24 hours?) do if I start running IPv6? Did the MS implementations interoperate with other vendors? Which one seems best under WinWhatever? Which one seems best overall (Linux/BSD/etc.)
Um - first off the reason there are no Mac clones is actually kinda an accident. IBM never intended for there to be clones of their PC's either (heck, they never even dreamt they'd be a big product!)
IBM PC clones came about because the BIOS they used was primitive and relatively easy to reverse-engineer in a legal fashion. The popular OS (there was originally a choice between DOS & the UCSD Pascal system) was licensed from MS under a non-exclusive contract. Thus once Phoenix came out with a good clone BIOS the market jumped from almost-alikes to out & out clones running a functionally identical BIOS and the same OS.
IBM sued folks for years trying to kill the clone market, then when it was clear they were unsuccessful they tried to come out with another 'standard' that they had complete control of. By that time however the architecture was entrenched & IBM simply moved themselves into a niche market from which their PC operations never really recovered.
On the other hand Apple put a large chunk of it's code into proprietary ROMs installed on the motherboard. These ROMs contained many of the routines critical to operating the Macs and they were both heavily legally protected and difficult to reverse engineer. There was no particular genius in this - it was simply how Apple built their boxes and it turned out to be fortuitous way of keeping their hold on their market.
Apple did have a licensing program, often incorrectly characterized as clones (in licensing the product is authorized under terms and the license holder is compensated - clones are simply legal knock-offs with nothing going back to the inventor.) The program was intended to supply Macs to markets Apple considered insufficiently profitable for it (Apple at the time had terrible supply management problems and an astonishingly high overhead.)
Unfortunately the licensees didn't remain focused on the small-margin educational market, super-high-end graphics market & burgeoning but very price sensitive foreign markets as originally intended but began to cannibalize Apple's high-profit mid/high-end domestic Mac market. As a result they began to cost Apple both in support, un-recovered R&D, and lost sales and thus were eventually unceremoniously killed.
Apple does have an advantage when it comes to close-coupling their hardware with their software. By making their own boxes they can design the hardware and software to compliment eachother. This is also a drawback as it limits the market to what Apple can develop & supply.
USB adoption came about when Apple needed to drop it's aging Apple Desktop Bus (ADB) and USB was a good match for the old technology (functionially they're very similar so it was easy to write shims for USB to operate in place of ADB.) Firewire/1394 was developed as a next generation SCSI and to correct the many mistakes Apple had made in it's originial SCSI implementation and then codified with (mis)use. The wireless inclusion was a bit of clever thinking on Apple's part and some great product engineering/cost negotiation resulting in a suprisingly inexpensive implementation (which humerously enough is based on a 486)
Wintel PCs have their own advantage in MS setting the WinHEC specifications and many, many companies optimizing their hardware production. This diversity makes for less optimization and greater support issues but it also makes for a much broader market and relatively faster pace of innovation.
Apple would be unwise to compete in the x86 market simply because they'd be horribly far behind when it comes to device support. In the 'sheltered' Mac market it's accepted that not third-party all devices are supported & cost more (conversely Mac users are furious when supported devices don't work flawlessly.) In the Wintel world everyone is expected to have WinX drivers and that's that.
Furthermore Apple commands a high premium for their Macintoshes simply because they're the only game in town. Were they to attempt to get the same margin on x86 boxes they charge on Macs they'd be laughed out of the market. To sell x86 PCs at a competitive price wouldn't recover their OS development costs and would cannibalize their traditional Mac platform sales.
Who would want a $2,000 PC selling for $3,000 runing MacOS X and a limited set of hardware options? I love Macs but this would be hard to swallow. Apple could consider using another chip (perhaps an Alpha) to justify/disguise their markup but it would still be difficult.
Then there would be that whole problem NT had with x86/Alpha/MIPS/PPC binaries and Lunix/BSD have with their own different hardware bases. It was tough enough for Apple when there were the M68020/M68030/M68040 and PPC issues (variations in memory management, floating point, and with PPC an entirely different architecture) leading to products that would run on some combinations of hardware & software but not others. This culminated with the 'Fat Binaries' for M68x/PPC applications.
Unfortunately as we've seen with other mixed-processor OS's (Linux being a good example) the whole process of supporting code on different processors is fraught with difficulty. Can you imagine explaining today to a Mac customer that some apps run on MacOS X PPC & other on MacOS X x86 and that the versions aren't the same?
Finally - Apple didn't 'steal' anything from Xerox. This is an old chestnut that's gone around for years and is patently false. If you do a bit of research you'll discover Apple had already settled on a graphical interface for their next-gen OS well before their visits to Xerox.
Certainly the Lisa folks were influenced by what they saw at Xerox but it was by no means a copy or theft. Indeed the concepts of much of what they eventully shipped were developed *before* their trips to Xerox.
Furthermore much of what they released was significantly different from what Xerox had (and yes I've used a Xerox Star extensively.)
Apple is a neat company and they've devloped some great stuff but they're not perfect. They've made some incredibly foolish, incredibly arrogent mistakes. They've also developed some amazing stuff and managed to pull their chestnuts out of the fire more times than any company has a right to.
Someone who know's Apple's business better then that durn Board of Directors... All these years the Financial Analysts have been saying the same thing: "Apple makes it's money on hardware". All these years they've been saying "They couldn't support themselves on the fees for their OS - the development & support costs would overwhelm them" - THEY'VE all been *wrong* and of course YOU are *right* !
How could we have all been so blind!
Please oh magnificent one - lead us into the light! Show us how only you can see clearly that which none of the investors can grasp, none of the company officers can delve, none of the stockholder percieve! For ony YOU oh amazing one shall humble those exalted bastions of capitalism and forever sunder Apple from it's hardware dependance and let it be reborn as a software company - profitably!
Oh - it's as if Rapture were upon us!
... and to think it happened on/. - what was Wall Street thinking not snapping you up...
Does this mean that we will get Microsoft Office for X which might work on FreeBSD? a few tweaks?
If by "a few tweaks" you mean recreating the entire Apple 'Carbon' environment and then getting it to work under X instead of Quartz then - sure.
The more honest answer is 'No' - or at least - "Not with MS Office 2001 for the Mac."
MS is not moving their Mac Office apps. to the Unix-side of MacOS X but rather tweaking the to run under the MacOS-derived Carbon environment. Thus aside from dropping some of the more difficult to support calls it's the same as it's always been. Indeed MS Office 2001 for the Mac won't even require MacOS X to run - t'll do fine on any Mac running MacOS 9x as long as the Carbon libraries are present.
The question comes what about after this next release? Will MS refuse to move to the Unix side of the OS, simply move only as far as the Cocoa side (neat Openstep-derived technologies) or go with Java (little chance.) Furthermore will they tie themselves to Apple's Quartz rendering/Aqua UI or write more generalized code that could be retargeted towards X Windows.
MacOS X will be able to run X apps if it has X installed. Apparently Apple is not shipping X with the OS. However there is already an excellent commercial X availiable that works under Quartz and fully integrates with the Aqua UI.
We go through this every time/. posts a MacOS X story.
MacOS X is not being developed for x86. Yes that was the plan for Rhapsody, MacOS's immediate predecessor. This was scrapped. Yes Darwin has been released as Open Source by Apple for the x86. Yes this is the base for MacOS X. No these are not the same things. MacOS X includes the Quartz rendering layer and the Aqua interface, the Classic, Carbon, and Cocoa environments, Quicktime, etc. Darwin may be the engine but that's *all* it is. It's unlikely Apple would release MacOS X for x86 since Apple is a hardware company and thus this wouldn't make sense for them financially. Yes you and many others think doing so would be cool but financially it would be suicide for Apple so tough - buy their stock and be happy they make a profit.
MacOS X uses a Mach kernel and is compatible with BSD 2.2. It is based on Nextstep and has inherited many of that OS's features. Technically Apple bought Next; practically Next took over Apple's OS development.
Yes Apple's computers come in funky cases with unusual colors. Hopefully most geeks can see beyond the flashy cases and note that there's some real compute power and some innovative OS stuff going on inside. There are those who are so put off they can't get past the box - that says more about them then it does about the products or their marketing.
This is MacOS X beta If history holds true Apple still has a few cards up it's sleeve it's saving 'till later. Steve Jobs likes very much to "Wow" folks and suprise them with kewl stuff. Nowhere does this beta say it's a full disclosure - it's a preview. Furthermore as a beta this release is expected to not be complete, to be buggy, to have problems - that's the point of releasing it. Lots of folks will want to review this Beta as they would the final release - don't pay too much creedence.
True Apple has gotten very aggressive about enforcing it's NDA's. If you were in their market you would be too. Not only does it weaken their technological edge by having everyone know what they're doing it also affects their sales. Folks hear rumors over & over of a 17" iMac next month and stop buying in advance of it (never happened - unlikely will - lousy form-factor.) Again Steve jobs likes to "Wow" folks - that's his sales technique. Spilling the beans, even a few hours ahead of time means the announcement goes from being a headline for Apple to being buried in a story.
MacOS X is a big deal for Linux & BSD folks. This is the first time a mass market vendor has released a Linux/BSD compatible OS. Sure the interface and many of the details are different but it opens the way for cross-ports. If a developer makes something for one OS they can support the other fairly easily. Thus it means many Linux/BSD applications will get access to the Mac market and many Mac applications being ported to MacOS X will go on to be ported to Linux/BSD etc.
Finally Apple is doing some interesting stuff for BSD and Linux. They've developed a great way of graphically configuring all of the subtly-different configuration files in Unix. They're beginning to help work on a new way of distributing, installing, and maintaining packages. They're spurring development of new drivers (DVD anyone?) With all of the discussion of X-Windows failings Quartz is an interesting example of what can be done with another model - an example that is not just an ambitious plan but a working widely used test case.
Finlly Apple is not perfect. They've blown more opportunites then can be counted, have more lives then a cat, and have legions who love or hate them (or both.) They're famous for developing amazing technologies then failing to capitalize on them, for their 10 (or is it 15?) year quest for the successor to MacOS, for arrogance and indecision. They've more then once set off on a path then abruptly changed course (the licensing program they dumped when it started to bleed them dry, the Newton and the eBook, OpenDoc & Bento, etc.)
OK - I'm Somecorp and I want to develop a new product. I'm about to invest a bucket of money, hire or assign a team of developers, and get this thing to market in a reasonable amount of time. Along the way I need to make it play nice on it's OS, be built using a standard set of tools my developers know, and consist of code I can revisit next year for V2 or just simple bug-fixes.
So, Smalltalk? I bring it up at a meeting with the other enginners-turned-suits and a couple of annoying marketing folks. They all stare at me. Smalltalk? We code in C. Or C++. Or whatever. We don't have any Smalltalk experiance. We don't have any Smalltalk tools. We don't have any Smalltalk developers.
But we can hire the developers! We can buy the tools! We can integrate this into our company! We can learn to read it ourselves as so to manage it!
Then Bob, who's been around forever takes me aside and points out a few things.
We're a business. We're not about changing the world, or even rocking it unless there's profit in it. Sure Smalltalk may be great but we've already got a language we use, the licenses are paid for, it's an indistry standard. Good developers are hard enough to find as it is without requiring them to be Smalltalk coders. Frankly we've never managed a Smalltalk project and don't know any of it's dangers, what it's "best practices" are, how to optimize it, even have any code we can reuse in it.
Look son - there are lots of great languages out there. They're fascinating, faster, etc. But we're in business and that means getting a quality application out the door. We stick with what we know and not add any variables we don't need. Now go back in there and let the Marketing folks tell us it needs to be 'synergistic' and 'mauve'.
So we go back and I politely drop the whole Smalltalk thing. Yeah, it's a great language. Sure it can do things cleverly and elegantly but that's not what we're about. We're about standardized production and that botique stuff isn't for us. So no Smalltalk today thank you.
That's why Smalltalk isn't moe popular. Personally I'm all for renaming it Internet2000MultiMediaOpenSouceSexySexySexy!!! but short of that it's just another great idea passed over by history...
I agree that *right* *now* it's a better idea to simply buy a dedicated Digital TV Recorder then to retrofit one's PC - I just think funkman got it all wrong. Here's his points, mine, and some more:
TV and home computer don't look together. That may sound petty, but that is reality for the masses, think about it. (Something to digest: The iMac had nothing to do with its technical features, it looked cool) Don't look good together? Sorry, but even amongst my most decorator-obsessed friends I don't know anyone who'd not find a way to work around this if they really cared. As to why iMacs sold: hint - it wasn't the colors. Yes they're a break away from the traditionial beige box and that made them trendy in certain circles but it was much more that they were the first resonably priced Macs that came out in a long time, they were agressively marketed, technically were good for their market and Apple didn't look like it was about to slip below the waves leaving everyone who bought one with an orphan.
The family PC, would be need to be near the computer, very distracting for homework.First many of us don't have "homework" in our houses (the most likely spot for a child to be in my house would be on the dining room table with an orange/ginger glaze and an apple in their mouth.) Of my acquaintences who do have progeny many of them seem to do quite well with the TV and the computer sharing the same room. Indeed I expect if one were to survey families with PCs most would be found in the same room as the main TV set, some because it's the common room in the house, others so they can kep an eye on their kids computer use.
If the TV and PC are a distance apart, networking will be involved. That will eliminate 95% (or more) of the population. (Face it, the/. readers are an extremely tiney minority) W-i-r-e-l-e-s-s. H-o-m-e-l-a-n. Both are happening now - not just amongst geeks but out in middle-class suburbia. Furthermore this has been going on since cable-modems were developed (y'see the computer gets connected to the cable-TV which usually comes into the house near the TV set even though they look just awful near eachother...)
For software makers, the market share is not great enough to show me the money. Even those who had the ability, would need to perform one of the above. This isn't a software issue: this is a hardware one. A bunch of companies (video-card folks, disk-drive makers, even PC vendors) would love this to happen. It wouuld set a new spec for PCs, a high-end one. The software would get written and tossed out there just to support the hardware, much like CD burner software is bundled with CDRW drives. There would probably be a similar market with the low-end version included in the box and a more fully-featured one available, or the listings able to be subscribed to. As to your second sentence - left over from a bad edit?
Support, support support. See previous statement about market share. Yeah, Dell, Apple, Compaq, Nvidia, ATI, Seagate, Maxtor, they don't have any market share between them. Just 'cause this could be big sales for them doesn't mean that they'll go after it...
So what are the other points?
You'll see PCs capable of doing this stuff availiable off of the shelf in the next 12 months. The technology is already there in bits & pieces, someone just has to put it all together. iMacs DV's already do much of it, MS WinME also includes most of the same technology.
Of course this will require folks keep their PCs on 24/7, the PCs be quiet enough to not be intrusive, the PC's 'sleep' & 'wake up' (power-conserve) to do the recording, and of course the recording not interfere with the computing or vice-versa.
There will need to be a way to control the computer's recording & playback from the couch. This will reqire some sort of custom remote (another one!) or better yet a USB-tethered IR 'eye' plugged into ones PC with some smart backend software that could work with many types of remotes. This would actually be almost the easiest part of the system as the hobbyists would all rush to make every remote they've ever owned worked with this plus their Palm Pilots and everything else.
There would need to be a source of TV listings avaliable in a format one's software can digest (TV-XML?) This could come from the Cable vendor or third parties but there's likely to be some sort of revenue recovery involved - this can't be cheap to assemble and I'm sure there are Intellectual Property issues involved somewhere.
Dedicated boxes will prove popular since they won't interfere with the computing side of things. Additionially they can be loaded with other features like set-top gaming, MP3s storage & playing, web-browsing, etc. They could even be sold as 'Home Servers' offering firewall, censorware, routing, and other features along with their basic TV functionality. You'd end up with a desk-based PC for keyboard-type things such as MS Office and an appliance for couch-potato stuff like TV watching and casual web-browsing (I want Brittany's skirt! Click on it and a brower pops up pointig to her website with the skirt in the video already loaded into the page)
Look, this is about the merging of the TV and the computer. It's big, it's happening, and companies like MS are rooting for it in so many ways. There's no need to go into the details, convergance has been discussed for years and these are the devices it's happening through.
Personally I think we need to change hearts in this country. We need to tell the media and the government that we will not be told how to think, and that we will not be told that holding "politically incorrect" opinions is wrong. This is a free republic, for Pete's sake, and I am a free man.
-- Anonymous Coward
Aren't they always?
(Made fun of by a gay man with lesbian friends, some of whom work in inner city schools where the day-to-day language isn't BBC English and many of the folks are Islamic...)
Arguing computers are becoming 'too easy' (basically dumbed-down) assumes we're all in agreement about what is a "computer".
Is a WebTV a 'computer'?
Is a VCR a 'computer'?
Is a Tivo a 'computer'?
Is a car engine a 'computer'?
Is a laser printer a 'computer'?
Is a pace-maker a 'computer'?
All of the above certainly employ computing technology. They even all have interfaces though of vastly differing sorts. No, none of them are the same as the general-purpose box that sits on your desk yet many of them duplicate the functions it performs.
At one time a 'computer' was a large hulking device that sat in a special air-conditioned room attended by a cadre of highly trained folks that spent all day performing mathematical calculatiions (hence a "computer".)
Now we use that underlying technology to edit digitized video, play interactive simulated 3D games, and instant-telegraph each other.
Are all of those 'computing'? Well, yes in one sense but no in another. Are all of the devices listed above 'computers'? Well, yes in one sense but no in another. Do all of them have interfaces? Well, yes in one sense but no in another.
What and how we use 'computers' have evolved. Their capabilites have also evolved. To argue that they've become 'dumbed down' is to ignore their ubiquity and specialization.
Tools are built appropriate to a their task. For computers that task is no longer calculating large tables of ballistics or whatnot but rather the ones listed above plus so many others. That we limit our tools to their task is not suprising: it's smart engineering.
Kee It Simple, Stupid means defining a tool's functions and paring off extranious functions. Make it the best at what it does and don't compromise it with superflous features. If it can be multipurpose great but don't let this interfere with it's basic usability.
Computers have become specialized tools. To confuse optimizing their functionality for their task (oftentimes interfering with extranious or lower-priority functions) with 'dumbing-down' is to ignore the features this specialization brings.
Well there's a big market: not. Custom NLM's never really took off and most of what did get written either migrated years ago to easier platforms or is in hard core Netware shops where it will likely stay for awhile.
As for Linux/BSD/etc. to Netware I expect most folks would just skip the NLM's entirely and code Java servlets for the Netware server (if they had to do this migration for some reason.) While a servlet wouldn't be as fast as an NLM it'd be easier to work with and has the advantage of being that much more portable in the future. Honestly though I've not heard of anyone porting anything custom from Unix to Netware in years but I suppose someone might do so for a specific need.
Frankly the market for custom Netware-based applications seems to be pretty minute. If one is going to develop something propriatary for in-house then NT or Linux/BSD/etc. would be the far more obvious choices. With Netware's increased connectivity one could host the app. on a separate box and still validate against the NW/NDS box. Netware is a great OS for what it does but NLM's are not a joy to write or debug. Besides if something is important enough to develop internally then it's likely important enough to get it's own box to run on.
The original question was really two: the first the OS and the second the hardware it's on.
Frankly most businesses with any technical acumen insist on a three year replacement cycle on things like x86-based servers. Why?
They're paid off.
They're no longer state-of-the-art. Getting replacement parts for them is becoming difficult for equipment long out of stock.
They're becoming 'worn'. Bearings have been spinning for three years. Power supplies have taken three years of small hits. The motherboard & cables are becoming brittle. Metal contacts are slowly getting gunky or working out of position.
The computing environment has moved on. Three years ago a server could be a PII 233 with 128 MB RAM and a 16 GB drivespace with a 10bT NIC. Now the clients are PIII 700's with 128 MB RAM & 24 MB HD' pulling down files over a 100bT wire.
Drivers are no longer being developed or tested for the OS's. Simply to maintain security patches one must update the OS occasionially & the more outdated the drivers are the greater the likelyhood of an incompatibility popping up.
After 3 years folks will no longer be facile with this generation of hardware. Something that we now take for granted was novel and required special consideration then - something we may well forget to take into account now when a problem arises.
Lastly - the chances are getting higher and higher that the manuals have been lost, the floppies holding critical device-drivers have 'rotted', documentation no longer matches the actual configuration, and the reasons for many of the originial implementation decisions are lost.
True lots of hardware chugs on happily year after year but it's also true that every day that pases after the originial burn-in period the device becomes more likely to fail. While failure of a home computer isn't a big deal (pop in a new power supply, replace the failed fan, whatever) in a business the results can be significent.
In the case of a file server failure many of the files that were in use during the failure may be truncated or damaged. Changes to them since the last backup may well be lost. Finding and replacing these damaged files can be a mess, popping up problems months or even years later. Employees are inconvienced when the services handled by that device are no longer availiable and the inevitable confusion results. The cost of even a a half hour outtage in a small business can quickly exceed the cost of a new server, in a midsize business it's a few minutes and in any large business any interruption of service is a serious issue.
The IS department is likewise disrupted with diagnosing the problem, determing the solution then picking up the pieces. Should the support be outside then there's the additionial travel time and a greater likelyhood of unfamiliarity with the device and it's functions leading to yet even more confusion and a longer outtage.
In short, spending the money on keeping hardware current is money well spent. Few businesses have any problems with understanding this need and will respect a 3-year lifespan on hardware.
It's folks like you that scare so many customers. You want the customer to go to Linux, or BSD, but can't provide a reason aside from "it's hip". So now you go fishing for reasons?
First, Novell is a company & Netware is a product. Novell makes a bunch of products and although Netware is their flagship being accurate tends to reassure customers.
Second the client already has Netware. Clearly it works well for them. Clearly it's integrated into their operations. They seem to have support for it, the users are used to it, the files and rights are likely well established and well understood. There are doubtless ancillary systems like backups, print servers, email, etc. that all rely on Netware that would need to be reconfigured or replaced should Netware go away.
Next support folks for Netware are easy to find and have well established credentials. Support for Linux or other comperable OS's is pretty much a dice-roll these days. Application support is the same - everything understands how to work in a Netware environment - few applications yet know how to optimize their file calls or locking in a Linux/etc. environment. Have a problem with Whizbang2000? Call their support line and say Netware or NT; it's a click in their decision tree. Say something unusual like Linux or BSD and the phonetech will go into a crash & burn, likely after first trying to blame your Linux/etc for the problem.
Look, I'm not knocking Linux or BSD varients or anything else. I'm just pointing out that there's a hell of a lot of issues involved in changing from one server OS to another. Lots (most) of these issues have very little to do with the quality or qualities of the OS itself but rather with external situations like legacy compatibility, support mechanisms and the basic horrors of reengineering a typically complex network environment.
To encourage a customer to change their server OS, particularly when it's one that they seem so happy with, is not to be done lightly. To encourage them to move to an OS that you & your company don't know well enough to even recommend a particular choice is sheer folly.
I can see suggesting Linux or some other non-traditionial OS (damn we need a word that encompasses Linux & the BSDs but leaves out the more obscure varients) for a client with a specific need for something not found in their current Server-OS-of-choice. I can even see encouraging them to use Linux/BSD/etc. in new deployments where there isn't much legacy material to worry about. I'd definately encourage them in cases where they've found thier current Server OS unsuitable or they've outgrown it (all assuming I was well familier with the specific product I was recommending.)
In your situation? It's a good thing your company is researching the alternatives. It's a better thing your boss will likely take your results, read them with interest, and not mention this to this client. Be cheered though that your studies won't have gone to waste as it wouldn't be suprising if soon some other client either requests Linux/etc. or has a situation where you folks can legitimately recommend Linux/etc.
Be ready to write excruciatingly detailed specifications and testing procedures.
Frankly for a one-off outsourcing doesn't make sense. You'll spend too much time & energy detailing what needs to be done and how it is to be done and when what parts are due and how to determine what was done properly and how to resolve problems... You'll then spend many hours overseeing those points as well as answering questions, resolving unexpected issues (things that were they done in your office would be settled over the water-cooler) and of course revising everything as the situation evolves. With all of that overhead it's cheaper & more efficient to just contract a bunch more coders locally and keep 'em under your thumb.
Where it does make sense is when you want a portion of code written that has fairly clear specifications and you're looking to get into a long-term relationship. There you can amortize the costs of the startup and learning process over several years or projects and get some real savings. This of course assumes your company is structured so that it can plan long-term and is stable enough internally to work with a bunch of outsiders in a possibly different time zone.
Honestly though I've heard of such companies I've never seen one myself (much like unicorns.)
First, thanks for correcting my typo (affect/effect) - never post while getting ready for bed.
Second I'm not a 'fanboy' - rather I'm somebody who tracks this market as part of my job. Torvaldis or not Transmeta has some interesting technology. Commercially successful is still TBD but it is interesting stuff that could have applications beyond their original market.
Third if you recall (or are aware of) Intel spent years dealing with the results of it's licensing production of it's 80386 chips. They ended up competing with their own licensees for prices and allocations. It was these licenses that allowed many of the clones to convert (against Intel's lawyers and many court battles) to 'licensees' and thus buy legitimacy when they were manufactured by license holders or when their designers bought or were bought by license holders.
If I was a hot new thing on the block possibly considering another round of investment I'd certainly want the license variable off of the sheets. It's not unlikely that the licenses contained a standard buy-back clause which Transmeta exercised. Furthermore it's telling that the deal was done with Transmeta stock and not their cash.
Whether Transmeta's chips are 'all-that' we don't know yet. Certainly they have promise for competing in the mobile-marketplace with Intel. Whether the big boys are just backing them to keep pressure on Intel in the market or they're seen as a truly viable isn't clear. It's possible that they're both a pressure tactic and a potential breakthrough - a two-fer in the eyes of IBM, Toshiba & others. Either way it's too soon to bury them.
Right now Transmeta probably has another year in which to make some success with their original plan. If they don't succeed look for them to retarget to some less obvious/less immediately profitable market. I'd bet they've already got a team working on developing some legacy-emulation for aging big iron (something that would certainly pique IBM's interest.)
Any which way - they've got some interesting Intellectual Property and make for a good story.
So Transmeta is buying back it's licenses. This means they have a bucket of cash & would like more control of thier own future.
It doesn't mean that Toshiba or IBM are dropping them as a supplier - just that they'll be a supplier like any other supplier.
It doesn't mean Transmeta's technology is any better or worse then it was or seemed to be when IBM & Toshiba bought the licenses awhile ago - it just means that the financial folks at those companies wanted the cash more then the licenses & their supply folks felt comfortable with not having production in-house.
This doesn't mean that IBM won't continue to build Transmeta's chips in their plants. IBM builds lots of chips for many companies as a simple supplier. IBM has the foundry capacity & the manufacturing technology to build chips for any number of clients & it brings them a good profit.
This does mean that Transmeta will have more freedom in selecting manufacturers and setting prices & directly controlling production.
It doesn't mean that Transmeta won't turn around next year and sell licenses again for either the current set of chips, for a next generation, or for third-party implementations.
Frankly this seems more like "News for Finance Nerds" then anything directly technology related.
Slashdot Mirror
One of the advantages I appreciate about it is the ability to keep my Mac environment while popping in & out of others at need, no reboots required. At various times I've had RedHat & Mandrake installed, Netware, Win9x, and several NTs. Double-click - I'm running NT. Double-click - I'm in Netware. Double-click - hey it's Linux! Click - I'm back to my MacOS which never stopped running. No messy partitions, no boot managers, no shut-down-everything-then-reboot-into-whatever.
Moving from hardware to hardware is simply a matter of reinstalling VPC then copying the settings & disk image. I keep a small hub on my desk so I can drag these images between my desktop & laptop without burdoning the office LAN (routinely copying a 1 GB file on shared media isn't really a nice thing to do to one's office-mates)
Tips for running VPC: Memory and disk space, you can't have too much of either. A stock iBook would be crowded with VPC, really consider bumping up whatever you get as much as reasonably possible.
Their application runs under BSD & 'till recently they've been requiring their customers buy a standard distribution. They've now expanded their support to the various free BSDs and are now considering MacOS X.
As their customer base is non-technical folks with limited support resources something like MacOS X would seem a logical step. However they're unwilling to commit resources and fork their product until MacOS X has been out in the market awhile, appears successful & enough customers seem willing to adopt it.
One interim strategy we discussed was simply continuing to run their application under an X Server and pretty-much ignoring the whole MacOS X-side of things until they've determined how far they want to go with this.
Generally one can get a significant discount from MSRP if one licenses only the required parts of a product, limits it's use to running the licensed application, handles product support & is willing to include an upgrade offer in the packaging. If the X Server vendor is open to licenses like this then the cost per unit could be acceptable.
Thus their product could ship almost immediately and with the exception of the added X Server install and some other "MacOS-X-ifications" (graphical installer, file locations, frameworks, icons) would be the same as their other releases. Indeed we guesstimated it would take 2 or 3 days to modify the unix side of things and another 2 or 3 to produce the MacOS X side.
This is exactly the sort of thing Apple probably worries about. Ultimately it might be a win for them but in the meantime they'll have a quasi-ported-application runnning on their shiny new OS.
As to concerns regarding the supplier, well, yours aren't new ones. Generally one can request an audit of the company to determine it's health, invest in things like a code-escrow policy, have alternative strategies in place (I expect there won't be one X Server vendor for MacOS X forever), etc.
Finally these concerns are less strong then they might be otherwise as this would intended as an interim step. Should the product prove popular then the full port to Mac OS X would take place with the Aqua GUI etc. and then the licensed X Server could be dispensed with.
As I see it you have four choices:
Damn - posted instead of previewing. Well, there it is, warts & all - you get the idea. Honestly I'm not terribly interested in pursuing this discussion much futher anyway. Apple buying SGI seems extremely unlikely IMHO and 'what ifs' aren't particularly engaging.
Software-wise they're not a particularly good matchup. Sure they overlap in some ways but then almost everyone in that part of the market does.
Hardware-wise they've very little in common. Where SGI does have 'kewl stuff' it's not particularly applicable towards Apple's current hardware base (that I'm aware of.)
Customers, contracts, service & support, development engineers - SGI is hemmoraging all of those and again, none of them are very good matches for Apple's business model.
What Apple needs now is to improve it's hardware and solidify MacOS X.
In hardware Apple needs faster, more flexible motherboards. Faster CPU's would be great too but they can get away with dual (or more) PowerPC's as long as they're competively priced. Should PowerPC truly be stuck at a roadblock Apple could consider moving to Alpha. In no case are they going to succeed (ie profit) competing in the consumer or workstation x86 market - at least not in the near-future. Once the transition to MacOS X is complete and it's established Apple would do well to consider a Darwin-based x86 subset specialized for server duty, much like the MacOS X Server release of two years ago is used today but on a x86 hardware platform. I expect they'd treat it much like they do their '486-based AirPort today - the CPU is x86 but they don't make a big deal of it.
OS X needs to get out in the market and establish itself as a Unix peer. Once it gets some creditability as a stable Unix vendors can start porting over Unix-apps to it and customers can start weaning off of the Classic/Carbon codebase. With this transition Apple could begin to move into some of the server market making the same arguments MS makes for NT: one OS scalable for desktop / workstation / server. They'd be able to come up to speed rather quickly in the server space as the developers would be simply performing another Unix port with some added UI work.
Were I Apple i'd be looking to spend my money on a few things:
Why would Apple, fresh from it's own brush with death want to purchase another ailing company, particularly one with such poor prospects?
Apple has finally gotten it's hardware habit somewhat under control. The original lean line-up has now ballooned but at least almost everything is being based on common motherboards. SGI would bring in a completely different set of technologies with almost no common elements.
Apple has also pared down it's software holdings. No longer does it try to compete with it's own applications but has spun off/shut down/de-emphasized most of those distracting and ultimately non-profitable lines of business. SGI would pull it back into those markets in a big way.
Finally, Apple is once again focussing on profitable markets, one where it can sell either enormous quantities of hardware (iMacs) or fewer but highly marked up ones (Cubes.) SGI doesn't fit into either category particularly well, nor does it's own category seem much longer for this world.
This appears to be a case of looking-for-a-buyer-for-SGI & not what-could-Apple-spend-it's-bucks on. Sure if gifted with SGI I'm sure Apple would be happy but $ for $ they'd be a lot better off spending their money on R&D to extend their own stuff into what's left of SGI's market.
Apple's MacOS X does not come with an X Windows server. Apple has no intention of developing or releasing such a beast. Apple instead chose to develop a PDF-based display system called "Quartz" upon which runs their UI named "Aqua".
Tenon, a respected developer of Mac software, has developed an X Server that runs on MacOS X. This is significantly different from John Carmack's port of X to Apple's open-source OS Darwin (upon which MacOS X is based.) Tenon's X Server is driving the Quartz PDF-based display and utilizes the Aqua toolkits to produce a fully MacOS X-integrated display. In short anything run under Tenon's X Server is immediately available to the rest of the MacOS environment as just another PDF (cut-'n-paste, etc.) as well as appearing as Aqua-like as possible.
Thus with Tenon's X Server one can run a generic X application and it will appear as simply another Mac OS X application obeying as many of the Aqua UI principals as possible. Indeed with many X applications trivial changes will be required to make them appear to be native Mac OS X applications (mostly menu placements, dialogue boxes, etc.)
As one can imagine, this is both good news and bad news for Apple They undoubtedly welcome this product as it gives the connectivity they so sorely need; particularly in their important scientific research market where they're already fairly popular. On the other hand there is likely a fear that developers might 'port' to MacOS X by simply running their apps in a X term session (possibly a cut-down server licensed from Tenon) and not go native.
As to Tenon's other 'ports' - are they ports? Likely yes. Getting a unix application, particularly one already native to BSD to run under Mac OS X isn't much effort, if any. Constructing a native user interface for it, while not very difficult, does take time and some (presumably) skill. Since we already talk of ports to other such brother/sister OS's the same would seem to apply here. The argument is strengthened with the added effort of creating an Aqua UI and integrating other Mac OS X conventions which Tenon has done.
-- Michael
No affiliation with any Mac developer currently, nor have I ever purchased any Tenon product. However I do look forward to running their OS X Server.
In places I've managed one of my first changes has been to insist that HR put a message on a email distribution list every time a position is created (note this is often well before someone is hired but it gives my staff time to determine the future employee's needs), upon a hiring, and the instant they believe someone may or will be leaving. In these communications HR must specify dates and the appropriate managers to contact for direct instruction. I also put an emergency procedure in place for 'rapid-separations' where all of a person's accounts are identified, marked for immediate back-up, and locked down until the situation is clarified.
I generally drive these policies & procedures home by holding a meeting between HR, IS, and Legal with all of us asked to brainstorm on the awful things that could happen should we drop the ball on this. One can usually come up with some very nasty scenarios pretty fast. The folks involved also generally know a few real-life stories we've seen or heard of we can recount just to completely scare everyone into following these policies seriously.
What can really force these policies is privacy laws. Even though many would think that communications to someone via a companies resources would be properly a companies property this changes a bit once the person is no longer an employee. I'm not a lawyer but I do know that in most places one is on shaky ground continuing to allow the former employee's name to remain active in the email system after a reasonable amount of time. To have someone then go through a former employees communications, specifically any that are received after the employee is separated from the company, is very dangerous and just asking for a nasty lawsuit.
My own solution to moved-on employees has been to place an auto-responder on the email account indicating the person is no longer with the company, possibly listing the other person(s) who are now handling the former employees responsibilities, and referring all other communications to HR. Generally this will do for up to a year after which the account just becomes another generic dead one. For voicemail a similar procedure is used by closing the person's inbox and replacing their old greeting with a new one giving the new numbers to contact for various services.
Of course one can avoid many of these problems by encouraging the use of functional email & voicemail accounts. With these many messages go to "Department - Function" instead of individual persons. One can't (and oftentimes shouldn't) get rid of personal email accounts but by keeping much of the purely administrative email on the functional address list does. Utilizing this duplicate system can cut down enormously on mail-list administration and general administrivia.
Another problem I commonly run into is the 'legacy' account where someone has moved on but another simply assumed their accounts, oftentimes their replacement. This sort of thing leads to really confusing situations where one isn't sure who is using what accounts, which are active, and which are linked. This can become particularly problematic when trying to implement unified login systems.
Finally there's the nightmare of IS staff leaving. Oftentimes we know waaay too many passwords, particularly the 'deep-mojo' ones. To help expedite these transitions I generally try to keep a list of all the primary accounts (passwords stored seperately in a secure place)and a instruction sheet on changing them all at need. It's also simply good practice to discourage users from giving passwords to IS staff and simply requiring them to enter themselves when needed.
So what services do you have access to? I'll be more then happy to run the search for you but you can pay for your own copies. Doubtless a finance whiz like you subscribes to Bloomberg / FirstCall / West / etc.
What about running IPv6 on 9x/NT/2k? Anyone have any reports on it? How hard was it to get running? Did your apps play nice with it? How was performance? Who was there to talk to? Any practical immediate advantages? Are there any ISP's yet offering IPv6 support? What will AT&T @Home (is that their name this 24 hours?) do if I start running IPv6? Did the MS implementations interoperate with other vendors? Which one seems best under WinWhatever? Which one seems best overall (Linux/BSD/etc.)
IBM PC clones came about because the BIOS they used was primitive and relatively easy to reverse-engineer in a legal fashion. The popular OS (there was originally a choice between DOS & the UCSD Pascal system) was licensed from MS under a non-exclusive contract. Thus once Phoenix came out with a good clone BIOS the market jumped from almost-alikes to out & out clones running a functionally identical BIOS and the same OS.
IBM sued folks for years trying to kill the clone market, then when it was clear they were unsuccessful they tried to come out with another 'standard' that they had complete control of. By that time however the architecture was entrenched & IBM simply moved themselves into a niche market from which their PC operations never really recovered.
On the other hand Apple put a large chunk of it's code into proprietary ROMs installed on the motherboard. These ROMs contained many of the routines critical to operating the Macs and they were both heavily legally protected and difficult to reverse engineer. There was no particular genius in this - it was simply how Apple built their boxes and it turned out to be fortuitous way of keeping their hold on their market.
Apple did have a licensing program, often incorrectly characterized as clones (in licensing the product is authorized under terms and the license holder is compensated - clones are simply legal knock-offs with nothing going back to the inventor.) The program was intended to supply Macs to markets Apple considered insufficiently profitable for it (Apple at the time had terrible supply management problems and an astonishingly high overhead.)
Unfortunately the licensees didn't remain focused on the small-margin educational market, super-high-end graphics market & burgeoning but very price sensitive foreign markets as originally intended but began to cannibalize Apple's high-profit mid/high-end domestic Mac market. As a result they began to cost Apple both in support, un-recovered R&D, and lost sales and thus were eventually unceremoniously killed.
Apple does have an advantage when it comes to close-coupling their hardware with their software. By making their own boxes they can design the hardware and software to compliment eachother. This is also a drawback as it limits the market to what Apple can develop & supply.
USB adoption came about when Apple needed to drop it's aging Apple Desktop Bus (ADB) and USB was a good match for the old technology (functionially they're very similar so it was easy to write shims for USB to operate in place of ADB.) Firewire/1394 was developed as a next generation SCSI and to correct the many mistakes Apple had made in it's originial SCSI implementation and then codified with (mis)use. The wireless inclusion was a bit of clever thinking on Apple's part and some great product engineering/cost negotiation resulting in a suprisingly inexpensive implementation (which humerously enough is based on a 486)
Wintel PCs have their own advantage in MS setting the WinHEC specifications and many, many companies optimizing their hardware production. This diversity makes for less optimization and greater support issues but it also makes for a much broader market and relatively faster pace of innovation.
Apple would be unwise to compete in the x86 market simply because they'd be horribly far behind when it comes to device support. In the 'sheltered' Mac market it's accepted that not third-party all devices are supported & cost more (conversely Mac users are furious when supported devices don't work flawlessly.) In the Wintel world everyone is expected to have WinX drivers and that's that.
Furthermore Apple commands a high premium for their Macintoshes simply because they're the only game in town. Were they to attempt to get the same margin on x86 boxes they charge on Macs they'd be laughed out of the market. To sell x86 PCs at a competitive price wouldn't recover their OS development costs and would cannibalize their traditional Mac platform sales.
Who would want a $2,000 PC selling for $3,000 runing MacOS X and a limited set of hardware options? I love Macs but this would be hard to swallow. Apple could consider using another chip (perhaps an Alpha) to justify/disguise their markup but it would still be difficult.
Then there would be that whole problem NT had with x86/Alpha/MIPS/PPC binaries and Lunix/BSD have with their own different hardware bases. It was tough enough for Apple when there were the M68020/M68030/M68040 and PPC issues (variations in memory management, floating point, and with PPC an entirely different architecture) leading to products that would run on some combinations of hardware & software but not others. This culminated with the 'Fat Binaries' for M68x/PPC applications.
Unfortunately as we've seen with other mixed-processor OS's (Linux being a good example) the whole process of supporting code on different processors is fraught with difficulty. Can you imagine explaining today to a Mac customer that some apps run on MacOS X PPC & other on MacOS X x86 and that the versions aren't the same?
Finally - Apple didn't 'steal' anything from Xerox. This is an old chestnut that's gone around for years and is patently false. If you do a bit of research you'll discover Apple had already settled on a graphical interface for their next-gen OS well before their visits to Xerox.
Certainly the Lisa folks were influenced by what they saw at Xerox but it was by no means a copy or theft. Indeed the concepts of much of what they eventully shipped were developed *before* their trips to Xerox. Furthermore much of what they released was significantly different from what Xerox had (and yes I've used a Xerox Star extensively.)
Apple is a neat company and they've devloped some great stuff but they're not perfect. They've made some incredibly foolish, incredibly arrogent mistakes. They've also developed some amazing stuff and managed to pull their chestnuts out of the fire more times than any company has a right to.
Oh thank goodness!
Someone who know's Apple's business better then that durn Board of Directors... All these years the Financial Analysts have been saying the same thing: "Apple makes it's money on hardware". All these years they've been saying "They couldn't support themselves on the fees for their OS - the development & support costs would overwhelm them" - THEY'VE all been *wrong* and of course YOU are *right* !
How could we have all been so blind!
Please oh magnificent one - lead us into the light! Show us how only you can see clearly that which none of the investors can grasp, none of the company officers can delve, none of the stockholder percieve! For ony YOU oh amazing one shall humble those exalted bastions of capitalism and forever sunder Apple from it's hardware dependance and let it be reborn as a software company - profitably!
Oh - it's as if Rapture were upon us!
If by "a few tweaks" you mean recreating the entire Apple 'Carbon' environment and then getting it to work under X instead of Quartz then - sure.
The more honest answer is 'No' - or at least - "Not with MS Office 2001 for the Mac."
MS is not moving their Mac Office apps. to the Unix-side of MacOS X but rather tweaking the to run under the MacOS-derived Carbon environment. Thus aside from dropping some of the more difficult to support calls it's the same as it's always been. Indeed MS Office 2001 for the Mac won't even require MacOS X to run - t'll do fine on any Mac running MacOS 9x as long as the Carbon libraries are present.
The question comes what about after this next release? Will MS refuse to move to the Unix side of the OS, simply move only as far as the Cocoa side (neat Openstep-derived technologies) or go with Java (little chance.) Furthermore will they tie themselves to Apple's Quartz rendering/Aqua UI or write more generalized code that could be retargeted towards X Windows.
MacOS X will be able to run X apps if it has X installed. Apparently Apple is not shipping X with the OS. However there is already an excellent commercial X availiable that works under Quartz and fully integrates with the Aqua UI.
MacOS X is not being developed for x86. Yes that was the plan for Rhapsody, MacOS's immediate predecessor. This was scrapped. Yes Darwin has been released as Open Source by Apple for the x86. Yes this is the base for MacOS X. No these are not the same things. MacOS X includes the Quartz rendering layer and the Aqua interface, the Classic, Carbon, and Cocoa environments, Quicktime, etc. Darwin may be the engine but that's *all* it is. It's unlikely Apple would release MacOS X for x86 since Apple is a hardware company and thus this wouldn't make sense for them financially. Yes you and many others think doing so would be cool but financially it would be suicide for Apple so tough - buy their stock and be happy they make a profit.
MacOS X uses a Mach kernel and is compatible with BSD 2.2. It is based on Nextstep and has inherited many of that OS's features. Technically Apple bought Next; practically Next took over Apple's OS development.
Yes Apple's computers come in funky cases with unusual colors. Hopefully most geeks can see beyond the flashy cases and note that there's some real compute power and some innovative OS stuff going on inside. There are those who are so put off they can't get past the box - that says more about them then it does about the products or their marketing.
This is MacOS X beta If history holds true Apple still has a few cards up it's sleeve it's saving 'till later. Steve Jobs likes very much to "Wow" folks and suprise them with kewl stuff. Nowhere does this beta say it's a full disclosure - it's a preview. Furthermore as a beta this release is expected to not be complete, to be buggy, to have problems - that's the point of releasing it. Lots of folks will want to review this Beta as they would the final release - don't pay too much creedence.
True Apple has gotten very aggressive about enforcing it's NDA's. If you were in their market you would be too. Not only does it weaken their technological edge by having everyone know what they're doing it also affects their sales. Folks hear rumors over & over of a 17" iMac next month and stop buying in advance of it (never happened - unlikely will - lousy form-factor.) Again Steve jobs likes to "Wow" folks - that's his sales technique. Spilling the beans, even a few hours ahead of time means the announcement goes from being a headline for Apple to being buried in a story.
MacOS X is a big deal for Linux & BSD folks. This is the first time a mass market vendor has released a Linux/BSD compatible OS. Sure the interface and many of the details are different but it opens the way for cross-ports. If a developer makes something for one OS they can support the other fairly easily. Thus it means many Linux/BSD applications will get access to the Mac market and many Mac applications being ported to MacOS X will go on to be ported to Linux/BSD etc.
Finally Apple is doing some interesting stuff for BSD and Linux. They've developed a great way of graphically configuring all of the subtly-different configuration files in Unix. They're beginning to help work on a new way of distributing, installing, and maintaining packages. They're spurring development of new drivers (DVD anyone?) With all of the discussion of X-Windows failings Quartz is an interesting example of what can be done with another model - an example that is not just an ambitious plan but a working widely used test case.
Finlly Apple is not perfect. They've blown more opportunites then can be counted, have more lives then a cat, and have legions who love or hate them (or both.) They're famous for developing amazing technologies then failing to capitalize on them, for their 10 (or is it 15?) year quest for the successor to MacOS, for arrogance and indecision. They've more then once set off on a path then abruptly changed course (the licensing program they dumped when it started to bleed them dry, the Newton and the eBook, OpenDoc & Bento, etc.)
But damn they make the market interesting :)
So, Smalltalk? I bring it up at a meeting with the other enginners-turned-suits and a couple of annoying marketing folks. They all stare at me. Smalltalk? We code in C. Or C++. Or whatever. We don't have any Smalltalk experiance. We don't have any Smalltalk tools. We don't have any Smalltalk developers.
But we can hire the developers! We can buy the tools! We can integrate this into our company! We can learn to read it ourselves as so to manage it!
Then Bob, who's been around forever takes me aside and points out a few things.
We're a business. We're not about changing the world, or even rocking it unless there's profit in it. Sure Smalltalk may be great but we've already got a language we use, the licenses are paid for, it's an indistry standard. Good developers are hard enough to find as it is without requiring them to be Smalltalk coders. Frankly we've never managed a Smalltalk project and don't know any of it's dangers, what it's "best practices" are, how to optimize it, even have any code we can reuse in it.
Look son - there are lots of great languages out there. They're fascinating, faster, etc. But we're in business and that means getting a quality application out the door. We stick with what we know and not add any variables we don't need. Now go back in there and let the Marketing folks tell us it needs to be 'synergistic' and 'mauve'.
So we go back and I politely drop the whole Smalltalk thing. Yeah, it's a great language. Sure it can do things cleverly and elegantly but that's not what we're about. We're about standardized production and that botique stuff isn't for us. So no Smalltalk today thank you.
That's why Smalltalk isn't moe popular. Personally I'm all for renaming it Internet2000MultiMediaOpenSouceSexySexySexy!!! but short of that it's just another great idea passed over by history...
Modula3 however - now THERE's a great idea!...
So what are the other points?
Look, this is about the merging of the TV and the computer. It's big, it's happening, and companies like MS are rooting for it in so many ways. There's no need to go into the details, convergance has been discussed for years and these are the devices it's happening through.
Aren't they always?
(Made fun of by a gay man with lesbian friends, some of whom work in inner city schools where the day-to-day language isn't BBC English and many of the folks are Islamic...)
All of the above certainly employ computing technology. They even all have interfaces though of vastly differing sorts. No, none of them are the same as the general-purpose box that sits on your desk yet many of them duplicate the functions it performs.
At one time a 'computer' was a large hulking device that sat in a special air-conditioned room attended by a cadre of highly trained folks that spent all day performing mathematical calculatiions (hence a "computer".)
Now we use that underlying technology to edit digitized video, play interactive simulated 3D games, and instant-telegraph each other.
Are all of those 'computing'? Well, yes in one sense but no in another. Are all of the devices listed above 'computers'? Well, yes in one sense but no in another. Do all of them have interfaces? Well, yes in one sense but no in another.
What and how we use 'computers' have evolved. Their capabilites have also evolved. To argue that they've become 'dumbed down' is to ignore their ubiquity and specialization.
Tools are built appropriate to a their task. For computers that task is no longer calculating large tables of ballistics or whatnot but rather the ones listed above plus so many others. That we limit our tools to their task is not suprising: it's smart engineering.
Kee It Simple, Stupid means defining a tool's functions and paring off extranious functions. Make it the best at what it does and don't compromise it with superflous features. If it can be multipurpose great but don't let this interfere with it's basic usability.
Computers have become specialized tools. To confuse optimizing their functionality for their task (oftentimes interfering with extranious or lower-priority functions) with 'dumbing-down' is to ignore the features this specialization brings.
As for Linux/BSD/etc. to Netware I expect most folks would just skip the NLM's entirely and code Java servlets for the Netware server (if they had to do this migration for some reason.) While a servlet wouldn't be as fast as an NLM it'd be easier to work with and has the advantage of being that much more portable in the future. Honestly though I've not heard of anyone porting anything custom from Unix to Netware in years but I suppose someone might do so for a specific need.
Frankly the market for custom Netware-based applications seems to be pretty minute. If one is going to develop something propriatary for in-house then NT or Linux/BSD/etc. would be the far more obvious choices. With Netware's increased connectivity one could host the app. on a separate box and still validate against the NW/NDS box. Netware is a great OS for what it does but NLM's are not a joy to write or debug. Besides if something is important enough to develop internally then it's likely important enough to get it's own box to run on.
Frankly most businesses with any technical acumen insist on a three year replacement cycle on things like x86-based servers. Why?
True lots of hardware chugs on happily year after year but it's also true that every day that pases after the originial burn-in period the device becomes more likely to fail. While failure of a home computer isn't a big deal (pop in a new power supply, replace the failed fan, whatever) in a business the results can be significent.
In the case of a file server failure many of the files that were in use during the failure may be truncated or damaged. Changes to them since the last backup may well be lost. Finding and replacing these damaged files can be a mess, popping up problems months or even years later. Employees are inconvienced when the services handled by that device are no longer availiable and the inevitable confusion results. The cost of even a a half hour outtage in a small business can quickly exceed the cost of a new server, in a midsize business it's a few minutes and in any large business any interruption of service is a serious issue.
The IS department is likewise disrupted with diagnosing the problem, determing the solution then picking up the pieces. Should the support be outside then there's the additionial travel time and a greater likelyhood of unfamiliarity with the device and it's functions leading to yet even more confusion and a longer outtage.
In short, spending the money on keeping hardware current is money well spent. Few businesses have any problems with understanding this need and will respect a 3-year lifespan on hardware.
First, Novell is a company & Netware is a product. Novell makes a bunch of products and although Netware is their flagship being accurate tends to reassure customers.
Second the client already has Netware. Clearly it works well for them. Clearly it's integrated into their operations. They seem to have support for it, the users are used to it, the files and rights are likely well established and well understood. There are doubtless ancillary systems like backups, print servers, email, etc. that all rely on Netware that would need to be reconfigured or replaced should Netware go away.
Next support folks for Netware are easy to find and have well established credentials. Support for Linux or other comperable OS's is pretty much a dice-roll these days. Application support is the same - everything understands how to work in a Netware environment - few applications yet know how to optimize their file calls or locking in a Linux/etc. environment. Have a problem with Whizbang2000? Call their support line and say Netware or NT; it's a click in their decision tree. Say something unusual like Linux or BSD and the phonetech will go into a crash & burn, likely after first trying to blame your Linux/etc for the problem.
Look, I'm not knocking Linux or BSD varients or anything else. I'm just pointing out that there's a hell of a lot of issues involved in changing from one server OS to another. Lots (most) of these issues have very little to do with the quality or qualities of the OS itself but rather with external situations like legacy compatibility, support mechanisms and the basic horrors of reengineering a typically complex network environment.
To encourage a customer to change their server OS, particularly when it's one that they seem so happy with, is not to be done lightly. To encourage them to move to an OS that you & your company don't know well enough to even recommend a particular choice is sheer folly.
I can see suggesting Linux or some other non-traditionial OS (damn we need a word that encompasses Linux & the BSDs but leaves out the more obscure varients) for a client with a specific need for something not found in their current Server-OS-of-choice. I can even see encouraging them to use Linux/BSD/etc. in new deployments where there isn't much legacy material to worry about. I'd definately encourage them in cases where they've found thier current Server OS unsuitable or they've outgrown it (all assuming I was well familier with the specific product I was recommending.)
In your situation? It's a good thing your company is researching the alternatives. It's a better thing your boss will likely take your results, read them with interest, and not mention this to this client. Be cheered though that your studies won't have gone to waste as it wouldn't be suprising if soon some other client either requests Linux/etc. or has a situation where you folks can legitimately recommend Linux/etc.
Frankly for a one-off outsourcing doesn't make sense. You'll spend too much time & energy detailing what needs to be done and how it is to be done and when what parts are due and how to determine what was done properly and how to resolve problems... You'll then spend many hours overseeing those points as well as answering questions, resolving unexpected issues (things that were they done in your office would be settled over the water-cooler) and of course revising everything as the situation evolves. With all of that overhead it's cheaper & more efficient to just contract a bunch more coders locally and keep 'em under your thumb.
Where it does make sense is when you want a portion of code written that has fairly clear specifications and you're looking to get into a long-term relationship. There you can amortize the costs of the startup and learning process over several years or projects and get some real savings. This of course assumes your company is structured so that it can plan long-term and is stable enough internally to work with a bunch of outsiders in a possibly different time zone.
Honestly though I've heard of such companies I've never seen one myself (much like unicorns.)
Second I'm not a 'fanboy' - rather I'm somebody who tracks this market as part of my job. Torvaldis or not Transmeta has some interesting technology. Commercially successful is still TBD but it is interesting stuff that could have applications beyond their original market.
Third if you recall (or are aware of) Intel spent years dealing with the results of it's licensing production of it's 80386 chips. They ended up competing with their own licensees for prices and allocations. It was these licenses that allowed many of the clones to convert (against Intel's lawyers and many court battles) to 'licensees' and thus buy legitimacy when they were manufactured by license holders or when their designers bought or were bought by license holders.
If I was a hot new thing on the block possibly considering another round of investment I'd certainly want the license variable off of the sheets. It's not unlikely that the licenses contained a standard buy-back clause which Transmeta exercised. Furthermore it's telling that the deal was done with Transmeta stock and not their cash.
Whether Transmeta's chips are 'all-that' we don't know yet. Certainly they have promise for competing in the mobile-marketplace with Intel. Whether the big boys are just backing them to keep pressure on Intel in the market or they're seen as a truly viable isn't clear. It's possible that they're both a pressure tactic and a potential breakthrough - a two-fer in the eyes of IBM, Toshiba & others. Either way it's too soon to bury them.
Right now Transmeta probably has another year in which to make some success with their original plan. If they don't succeed look for them to retarget to some less obvious/less immediately profitable market. I'd bet they've already got a team working on developing some legacy-emulation for aging big iron (something that would certainly pique IBM's interest.)
Any which way - they've got some interesting Intellectual Property and make for a good story.
Frankly this seems more like "News for Finance Nerds" then anything directly technology related.