Did you even read my reply? Your response reads like you're concentrating really hard on sticking a bowling pin up your ass and not paying any attention to anything else you're doing. Apple sells to its current customers because they can make a steady income that way. Repeat customers are good for business, new customers typically aren't because the cost of aquiring them is usually more than you make off them. While a small percentage of PC users will switch to a Mac simply to get an iPod and use iTMS a large percentage of Mac users will do just that. They already have the Mac with the needed software support. An early Christmas present later and they can take all of their music with them be it from a CD or iTMS.
Save your "golden ears" bullshit for someone else. That argument is absolutely ridiculous. For a majority of music consumers a 128kbps AAC is more than fine, especially when the AACs from iTMS are encoded from 24-bit 48KHz masters. A 128kbps AAC is phsycoacoustically identical to the music coming off a CD. A majority of music customers are not audiophiles and do not have $2,000+ audio systems. Most people have stereos from Wal-Mart that cost less than $200 or a set of speakers on their computer that maybe set them back $30.
How come people are Apple fan boy cheerleaders when you make retarded arguments?
You don't have to include any Frameworks with your application if you don't feel you need to. If you're using only system Frameworks or ones you can reasonably expect to exist on the system you only need to ship the binary and its resources in the bundle. Safari is a good example.
In the beta versions of Safari the WebCore and JavaScriptCore frameworks were shipped in the app bundle. As they didn't exist on the system then it needed to ship with them. As soon as Safari went 1.0 Apple moved the frameworks WebKit.framework and stuck that in/System/Library/Frameworks. Now any application can use WebKit. The only time you really need to include libraries with your application is when you use stuff the system isn't likely to have. If you're going to write a bunch of applications using a custom framework it'd probably be best to just install the framework onto the system.
UT2003 pulls sort of the opposite trick than Safari 1.0. UT2003 packs everything the game needs into a single bundle. Everything from the game models to its version of libSDL are stuffed into the application bundle. While the bundle is over 200MB for the demo it is easy to move to some other media. Since the configuration file is stored in ~/Library/Application Support/Unreal Tournament 2003/ you can put the game itself on an external FW drive, an iPod, or even a CD-ROM.
The Unix style of VFS entries pointing to different media isn't as practical on a desktop system as it was on bigass mainframes. On an iMac it wouldn't be terribly practical to stick a second hard drive in in order to mount/usr/local and/Users on it. Practical for a mainframe, impractical for an iMac or most desktops for that matter. Again the OSX method of dealing with this is pretty good. All the Unix stuff is hidden when you view stuff in FInder. You could nuke everything you wanted via Finder and still have a bootable system. It wouldn't be terribly useful but it would at least boot to an extent.
I think the one thing keeping Linux from having real mainstream appeal is the Unix underpinnings it clings to. OSX uses its Unix system as a tool rather than as a paradigm. Application centric systems are much friendlier to users lacking the drive to learn to string together several disparate programs to get a final result. I think most people would rather click a "Search" or hit a V button instead of typing ls ~/Pictures | grep ^Vaca to find their vacation picturesi n a directory. Those same people wouldn't be too keen on typing mailx -s "My vacation pictures" someone@anemailaddress.com to send those pictures to their friend.
You should wear a t-shirt that says "I do not understand economics". Customer acquisition is expensive and time consuming. It is much cheaper to preach to the choir. Selling new products to existing customers costs you far less than trying to get new customers. By making your current customers happy and buying new products you can keep a steady income without increased costs. If your products are especially desirable this practice has the side effect of drawing in new customers, the ones that had been sitting on the fence.
The iTMS is just such a business idea. It is designed to get people who already have a Mac to buy an iPod as well. Their Mac already has the Firewire port and software to run the iPod. All that a lot of people need is a decent excuse to pick one up. The iTMS is just such an excuse. Being able to pick up full high quality albums for $10 is a bargain compared to the retail prices you pay at Best Buy or Sam Goody. If ten million songs generates a hundred thousand iPod sales Apple makes some beaucoup cash. That isn't just $3m in profit from the music downloaded but another $12m from the sales of the iPods for $18m in profit instead of $3m.
The same principle will also bode for the PC. The iTMS is designed to drive sales of iPods. Releasing it on the Mac first lets the profit made from those Macs cover the costs of setting up the service and expand it for use on PCs. The same plan was followed with the iPod itself. It was a Mac-only product for a while before the Windows version was released. The initial Mac release not only rewarded existing customers, making them want to remain customers, but also let the money made from those Macs cover the initial costs of the product.
The way MacOS X solves this problems is a good idea and Linux might do well to learn from it. Applications come in the form of Bundles which are just fancy directories. To the user they are just singular icons in a folder. What makes Bundles special are the special files stored in them that mean something to the OS.
A typical bundle only has one directory at the first level, Contents. In this directory is is the MacOS, Frameworks, Shared Frameworks, Resources, and Shared Support directories. The MacOS directory has the actual application binary. The Resources directory stores stuff like icons, NIB files, and localization strings. The important ones in this case are the Frameworks and Shared Frameworks directories. You get to ship your applications with all the frameworks it needs to run.
The Frameworks directory is where you can stuff all the Frameworks you always want an application to use. If you're using say libSDL and you're pretty sure someone doesn't have it on their systems you might put it in there. If you put it in the Shared Frameworks directory the application will use whatever version of libSDL you packed unless the system has a newer version and in that case will use the newer version. Using Shared Frameworks also lets you package libraries with an application and share them with other applications using the same framework.
The benefits of this should be obvious. No privilege is needed to install applications and their frameworks. A program will just as easily run from ~/Applications as it will from/Applications. Shared Frameworks let you take advantage of newer frameworks existing on the system. It also makes it very easy to install an application. If you really wanted you could just distribute MyApplication.app.tgz foregoing the disk image. Dragging an icon to/Applications and having a new program to do whatever with is a very nice system, even for people who know what they're doing.
Good suggestion. A new Linux user has to open a terminal, know what the hell to even type, then wait for it to download and compile. That will endear Linux into the hearts of the uninitiated.
However easy portage is to use it is not as friendly as an icon on the screen you can click.
There's a couple G4 PowerMac models that break because of the update. The problem lies in the Ethernet driver update. For whatever reason the AppleGMACEthernet.kext driver broke on the update. The 10.2.8 version of the extension is 1.3 while the 10.2.6 version is 1.2.4.
To fix the problem find somebody with a copy of 10.2.6 installed. Tar their AppleGMACEthernet.kext and then put it on your system copying it to/System/Library/Extensions. Restart your system and it will load up the old extension and your ethernet ought to work fine.
That is the worst response ever. You're trying to say Apple as a corporation has no right to protect the work they've put money into developing.
Re:Apple Computer needs to settle.
on
Beatles Bite Apple
·
· Score: 2, Informative
Apple went after Zettabyte because they were blatantly violating iDVD's license. They were putting SDs in the eMacs and distributing them with pirated copies of iDVD. If you bought one of those eMacs you were buying a pirated copy of iDVD because its license required it to come with a Mac originally including a SD.
The C&D letters to the makers of Aqua skins were not presented for copying Aqua's look and feel. The first round of skins were pixmaps made from screenshots of OSX. When people generated their own buttons via GIMP/Photoshop/PSP Apple didn't go after them.
If you're going to try to make a point at least get your facts straight, not straight from Slashdot.
Microsoft's servers are what let MSN users connect to one another. It requires processor cycles, memory, and network bandwidth to have people on MSN message each other. Please explain why Microsoft shouldn't be able to disallow people to connect to their servers? Running MSN costs money. If their service is ad and subscriber supported and you use it without subscribing or seeing the ads they can tell you to buzz off. I doubt you'd like people leeching off your resources, especially ones costing you a bit of money.
You're also a little too eager to point out how my analogy somehow fails to correct the original. My analogy works fine, it is the premise of the analogy that is stupid. The argument of PacBell licensing connectivity to phones manufactured by Uniden is moot. You have the right to do what you want with what you own. If you're using something belonging to someone else you've only got the rights they grant you. Just because a business has a driveway connecting to a public road doesn't mean they can't put a gate on that driveway.
It doesn't matter either if the choise shouldn't be restricted, it is because you don't own it and didn't pay for it. If you want to provide free love and access to the world, you can front the money. Since MSN is the one fronting the money in this case they can tell whomever they please that they have to buy a license to access their network. Until the cost of providing MSN's service costs nothing you don't have an arguement as to the way things ought to be.
Microsoft cares if Microsoft gets hurt. Ergo they are disallowing people with older non-advertising clients to use the netowork. They built it and run it, they have say over who does and doesn't use it.
Your analogy does not work. A proper one would state PacBell/BellSouth/Qwest refused to allow Uniden to manufacture phones that used their telephone lines to make a phone call. The problem with MSN compatibility and licensing isn't about reverse engineering the protocol. Indeed Microsoft can't tell you you're not allowed to reverse engineer it. As long as your implementation is clean they can't say much to you. The issue is with third party clients connecting to MSN's network services, akin to the previously mentioned phone companies' trunks.
MSN owns the network you have to connect to in order to talk to MSN users. Every user on MSN has to connect to a notification server, all conversations take place over one of MSN's switchboards. A third party client then is using MSN network resources without license to do so. Reverse engineering a protocol is not the same as using a network without permission.
Along with the point the sibling reply makes you're also forgetting output of a generator is not as important as the yield delivered to the end user.
If a coal plant is producing 50MWh but transmitting over lines with only 20% efficiency the end usable amount of energy out of burning 50MWh of coal is only 10MWh. Subtract inefficient transformers in the loop and you might only see a total yield of 8MWh out of the 50MWh worth of coal burnt. If each of those 4,000 homes were running their own small generators the total amount of energy they would need to run would be the 8MWh worth they were receiving from the 50MWh burned at the coal plant.
By moving the power generation closer to the end users less fuel is needed to provide the same usable power yield. That is not to necessarily say that biomass gasifers are some magical answer to the nation's power needs. It is however a salient point that a coal plant many miles from its customers is producing way more power than they are capable of receiving from it.
Coal plants take carbon that's been out of circulation for millions of years, put it back into the carbon cycle, and waste a lot of energy on inefficient transmission. Coal plants no matter how many regulations mandate cleanliness are problematic sources of energy. Coal isn't getting more plentiful nor are there any extra carbon sinks popping up to absorb the carbon released by burning coal.
The specific details of "securing" a Windows lab against viruses and worms is really irrelevant. You only need one person connecting to their ISP's e-mail server or one file from an outside computer to infect a whole network. A datacenter might be a different beast but we're talking offices and labs where users need to actually interact with computers, not just leech services off them.
Reimaging is fine and dandy but it costs you extra cash to use Ghost or some other imaging system at your site. Bootable backups of OS9 or X are free with a CD-R. Again you're concerning yourself more with specific patches to Windows' problems. The general issue at hand is the Windows systems are inherently insecure and require much administration and money to keep working properly. The cost of admins for a large lab or office can very easily drive the price of PCs far beyond that of a Mac lab.
As for floppies, they became all but useless with the iMac and all later Macs. Open Firmware does all the things better that a DOS boot disk will do. You can boot off a network, CD, or Firewire drive to get into a live OS to fix problems. I'm sorry but floppies need to get gone.
While $699 may indeed be more money than $500 up front, that doesn't really address the price issue as a whole. When you buy as an institution you have to gauge the system's TCO, not merely the up front cost.
I've seen a number of PC computer labs in the past couple years, Gateways, Dells, and HPs have been most prevelent. In most of the labs I'd say a good 5% of the machines were down at any given time from hardware failure. Each of those failures required one of the lab adminstrators to at the very least diagnose if not fix. A suprising number of times I've seen entire computer labs entirely screwed over by the latest Windows VotW (Virus of the Week).
The several Mac labs I've either administered or have seen have been run by fewer admins and have seen far less downtime. Both OS9 and 10 are relatively simple to manage, even in a large lab environment. OSX works very well with Windows and Unix network shares meaning no third party software to provide such support. OSX Server is very well priced per client than Windows Server 2003 or 2000 Server. The OSX Server can also provide services for Linux, Unix, and Windows systems as well as Macs.
Each down system or per seat cost of a supporting server OS raises the TCO of any purchase. The adminstration costs of a Windows lab will quickly raise the price of the lab over that of an equivilent Mac lab. Say you've got a district with a need for 1000 computers. Admins say are running $50k a year. Per hundred computers you need two MCSEs. Per three hundred eMacs you might only need two admins.
The first year your eMac lab will cost the district $799,000 just in administration and upfront purchasing. The PC lab will cost you $800,000 or so. By virtue of the PCs just needing more care you've eliminated any price advantage they had in the first year. Subsequent years the problem is exacerbated even more, the PC admins are going to suck down $300k a year. The Mac admins only $100k. Over five years the PCs are going to suck two million dollars out of the district coffers. The Macs will cost the district eight hundred thousand dollars less than the PCs despite the higher up front price.
Any institution looking only at the initial system price for computers is foolish and should be removed from their position promptly.
The premise of the article is ridiculous. The entire premise of people needing to learn the programs the "industry" uses is ridiculous. If you work somewhere you have to learn the software your job requires, not infrequently do businesses use software you've never seen before working there.
I had to go downtown to the Hall of Justice one afternoon to pick up some paperwork. Waiting for the clerk to find the file I needed I was looking around the office. On the clerks desk I noticed an X terminal. Some sort of database search program was open on the screen. When the clerk came back I asked her about it and she just knew the box was a "terminal" and it ran her database software. Way back when my city signed a contract with Sun for a bunch of mainframes so I'm betting the terminal was probably hooked up to a Sun mainframe.
That clerk was using a Unix system and X11. It is entirely likely at home she had a PC with Windows running on it. She was a bit older than me so it is even more likely she had never seen a computer in school. She had never used a computer before and was using SunOS daily. Did she know anything about it? Judging from the way she looked at me when I questioned her she didn't seem to know much if anything about the terminal or the mainframe driving it. She was using the terminal because she was trained to click the right buttons on the database app and type the right things in the right spots. Anyone who isn't a complete moron could be taught the same thing.
At a publisher I worked for the pre-press office consisted of about twenty eight Macs. They were all running a program specifically written to layout and work with advertisements. Being as the program has little use outside of pre-press departments dealing with advertisement composing even the most advanced users in the office did't have it at home. I'd be really suprised if any school had ever taught that application specifically.
Several of the people in the office had PCs at homes. All of the advanced (well paid) artists had Macs at home with most of the software in the office - Photoshop, Illustrator, XPress. My friend had a PC at home with those apps on it. At work he used a G4 PowerMac. Some of the people there while very nice people were computer dummies. They were however still able to use a rather purpose specific graphic design application, a custom written database system, and a Wyse terminal in the corner for order processing.
The idea that people can't figure out how to use a PC because they were taught on Macs in school is simply absurd. If you understand basic computing concepts like clicking bottons on a mouse and typing things on a keyboard you can be trained to use just about anything. Thinking you're somehow going to train third graders useful or even applicable computer skills is an obscenely myopic idea. It would be at least ten years before a third grader ever really needed to use a computer in a professional capacity.
Ten years ago DOS was all the rage and networks were voodoo. Teaching a third grader how to do everything in DOS would not be much help to them in today's job market. The Excel XP tips, tricks, and shortcuts will be equally useless in another ten years. What is important is teaching people the concepts of using computers. With the knowlege of concepts anybody can pick up the specifics pretty quickly.
The pre-press workers and clerk I mentioned had been trained to use systems they were entirely unfamiliar with. They understood enough however to know what a keyboard and mouse were for. They were able to grasp the concept that clicking on-screen widgets would cause the program to do things. People who could not so much shut down there computers without help were able to lay out very nice looking advertisements. It is a shame people want public schools to become vocational daycare for minors.
You've really got to be joking. I've yet to run across a Mac lab of any size administered by more than five people. I've yet to see a large installation of Windows systems require fewer than ten adminstrators.
The times I've been in charge of a large number of Macs I've made bootable OS discs. If something goes wrong I simply put the CD in the drive, run Disk Utility to erase the drive, and drag over the System folder. I can have a Mac running in the time it takes to copy the files off a CD. With Charles Srstka's BootCD I can even do that with OSX. Try making a bootable Windows CD sometime, I guarantee is makes for an entertaining experience.
As for worms and viruses, no data center can be 100% immune from Windows' inherent security problems. A decent firewall can keep protected systems from being exposed to random search worm attacks, a virus scanner can remove infected files, but no one can protect computers from dumb users. Opening viral e-mail attachments will be a problem on Windows for quite a while yet. Viral e-mail attachments that can propogate via network connections can take down even a properly administered datacenter or lab. Look at the problems Melissa caused and all it did was e-mail itself to people.
I also don't understand your "defense" of floppies. They are horrendously slow and markedly unreliable. The failure rate of a box of floppies is pretty horrible. Sometimes the slightest bend or push will damage a floppy's disc or door mechanism. The floppy drives themselves are also of horrible quality. On my PC I've had horrible problems with floppies written by other computers. Work floppies when home mysteriously become unformatted and useless sometimes. It will be a nice day when PCs can finally manage to move away from the floppy entirely.
I'm a best tool for the job advocate. The GPL is indeed the best tool for the job in several situations, in others it fails miserably. The original comment was in regards to Apple using Open Source soley as a PR scheme because the APSL is not as "Free" as the GPL. I think that sort of opinion is quite a bit off. In a situation where a company, Apple in this case, wants to sell a product but also release a Free product the GPL alone is not a viable license. TrollTech is in the same situation. Apple and TrollTech would not be able to produce only GPL works and expect to make any money using them.
Apple's changes to KHTML are open and available. KHTML has benefitted a great deal from the work Apple put in to tailor KHTML to their needs. This is a great example of free-but-not-as-copyleft-as-the-GPL licensing working for open source and proprietary groups. Apple got an excellent HTML rendering engine and the community got support in the form of the money Apple spent paying their developers to work on KHTML. It was a win-win situation for both groups. CUPS is in the same position, Apple's adopting its use because it is free and open and it provides them important functionality. Print Center and the Cocoa printing frameworks aren't open source but they are the money maker that supports the development of CUPS.
If someone reads and understands the GPL it is easy to see it is possible to make Free software and still make money. You just need to stack other licensing on top of the GPL in order to keep the cheapskates from taking advantage of your generosity. TrollTech has managed this by using the QPL to add usage stipulations to their GPL'ed code. Apple has done this by avoiding the GPL for a more author friendly yet still sort of Free license. The best tool for the job will usually benefit everybody in the end.
I'm not contradicting myself. Saying the GPL is "harmful" to developers and then saying TrollTech's business model is undermined by Qt's GPL license go hand in hand. Without their QPL license on top of the GPL license, Qt/Free would take over Qt/Commercial's market. No one will pay for what they can get for free. The QPL is what requires you to use Qt/Free in only non-profit products, the GPL alone doesn't stipulate that.
You yourself are running into the issue of IP and idea infringement. You've got ideas and IP you're implemented. I can download the source to your program, fork the code, then go on making my own version of that program using a bunch of your code. You might consider it theft but with the GPL you're requiring yourself to give up the bread and butter of your IP, the source code. Imagine if you were selling your application, I could buy a single copy from you and put it on CD to sell myself and not give you a dime.
You're giving away your software and are concerned about IP theft. The situation is far worse when you're trying to pay rent with your software sales. That is why the APSL is less Free than the GPL, it provides more protection and control for the code's author than the GPL allows for.
Red Hat's money is made off selling services attached to otherwise free software. When you buy a Red Hat Pro bundle for $149 you're paying for the printed manual, phone support, and access to their non-public (faster) update service. It's a good idea not to confuse the difference between selling a service and selling a product. Red Hat couldn't sell a copy of Linux with no services for $149, CheapBytes would have put them out of business a long time ago if that were the case.
Your history is a little off unfortunately. Before the NeXT acquisition Apple had been working on the successor to MacOS 7, called Copland. The idea behind Copland was to get rid of all the cruft that no one used or no one was supposed to be using anymore. Copland was intended to run classic Mac applications in an emulation environment akin to Classic on OSX. Copland-aware apps were going to be the equivilent of Carbon apps in OSX now. They would be preemptive and have protected memory spaces. They would also be allowed to create real threads.
After about two years Apple finally killed the Copland project. It was horribly overdue and many of the components were going nowhere. Late in 96 Apple bought NeXT for ?$430m. In January of 97 Steve Jobs was an "advisor" to Apple from the NeXT deal. He was not then actually CEO. Basing Rhapsody (OSX) on NeXTSTEP had been the contingency plan after Copland washed out.
Basing your opinion of the Cocoa/OpenStep API based on the commercial failure of NeXT hardware is a bit ridiculous. The API is not the reason NeXT hardware sold poorly. NeXTStations were expensive, moreso even than the egregiously overpriced Macs of the time. Breaking into a populated market is difficult at best and impossible at worst. NeXT sold expensive computers with remarkable hardware quality and an awesome OS but no killer app.
That has nothing to do with the quality of the OpenStep API however. The OpenStep, now Cocoa, API is well designed and very robust. Play around in GNUStep or Cocoa for a little while sometime. The API is easy to work with and very verbose which requires a lot of typing but in the end makes for very easily understood code. Designed to run inside of a host OS, OpenStep is extraordinarily portable and abstracts as much as possible from the developer. The source code in Building Cocoa Applications: A Step by Step Guide by Simson Garfinkle and Michael Mahoney is nearly identical in every way to the code in NeXTSTEP Programming: Step One written by Simson Garfinkle. A lot of the text of the book regarding the applications themselves is also similar if not identical. The only real changes between the two books are OSX or NeXTSTEP specific topics and explanations. Those same examples will Sun's OpenStep implemantation and GNUStep. How the history of the API somehow invalidates those facts I don't seem to understand. Nor does the history show in any way that developers hate working with it.
Even with dual licensing the GPL is not an author centric or even friendly license. Copylefting in and of itself is a pro-information anti-author action. That is not to say the GPL is somehow evil or a bad license. The concept of the GPL is to eliminate the control over the use of the software traditional copyright allows.
The only saving grace of Qt's licensing is the QPL which prevents the "Free" version of Qt from being used to make commercial software. In order to make commercial software developers need to fork over dough for the "Commercial" edition. If Qt was licensed only under the GPL and their commercial license TrollTech would have no way to control how their GPL edition was used. Anybody could get ahold of the GPL code and make all the commercial software they wanted with it and TrollTech wouldn't see a dime.
With GPL code you can't go an produce a proprietary version of it with added features then distributed it binary only to sell. Even if your proprietary code is a separate module or some such linking to GPL code is enough to consider the proprietary code a derivitive work and thus requires it to be covered under the GPL. Even connecting to GPL code via SOAP, CORBA, XML-RPC, and various other methods can be considered derivitive works depending on who you talk to and the time of day. The question of derivitive work is overly complex and does not lend itself well to distributing special proprietary versions of a GPL'ed codebase.
Dual licensing is not the end of a developers woes. TrollTech needs their QPL to prevent their GPL version of Qt from undermining their Commercial version. As I pointed out, the GPL itself is not friendly to software authors. The GPL combined with end use agreements or other licenses can work. The LGPL is a very good license for proprietary software developers as well. The GPL exists to make sure source code is virally free. By making the software free however, the GPL sticks authors in a bind trying to sell it. The GPL alone lets anyone take all of the authors work and redistribute it without any compensation going to the original author. That's nice for the community but not so nice for the author if she ever decided to make money off that software.
Chin up buckeroo. The "open source" ideology is one that is software centric rather than author centric. The GPL compatible licenses the FSF fully approves are designed to provide as much movability for the software without giving the author much in the way of recompense outside of community recognition. Information may want to be free but rent and stockholders want to be paid.
You're whining because you're inately jealous of what Apple's been able to do with Free code they've used in their products or based their products off of. Apple's taken a bunch of technologies and standards that have been floating in Limbo waiting for someone to actually do something useful and made a good product out of it. Now you want them to release all of their implementations so the next version of Linux can offer all of the features without any of the development time or cost. That is plainly stupid.
Take Redevous (zeroconf/service discovery). Apple took a languishing technology and turned it into a huge feature in their OS. They've also released enough documentation and code for Rendevous to make it simplistic for any developer to work their own implementation of it. If Linux developers hopped on the good foot they could have all the Rendevous functionality they wanted and be entirely compatible with all the services Apple's working with.
Not everyone can make money selling advertisements on their website, ergo they need to sell software or even hardware. To do so you need something your competition doesn't. Apple's in a good position because they've made themselves extremely compatible with the competition and provide incentives for using their products. You can use KHTML all you want in Konq or some other browser. In OSX you can use Konq if you want but they're offering Safari. Anybody can use CUPS for printing, Apple stuck Print Center on top of it and is offering that as an incentive to use their products.
Stop your whining about Apple using OS for PR benefits only. They've put some good money into GCC, CUPS, KHTML, and making OSX fully compatible with FreeBSD. Go check your kernel compile and stop whining about Apple's use of software.
For my $129 I got an OpenGL accelerated desktop, a system wide address book with a public API, great support for zeroconf networking and service discovery, CIFS/SMB support, and an AOL compatible instant messenger to boot. I figure I got quite a number of enhancements over the previous version of OSX. A.Mac subscription is entirely optional, I don't have one and don't miss it.
I don't see why $129 seems so expensive to you either. OSX was released in March of 2001. It didn't perform nearly as well as advertised and the update was released in September. The first update (10.1) only cost 10.0 users a penny to upgrade to a signifigant performance increase. Jaguar (10.2) was released in late August of 2002, a year and a handful of months after the original OSX release. Panther (10.3) doesn't look like it will be released until late in the fall. That's about 16 months between paid upgrades for the OS. That is only $8 a month that a copy of OSX costs. That is two less Frappucinos a month for 16 months and you've saved enough change to buy a new version of OSX. That's also assuming you buy upgrades the day they're released, there's little reason to upgrade to Panther if Jaguar's running fine and dnady for you. There's still plenty of folks running releases of 10.1 because it runs well enough for them not to justify an upgrade to 10.2. If $129 is so much you might want to reconsider your "career" as a McDonalds grease engineer.
Darwin is great and all, but many of us already have a kernel to use. Apple may say they embrace open source but when are they going to release code to some of the various software that makes OSX unique?
Wow I sure do like all the nifty features of OSX. I don't understand the fact that giving away the very technology that draws in customers, thus commoditizing the product, would be a stupid business move.
When they decided to use KHTML for Safari, I thought they would at least release the source code for Safari and not just the changes to KHTML.. Its not like Safari is innovative or anything, we already have better open source browsers, but releasing the source code would of been a nice gesture.
Apple should give away any and all software that draws customers to their platform. That way they no longer have to bother with selling hardware of any sort. Since their software should all be open source they can just make money selling advertisements. I'm sure they could make a couple hundred dollars a month at least. That's way more than my mom gives me!
Slashdot Mirror
Did you even read my reply? Your response reads like you're concentrating really hard on sticking a bowling pin up your ass and not paying any attention to anything else you're doing. Apple sells to its current customers because they can make a steady income that way. Repeat customers are good for business, new customers typically aren't because the cost of aquiring them is usually more than you make off them. While a small percentage of PC users will switch to a Mac simply to get an iPod and use iTMS a large percentage of Mac users will do just that. They already have the Mac with the needed software support. An early Christmas present later and they can take all of their music with them be it from a CD or iTMS.
Save your "golden ears" bullshit for someone else. That argument is absolutely ridiculous. For a majority of music consumers a 128kbps AAC is more than fine, especially when the AACs from iTMS are encoded from 24-bit 48KHz masters. A 128kbps AAC is phsycoacoustically identical to the music coming off a CD. A majority of music customers are not audiophiles and do not have $2,000+ audio systems. Most people have stereos from Wal-Mart that cost less than $200 or a set of speakers on their computer that maybe set them back $30.
How come people are Apple fan boy cheerleaders when you make retarded arguments?
You don't have to include any Frameworks with your application if you don't feel you need to. If you're using only system Frameworks or ones you can reasonably expect to exist on the system you only need to ship the binary and its resources in the bundle. Safari is a good example.
/System/Library/Frameworks. Now any application can use WebKit. The only time you really need to include libraries with your application is when you use stuff the system isn't likely to have. If you're going to write a bunch of applications using a custom framework it'd probably be best to just install the framework onto the system.
/usr/local and /Users on it. Practical for a mainframe, impractical for an iMac or most desktops for that matter. Again the OSX method of dealing with this is pretty good. All the Unix stuff is hidden when you view stuff in FInder. You could nuke everything you wanted via Finder and still have a bootable system. It wouldn't be terribly useful but it would at least boot to an extent.
In the beta versions of Safari the WebCore and JavaScriptCore frameworks were shipped in the app bundle. As they didn't exist on the system then it needed to ship with them. As soon as Safari went 1.0 Apple moved the frameworks WebKit.framework and stuck that in
UT2003 pulls sort of the opposite trick than Safari 1.0. UT2003 packs everything the game needs into a single bundle. Everything from the game models to its version of libSDL are stuffed into the application bundle. While the bundle is over 200MB for the demo it is easy to move to some other media. Since the configuration file is stored in ~/Library/Application Support/Unreal Tournament 2003/ you can put the game itself on an external FW drive, an iPod, or even a CD-ROM.
The Unix style of VFS entries pointing to different media isn't as practical on a desktop system as it was on bigass mainframes. On an iMac it wouldn't be terribly practical to stick a second hard drive in in order to mount
I think the one thing keeping Linux from having real mainstream appeal is the Unix underpinnings it clings to. OSX uses its Unix system as a tool rather than as a paradigm. Application centric systems are much friendlier to users lacking the drive to learn to string together several disparate programs to get a final result. I think most people would rather click a "Search" or hit a V button instead of typing ls ~/Pictures | grep ^Vaca to find their vacation picturesi n a directory. Those same people wouldn't be too keen on typing mailx -s "My vacation pictures" someone@anemailaddress.com to send those pictures to their friend.
You should wear a t-shirt that says "I do not understand economics". Customer acquisition is expensive and time consuming. It is much cheaper to preach to the choir. Selling new products to existing customers costs you far less than trying to get new customers. By making your current customers happy and buying new products you can keep a steady income without increased costs. If your products are especially desirable this practice has the side effect of drawing in new customers, the ones that had been sitting on the fence.
The iTMS is just such a business idea. It is designed to get people who already have a Mac to buy an iPod as well. Their Mac already has the Firewire port and software to run the iPod. All that a lot of people need is a decent excuse to pick one up. The iTMS is just such an excuse. Being able to pick up full high quality albums for $10 is a bargain compared to the retail prices you pay at Best Buy or Sam Goody. If ten million songs generates a hundred thousand iPod sales Apple makes some beaucoup cash. That isn't just $3m in profit from the music downloaded but another $12m from the sales of the iPods for $18m in profit instead of $3m.
The same principle will also bode for the PC. The iTMS is designed to drive sales of iPods. Releasing it on the Mac first lets the profit made from those Macs cover the costs of setting up the service and expand it for use on PCs. The same plan was followed with the iPod itself. It was a Mac-only product for a while before the Windows version was released. The initial Mac release not only rewarded existing customers, making them want to remain customers, but also let the money made from those Macs cover the initial costs of the product.
Buy an econ book.
The way MacOS X solves this problems is a good idea and Linux might do well to learn from it. Applications come in the form of Bundles which are just fancy directories. To the user they are just singular icons in a folder. What makes Bundles special are the special files stored in them that mean something to the OS.
/Applications. Shared Frameworks let you take advantage of newer frameworks existing on the system. It also makes it very easy to install an application. If you really wanted you could just distribute MyApplication.app.tgz foregoing the disk image. Dragging an icon to /Applications and having a new program to do whatever with is a very nice system, even for people who know what they're doing.
A typical bundle only has one directory at the first level, Contents. In this directory is is the MacOS, Frameworks, Shared Frameworks, Resources, and Shared Support directories. The MacOS directory has the actual application binary. The Resources directory stores stuff like icons, NIB files, and localization strings. The important ones in this case are the Frameworks and Shared Frameworks directories. You get to ship your applications with all the frameworks it needs to run.
The Frameworks directory is where you can stuff all the Frameworks you always want an application to use. If you're using say libSDL and you're pretty sure someone doesn't have it on their systems you might put it in there. If you put it in the Shared Frameworks directory the application will use whatever version of libSDL you packed unless the system has a newer version and in that case will use the newer version. Using Shared Frameworks also lets you package libraries with an application and share them with other applications using the same framework.
The benefits of this should be obvious. No privilege is needed to install applications and their frameworks. A program will just as easily run from ~/Applications as it will from
Good suggestion. A new Linux user has to open a terminal, know what the hell to even type, then wait for it to download and compile. That will endear Linux into the hearts of the uninitiated.
However easy portage is to use it is not as friendly as an icon on the screen you can click.
There's a couple G4 PowerMac models that break because of the update. The problem lies in the Ethernet driver update. For whatever reason the AppleGMACEthernet.kext driver broke on the update. The 10.2.8 version of the extension is 1.3 while the 10.2.6 version is 1.2.4.
/System/Library/Extensions. Restart your system and it will load up the old extension and your ethernet ought to work fine.
To fix the problem find somebody with a copy of 10.2.6 installed. Tar their AppleGMACEthernet.kext and then put it on your system copying it to
That is the worst response ever. You're trying to say Apple as a corporation has no right to protect the work they've put money into developing.
Apple went after Zettabyte because they were blatantly violating iDVD's license. They were putting SDs in the eMacs and distributing them with pirated copies of iDVD. If you bought one of those eMacs you were buying a pirated copy of iDVD because its license required it to come with a Mac originally including a SD.
The C&D letters to the makers of Aqua skins were not presented for copying Aqua's look and feel. The first round of skins were pixmaps made from screenshots of OSX. When people generated their own buttons via GIMP/Photoshop/PSP Apple didn't go after them.
If you're going to try to make a point at least get your facts straight, not straight from Slashdot.
The 17" has a prismatic (square cell) Li-ion battery, the 12", 15" and iBook all use old style cylindrical Li-ions.
Microsoft's servers are what let MSN users connect to one another. It requires processor cycles, memory, and network bandwidth to have people on MSN message each other. Please explain why Microsoft shouldn't be able to disallow people to connect to their servers? Running MSN costs money. If their service is ad and subscriber supported and you use it without subscribing or seeing the ads they can tell you to buzz off. I doubt you'd like people leeching off your resources, especially ones costing you a bit of money.
You're also a little too eager to point out how my analogy somehow fails to correct the original. My analogy works fine, it is the premise of the analogy that is stupid. The argument of PacBell licensing connectivity to phones manufactured by Uniden is moot. You have the right to do what you want with what you own. If you're using something belonging to someone else you've only got the rights they grant you. Just because a business has a driveway connecting to a public road doesn't mean they can't put a gate on that driveway.
It doesn't matter either if the choise shouldn't be restricted, it is because you don't own it and didn't pay for it. If you want to provide free love and access to the world, you can front the money. Since MSN is the one fronting the money in this case they can tell whomever they please that they have to buy a license to access their network. Until the cost of providing MSN's service costs nothing you don't have an arguement as to the way things ought to be.
Microsoft cares if Microsoft gets hurt. Ergo they are disallowing people with older non-advertising clients to use the netowork. They built it and run it, they have say over who does and doesn't use it.
Your analogy does not work. A proper one would state PacBell/BellSouth/Qwest refused to allow Uniden to manufacture phones that used their telephone lines to make a phone call. The problem with MSN compatibility and licensing isn't about reverse engineering the protocol. Indeed Microsoft can't tell you you're not allowed to reverse engineer it. As long as your implementation is clean they can't say much to you. The issue is with third party clients connecting to MSN's network services, akin to the previously mentioned phone companies' trunks.
MSN owns the network you have to connect to in order to talk to MSN users. Every user on MSN has to connect to a notification server, all conversations take place over one of MSN's switchboards. A third party client then is using MSN network resources without license to do so. Reverse engineering a protocol is not the same as using a network without permission.
Along with the point the sibling reply makes you're also forgetting output of a generator is not as important as the yield delivered to the end user.
If a coal plant is producing 50MWh but transmitting over lines with only 20% efficiency the end usable amount of energy out of burning 50MWh of coal is only 10MWh. Subtract inefficient transformers in the loop and you might only see a total yield of 8MWh out of the 50MWh worth of coal burnt. If each of those 4,000 homes were running their own small generators the total amount of energy they would need to run would be the 8MWh worth they were receiving from the 50MWh burned at the coal plant.
By moving the power generation closer to the end users less fuel is needed to provide the same usable power yield. That is not to necessarily say that biomass gasifers are some magical answer to the nation's power needs. It is however a salient point that a coal plant many miles from its customers is producing way more power than they are capable of receiving from it.
Coal plants take carbon that's been out of circulation for millions of years, put it back into the carbon cycle, and waste a lot of energy on inefficient transmission. Coal plants no matter how many regulations mandate cleanliness are problematic sources of energy. Coal isn't getting more plentiful nor are there any extra carbon sinks popping up to absorb the carbon released by burning coal.
The specific details of "securing" a Windows lab against viruses and worms is really irrelevant. You only need one person connecting to their ISP's e-mail server or one file from an outside computer to infect a whole network. A datacenter might be a different beast but we're talking offices and labs where users need to actually interact with computers, not just leech services off them.
Reimaging is fine and dandy but it costs you extra cash to use Ghost or some other imaging system at your site. Bootable backups of OS9 or X are free with a CD-R. Again you're concerning yourself more with specific patches to Windows' problems. The general issue at hand is the Windows systems are inherently insecure and require much administration and money to keep working properly. The cost of admins for a large lab or office can very easily drive the price of PCs far beyond that of a Mac lab.
As for floppies, they became all but useless with the iMac and all later Macs. Open Firmware does all the things better that a DOS boot disk will do. You can boot off a network, CD, or Firewire drive to get into a live OS to fix problems. I'm sorry but floppies need to get gone.
While $699 may indeed be more money than $500 up front, that doesn't really address the price issue as a whole. When you buy as an institution you have to gauge the system's TCO, not merely the up front cost.
I've seen a number of PC computer labs in the past couple years, Gateways, Dells, and HPs have been most prevelent. In most of the labs I'd say a good 5% of the machines were down at any given time from hardware failure. Each of those failures required one of the lab adminstrators to at the very least diagnose if not fix. A suprising number of times I've seen entire computer labs entirely screwed over by the latest Windows VotW (Virus of the Week).
The several Mac labs I've either administered or have seen have been run by fewer admins and have seen far less downtime. Both OS9 and 10 are relatively simple to manage, even in a large lab environment. OSX works very well with Windows and Unix network shares meaning no third party software to provide such support. OSX Server is very well priced per client than Windows Server 2003 or 2000 Server. The OSX Server can also provide services for Linux, Unix, and Windows systems as well as Macs.
Each down system or per seat cost of a supporting server OS raises the TCO of any purchase. The adminstration costs of a Windows lab will quickly raise the price of the lab over that of an equivilent Mac lab. Say you've got a district with a need for 1000 computers. Admins say are running $50k a year. Per hundred computers you need two MCSEs. Per three hundred eMacs you might only need two admins.
The first year your eMac lab will cost the district $799,000 just in administration and upfront purchasing. The PC lab will cost you $800,000 or so. By virtue of the PCs just needing more care you've eliminated any price advantage they had in the first year. Subsequent years the problem is exacerbated even more, the PC admins are going to suck down $300k a year. The Mac admins only $100k. Over five years the PCs are going to suck two million dollars out of the district coffers. The Macs will cost the district eight hundred thousand dollars less than the PCs despite the higher up front price.
Any institution looking only at the initial system price for computers is foolish and should be removed from their position promptly.
The premise of the article is ridiculous. The entire premise of people needing to learn the programs the "industry" uses is ridiculous. If you work somewhere you have to learn the software your job requires, not infrequently do businesses use software you've never seen before working there.
I had to go downtown to the Hall of Justice one afternoon to pick up some paperwork. Waiting for the clerk to find the file I needed I was looking around the office. On the clerks desk I noticed an X terminal. Some sort of database search program was open on the screen. When the clerk came back I asked her about it and she just knew the box was a "terminal" and it ran her database software. Way back when my city signed a contract with Sun for a bunch of mainframes so I'm betting the terminal was probably hooked up to a Sun mainframe.
That clerk was using a Unix system and X11. It is entirely likely at home she had a PC with Windows running on it. She was a bit older than me so it is even more likely she had never seen a computer in school. She had never used a computer before and was using SunOS daily. Did she know anything about it? Judging from the way she looked at me when I questioned her she didn't seem to know much if anything about the terminal or the mainframe driving it. She was using the terminal because she was trained to click the right buttons on the database app and type the right things in the right spots. Anyone who isn't a complete moron could be taught the same thing.
At a publisher I worked for the pre-press office consisted of about twenty eight Macs. They were all running a program specifically written to layout and work with advertisements. Being as the program has little use outside of pre-press departments dealing with advertisement composing even the most advanced users in the office did't have it at home. I'd be really suprised if any school had ever taught that application specifically.
Several of the people in the office had PCs at homes. All of the advanced (well paid) artists had Macs at home with most of the software in the office - Photoshop, Illustrator, XPress. My friend had a PC at home with those apps on it. At work he used a G4 PowerMac. Some of the people there while very nice people were computer dummies. They were however still able to use a rather purpose specific graphic design application, a custom written database system, and a Wyse terminal in the corner for order processing.
The idea that people can't figure out how to use a PC because they were taught on Macs in school is simply absurd. If you understand basic computing concepts like clicking bottons on a mouse and typing things on a keyboard you can be trained to use just about anything. Thinking you're somehow going to train third graders useful or even applicable computer skills is an obscenely myopic idea. It would be at least ten years before a third grader ever really needed to use a computer in a professional capacity.
Ten years ago DOS was all the rage and networks were voodoo. Teaching a third grader how to do everything in DOS would not be much help to them in today's job market. The Excel XP tips, tricks, and shortcuts will be equally useless in another ten years. What is important is teaching people the concepts of using computers. With the knowlege of concepts anybody can pick up the specifics pretty quickly.
The pre-press workers and clerk I mentioned had been trained to use systems they were entirely unfamiliar with. They understood enough however to know what a keyboard and mouse were for. They were able to grasp the concept that clicking on-screen widgets would cause the program to do things. People who could not so much shut down there computers without help were able to lay out very nice looking advertisements. It is a shame people want public schools to become vocational daycare for minors.
You've really got to be joking. I've yet to run across a Mac lab of any size administered by more than five people. I've yet to see a large installation of Windows systems require fewer than ten adminstrators.
The times I've been in charge of a large number of Macs I've made bootable OS discs. If something goes wrong I simply put the CD in the drive, run Disk Utility to erase the drive, and drag over the System folder. I can have a Mac running in the time it takes to copy the files off a CD. With Charles Srstka's BootCD I can even do that with OSX. Try making a bootable Windows CD sometime, I guarantee is makes for an entertaining experience.
As for worms and viruses, no data center can be 100% immune from Windows' inherent security problems. A decent firewall can keep protected systems from being exposed to random search worm attacks, a virus scanner can remove infected files, but no one can protect computers from dumb users. Opening viral e-mail attachments will be a problem on Windows for quite a while yet. Viral e-mail attachments that can propogate via network connections can take down even a properly administered datacenter or lab. Look at the problems Melissa caused and all it did was e-mail itself to people.
I also don't understand your "defense" of floppies. They are horrendously slow and markedly unreliable. The failure rate of a box of floppies is pretty horrible. Sometimes the slightest bend or push will damage a floppy's disc or door mechanism. The floppy drives themselves are also of horrible quality. On my PC I've had horrible problems with floppies written by other computers. Work floppies when home mysteriously become unformatted and useless sometimes. It will be a nice day when PCs can finally manage to move away from the floppy entirely.
I'm a best tool for the job advocate. The GPL is indeed the best tool for the job in several situations, in others it fails miserably. The original comment was in regards to Apple using Open Source soley as a PR scheme because the APSL is not as "Free" as the GPL. I think that sort of opinion is quite a bit off. In a situation where a company, Apple in this case, wants to sell a product but also release a Free product the GPL alone is not a viable license. TrollTech is in the same situation. Apple and TrollTech would not be able to produce only GPL works and expect to make any money using them.
Apple's changes to KHTML are open and available. KHTML has benefitted a great deal from the work Apple put in to tailor KHTML to their needs. This is a great example of free-but-not-as-copyleft-as-the-GPL licensing working for open source and proprietary groups. Apple got an excellent HTML rendering engine and the community got support in the form of the money Apple spent paying their developers to work on KHTML. It was a win-win situation for both groups. CUPS is in the same position, Apple's adopting its use because it is free and open and it provides them important functionality. Print Center and the Cocoa printing frameworks aren't open source but they are the money maker that supports the development of CUPS.
If someone reads and understands the GPL it is easy to see it is possible to make Free software and still make money. You just need to stack other licensing on top of the GPL in order to keep the cheapskates from taking advantage of your generosity. TrollTech has managed this by using the QPL to add usage stipulations to their GPL'ed code. Apple has done this by avoiding the GPL for a more author friendly yet still sort of Free license. The best tool for the job will usually benefit everybody in the end.
I'm not contradicting myself. Saying the GPL is "harmful" to developers and then saying TrollTech's business model is undermined by Qt's GPL license go hand in hand. Without their QPL license on top of the GPL license, Qt/Free would take over Qt/Commercial's market. No one will pay for what they can get for free. The QPL is what requires you to use Qt/Free in only non-profit products, the GPL alone doesn't stipulate that.
You yourself are running into the issue of IP and idea infringement. You've got ideas and IP you're implemented. I can download the source to your program, fork the code, then go on making my own version of that program using a bunch of your code. You might consider it theft but with the GPL you're requiring yourself to give up the bread and butter of your IP, the source code. Imagine if you were selling your application, I could buy a single copy from you and put it on CD to sell myself and not give you a dime.
You're giving away your software and are concerned about IP theft. The situation is far worse when you're trying to pay rent with your software sales. That is why the APSL is less Free than the GPL, it provides more protection and control for the code's author than the GPL allows for.
Red Hat's money is made off selling services attached to otherwise free software. When you buy a Red Hat Pro bundle for $149 you're paying for the printed manual, phone support, and access to their non-public (faster) update service. It's a good idea not to confuse the difference between selling a service and selling a product. Red Hat couldn't sell a copy of Linux with no services for $149, CheapBytes would have put them out of business a long time ago if that were the case.
Your history is a little off unfortunately. Before the NeXT acquisition Apple had been working on the successor to MacOS 7, called Copland. The idea behind Copland was to get rid of all the cruft that no one used or no one was supposed to be using anymore. Copland was intended to run classic Mac applications in an emulation environment akin to Classic on OSX. Copland-aware apps were going to be the equivilent of Carbon apps in OSX now. They would be preemptive and have protected memory spaces. They would also be allowed to create real threads.
After about two years Apple finally killed the Copland project. It was horribly overdue and many of the components were going nowhere. Late in 96 Apple bought NeXT for ?$430m. In January of 97 Steve Jobs was an "advisor" to Apple from the NeXT deal. He was not then actually CEO. Basing Rhapsody (OSX) on NeXTSTEP had been the contingency plan after Copland washed out.
Basing your opinion of the Cocoa/OpenStep API based on the commercial failure of NeXT hardware is a bit ridiculous. The API is not the reason NeXT hardware sold poorly. NeXTStations were expensive, moreso even than the egregiously overpriced Macs of the time. Breaking into a populated market is difficult at best and impossible at worst. NeXT sold expensive computers with remarkable hardware quality and an awesome OS but no killer app.
That has nothing to do with the quality of the OpenStep API however. The OpenStep, now Cocoa, API is well designed and very robust. Play around in GNUStep or Cocoa for a little while sometime. The API is easy to work with and very verbose which requires a lot of typing but in the end makes for very easily understood code. Designed to run inside of a host OS, OpenStep is extraordinarily portable and abstracts as much as possible from the developer. The source code in Building Cocoa Applications: A Step by Step Guide by Simson Garfinkle and Michael Mahoney is nearly identical in every way to the code in NeXTSTEP Programming: Step One written by Simson Garfinkle. A lot of the text of the book regarding the applications themselves is also similar if not identical. The only real changes between the two books are OSX or NeXTSTEP specific topics and explanations. Those same examples will Sun's OpenStep implemantation and GNUStep. How the history of the API somehow invalidates those facts I don't seem to understand. Nor does the history show in any way that developers hate working with it.
Even with dual licensing the GPL is not an author centric or even friendly license. Copylefting in and of itself is a pro-information anti-author action. That is not to say the GPL is somehow evil or a bad license. The concept of the GPL is to eliminate the control over the use of the software traditional copyright allows.
The only saving grace of Qt's licensing is the QPL which prevents the "Free" version of Qt from being used to make commercial software. In order to make commercial software developers need to fork over dough for the "Commercial" edition. If Qt was licensed only under the GPL and their commercial license TrollTech would have no way to control how their GPL edition was used. Anybody could get ahold of the GPL code and make all the commercial software they wanted with it and TrollTech wouldn't see a dime.
With GPL code you can't go an produce a proprietary version of it with added features then distributed it binary only to sell. Even if your proprietary code is a separate module or some such linking to GPL code is enough to consider the proprietary code a derivitive work and thus requires it to be covered under the GPL. Even connecting to GPL code via SOAP, CORBA, XML-RPC, and various other methods can be considered derivitive works depending on who you talk to and the time of day. The question of derivitive work is overly complex and does not lend itself well to distributing special proprietary versions of a GPL'ed codebase.
Dual licensing is not the end of a developers woes. TrollTech needs their QPL to prevent their GPL version of Qt from undermining their Commercial version. As I pointed out, the GPL itself is not friendly to software authors. The GPL combined with end use agreements or other licenses can work. The LGPL is a very good license for proprietary software developers as well. The GPL exists to make sure source code is virally free. By making the software free however, the GPL sticks authors in a bind trying to sell it. The GPL alone lets anyone take all of the authors work and redistribute it without any compensation going to the original author. That's nice for the community but not so nice for the author if she ever decided to make money off that software.
Chin up buckeroo. The "open source" ideology is one that is software centric rather than author centric. The GPL compatible licenses the FSF fully approves are designed to provide as much movability for the software without giving the author much in the way of recompense outside of community recognition. Information may want to be free but rent and stockholders want to be paid.
You're whining because you're inately jealous of what Apple's been able to do with Free code they've used in their products or based their products off of. Apple's taken a bunch of technologies and standards that have been floating in Limbo waiting for someone to actually do something useful and made a good product out of it. Now you want them to release all of their implementations so the next version of Linux can offer all of the features without any of the development time or cost. That is plainly stupid.
Take Redevous (zeroconf/service discovery). Apple took a languishing technology and turned it into a huge feature in their OS. They've also released enough documentation and code for Rendevous to make it simplistic for any developer to work their own implementation of it. If Linux developers hopped on the good foot they could have all the Rendevous functionality they wanted and be entirely compatible with all the services Apple's working with.
Not everyone can make money selling advertisements on their website, ergo they need to sell software or even hardware. To do so you need something your competition doesn't. Apple's in a good position because they've made themselves extremely compatible with the competition and provide incentives for using their products. You can use KHTML all you want in Konq or some other browser. In OSX you can use Konq if you want but they're offering Safari. Anybody can use CUPS for printing, Apple stuck Print Center on top of it and is offering that as an incentive to use their products.
Stop your whining about Apple using OS for PR benefits only. They've put some good money into GCC, CUPS, KHTML, and making OSX fully compatible with FreeBSD. Go check your kernel compile and stop whining about Apple's use of software.
For my $129 I got an OpenGL accelerated desktop, a system wide address book with a public API, great support for zeroconf networking and service discovery, CIFS/SMB support, and an AOL compatible instant messenger to boot. I figure I got quite a number of enhancements over the previous version of OSX. A .Mac subscription is entirely optional, I don't have one and don't miss it.
I don't see why $129 seems so expensive to you either. OSX was released in March of 2001. It didn't perform nearly as well as advertised and the update was released in September. The first update (10.1) only cost 10.0 users a penny to upgrade to a signifigant performance increase. Jaguar (10.2) was released in late August of 2002, a year and a handful of months after the original OSX release. Panther (10.3) doesn't look like it will be released until late in the fall. That's about 16 months between paid upgrades for the OS. That is only $8 a month that a copy of OSX costs. That is two less Frappucinos a month for 16 months and you've saved enough change to buy a new version of OSX. That's also assuming you buy upgrades the day they're released, there's little reason to upgrade to Panther if Jaguar's running fine and dnady for you. There's still plenty of folks running releases of 10.1 because it runs well enough for them not to justify an upgrade to 10.2. If $129 is so much you might want to reconsider your "career" as a McDonalds grease engineer.
Linux Whiner Translate-O-Matic:
Darwin is great and all, but many of us already have a kernel to use. Apple may say they embrace open source but when are they going to release code to some of the various software that makes OSX unique?
Wow I sure do like all the nifty features of OSX. I don't understand the fact that giving away the very technology that draws in customers, thus commoditizing the product, would be a stupid business move.
When they decided to use KHTML for Safari, I thought they would at least release the source code for Safari and not just the changes to KHTML.. Its not like Safari is innovative or anything, we already have better open source browsers, but releasing the source code would of been a nice gesture.
Apple should give away any and all software that draws customers to their platform. That way they no longer have to bother with selling hardware of any sort. Since their software should all be open source they can just make money selling advertisements. I'm sure they could make a couple hundred dollars a month at least. That's way more than my mom gives me!